A number of external links, related to WebSphere MQ:

Official IBM sites:

• WebSphere MQ Family (formerly - MQSeries family)
• WebSphere Trial downloads

Related links:

• MQ Software - Q Pasa! monitoring software
• MQ Solutions UK

WebSphere MQ, previously known as MQ Series, is a tool to transfer message and data from one system to another, a means of program-to-program communication. Basically, one program puts a message in a queue and the other program reads from the queue. This can be synchronous or asynchronous. It's time independant, communicating applications do not have to be active at the same time.

MQSeries runs on a variety of platforms. The MQSeries products enable programs to communicate with each other across a network of unlike components, such as processors, subsystems, operating systems and communication protocols. MQSeries programs use a consistent application program interface (API) across all platforms.

The figure shows the main parts of an MQSeries application at run time. Programs use MQSeries API calls, that is the Message Queue Interface (MQI), to communicate with a queue manager (MQM), the run-time program of MQSeries. For the queue manager to do its work, it refers to objects, such as queues and channels. The queue manager itself is an object as well.

What is Messaging and Queuing?

Message queuing is a method of program-to-program communication. Programs within an application communicate by writing and retrieving application-specific data (messages) to/from queues, without having a private, dedicated, logical connection to link them. Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly. Queuing means that programs communicate through queues. Programs communicating through queues need not be executed concurrently.


This figure shows how two programs, A and B, communicate with each other. We see two queues; one is the "output" queue for A and at the same time the "input" queue for B, while the second queue is used for replies flowing from B to A. The squares between the queues and the programs represent the Message Queuing Interface (API) the program uses to communicate with MQSeries' run-time program, the queue manager. As said before, the API is a simple multi platform API consisting of 13 calls.

About the queue manager

The heart of MQSeries is the message queue manager (MQM), MQSeries' run-time program. Its job is to manage queues and messages for applications. It provides the Message Queuing Interface (MQI) for communication with applications. Application programs invoke functions of the queue manager by issuing API calls. For example, the MQPUT API call puts a message on a MQSeriesqueue to be read by another program using the MQGET API call. This scenario is shown in the next figure.


A program may send messages to another program that runs in the same machine as the queue manager (shown above), or to a program that runs in a remote system, such as a server or a host. The remote system has its own queue manager with its own queues. This scenario is shown in the next figure.


The queue manager transfers messages to other queue managers via channels using existing network facilities, such as TCP/IP, SNA or SPX. Multiple queue managers can reside in the same machine. They also need channels to communicate. Application programmers do not need to know where the program to which they are sending messages runs. They put their messages on a queue and let the queue manager worry about the destination machine and how to get the messages there. MQSeries knows what to do when the remote system is not available or the target program is not running or busy. For the queue manager to do its work, it refers to objects that are defined by an administrator, usually when the queue manager is created or when a new application is added. MQSeries for Windows provides graphical user interfaces; other platforms use the command line interface or panels.

DB2 database check:

# ps -ef | grep db2loggw

This command shows you the (log writer processes of the) DB2 databases that are active. To show the DB2 instance list:

# su - db2inst1 -c db2 list active databases
# su - db2inst1 -c db2ilist

Check if the db2agents and db2sysc are active via ps -ef. If one of these are not functioning, the database will not be active.

Check connectivity to DB2 database:

# su - db2inst1
# db2 connect to [database-instance] user [user-name] using [password]
db2 list tables
db2 list applications
db2 connect reset

IBM HTTP Server check:

Check the HTTP process using:

# ps -ef | grep httpserver

Startup a web browser to http://[server]/ and to https://[server]/.

Check the eClient:

# ps -ef | grep eClient_Server

WebSphere check:

Start a browser to http://[server]:9090/admin and login with ID wasadmin or icmadmin. Start a command window, go to the WebSphere directory (WebSphere/AppServer/bin) and run:

# serverstatus -all

Individual WebSphere applications can be stopped with stopserver icmrm (if you would like to stop the Resource Manager) and startserver icmrm (server1 is the default WebSphere server).

Check the Resource Manager

Start a browser to http://[server]/icmrm/ICMResourceManager. If you get output about a NULL request, it's fine.

Other checks:

http://[server]/icmrm/snoop should output information of the Snoop Servlet.
https://[server]/icmrm/ICMRMAdminServlet should show RM diagnostic data (You'll probably have to logon with the rmadmin userid).

A number of external links, related to WebSphere Application Server:

Official IBM sites:

• WebSphere IBM page
• WebSphere Application Server
• WAS - Support page
• WAS 5.1 - Info Center
• WAS 6.0 - Info Center
• WAS - Prerequisites
• Search for WebSphere on www.redbooks.ibm.com
• WebSphere Redbooks Domain
• WebSphere Developer Domain
• Websphere Advisor Magazine

Related links:

• Eclipse.org
• JBoss
• WebSphere.org
• Java2 Platform Enterprise Edition standard
• Java Runtime Environment
• IBM HTTP Server - support

First of all, start your HTTP Server and WAS administration server "server1".

In a browser, run the snoop servlet:

http://localhost:9080/snoop

Using port 9080 bypasses the web Server plug-in and uses the imbedded HTTP server of WebSphere Application Server.

In a browser, run the snoop servlet:

http://localhost/snoop

This uses port 80, which will test the Web Server plug-in of the HTTP Server, and the communication from the Web Server to WebSphere Application Server.

WebSphere Application Server (WAS) is a server for deploying and managing applications on the web. It is a deployment environment for Java based applications (it is basically an environment for running Java code). For example, the eClient of IBM Content Manager uses Java Server Pages (JSPs). JSPs contain HTML and embedded Java code that is compiled and run by WAS, similar to PHP. WebSphere Application Server is actually part (or the foundation) of a huge range of products, called the WebSphere family of products.

WAS is built on the services of a web server to provide additional services to support business applications and transactions on the web. A common example of this is persistence support for user sessions that cannot be provided by only using an HTTP server. In general, WAS is able to facilitate a multi-tiered, web enabled environment that provides security, reliability, availability, scalability, flexibility and performance. WAS can, of course, serve static HTML and dynamic content.

Releases available:

• WAS Express (Single Server): Designed to support only a single hardware server. For small companies or individuals.
• WAS Base: intended for large production environments. Its purpose: A stand-alone, single machine, which is not scalable (1 process on 1 machine).
• WAS Network Deployment (ND): offers specific high end functionality. Actually the same as the base version, but this version is scalable: it can be spread over several systems to offer load-balancing capabilities.
• WAS Enterprise: the same as the ND version, but with added features. Nowadays it is also called the Business Integration Foundation version.

The admin console of WAS is also a WebSphere application, usually available through:

http://[server]:9090/admin

WAS 5 has a connection pooling feature, which can result in a significant observable reduction in response time, especially for database connections. It reduces the overhead of creating a new connection for each user and disconnting it afterwards, by using existing connections from a connection pool. WAS communicates with databases via JDBC, which is actually the driver for a database.