Abstract
This document is methodology documentation for configuring JMS Server in Websphere 6.1 which does not come with inbuilt JMS Server. This is an extract from migrations done for a client for set of applications
Introduction
This document does a case study of an Application named Middle Tier Application (MTA) which uses MQ Queues. This application is migrated to Websphere 6.1 in RAD 7.0. Websphere 6.1 does not have inbuilt JMS Server. To overcome this we configured JMS using System Integration Bus (SIB).
Problem
Configure JMS Server on Websphere 6.1. Websphere 6.1 does not come with inbuilt JMS Server.
Approach
We will configure JMS Server using Service Integration Bus (SIB). Before configuring SIB, first we should develop an understanding what a SIB is?
Service Integration Bus
A service integration bus is a group of one or more application servers or server clusters in a WebSphere Application Server cell that cooperate to provide asynchronous messaging services. The application servers or server clusters in a bus are known as bus members.
- Any application can exchange messages with any other application by using a destination to which one application sends, and from which the other application receives.
- A message-producing application, that is, a producer, can produce messages for a destination regardless of which messaging engine the producer uses to connect to the bus.
- A message-consuming application, that is, a consumer, can consume messages from a destination (whenever that destination is available) regardless of which messaging engine the consumer uses to connect to the bus.
A service integration bus comprises a SIB Service, which is available on each application server in the WebSphere Application Server environment. By default, the SIB Service is disabled. This means that when a server starts it does not have any messaging capability. The SIB Service is automatically enabled when we add the server to a service integration bus. We can choose to disable the service again by configuring the server.
A service integration bus supports asynchronous messaging; that is, sending messages asynchronously. Asynchronous messaging is possible regardless of whether the consuming application is running or not, or if the destination is available or not. Point-to-point and publish/subscribe messaging are also supported.
After an application has connected to the bus, the bus behaves as a single logical entity and the connected application does not need to be aware of the bus topology. In many cases, connecting to the bus and defining bus resources is handled by an application programming interface (API) abstraction, for example the administered JMS connection factory and JMS destination objects.
The service integration bus is sometimes referred to as the messaging bus if it is used to provide the messaging system for JMS applications using the default messaging provide.
Many scenarios require a simple bus topology; perhaps, for example, a single server. By adding multiple servers to a single bus, we can increase the number of connection points for applications to use. By adding server clusters as members of a bus, we can increase scalability and achieve high availability. Servers, however, do not have to be bus members to connect to a bus. In more complex bus topologies, multiple buses are configured, and can be interconnected to form complex networks. An enterprise might deploy multiple interconnected buses for organizational reasons. For example, an enterprise with several autonomous departments might want to have separately administered buses in each location.
Bus Members
The members of a service integration bus can be application servers or server clusters. Bus members that are application servers or server clusters contain messaging engines, which are the application server components that provide asynchronous messaging services.
To use a service integration bus, we must add at least one member that is an application server or server cluster.
Adding a bus member automatically creates a messaging engine for that bus member. Each messaging engine has its own data store, used for example to store persistent messages and maintain durable subscriptions. By default a messaging engine associated with a server is configured with an in-process, Cloudscape-based data store. In other cases, we are asked to provide the Java Naming and Directory Interface (JNDI) name of a Java Database Connectivity (JDBC) data source for use by the messaging engine.
When the bus member is an application server, it can have only one messaging engine. If the bus member is a server cluster, it can have additional messaging engines to provide high availability or workload sharing characteristics.
To host queue-type destinations, the messaging engine can hold messages until consuming applications are ready to receive them. Each messaging engine also has a data store where it can hold messages so that if the messaging engine fails, messages are not lost.
When we define a queue-type destination, we assign it to a bus member. When that bus member is an application server or a server cluster, the messaging engine (or engines) in that bus member holds the messages.
If required, we can remove members from a bus. However, this action deletes any messaging engines that are associated with a bus member, including knowledge of any messages held by the data store for those messaging engines. Therefore, we must plan this action carefully.
When a bus member is deleted, the data source associated with this bus member is not automatically deleted, because users often associate their own data source with a bus member. This also applies to bus members created using the default data source: the data source is not automatically deleted and you must remove it manually.
If we do not delete the data source manually and another messaging bus member is created, the messaging engine will fail to start.
Bus Destinations
A bus destination is a virtual location within a service integration bus, to which applications attach as producers, consumers, or both to exchange messages.
Bus destinations can be either "permanent" or "temporary":
- A permanent destination is defined by an administrator for use by one or more applications over an indeterminate period of time. Such destinations remain until explicitly deleted by the administrator or by some administrative command or script.
- A temporary destination is created and deleted by an application, or the messaging provider, for use by that application during a session with a service integration bus. The destination is assigned a unique name.
The following are the main types of destination:
1. Queue
A destination for point-to-point messaging.
2. Topic space
A destination for publish/subscribe messaging.
3. Alias
An alias destination makes a destination available by another name and, optionally, overrides the parameters of the destination. Applications can use an alias destination to route messages to another destination in the same bus or in another (foreign) bus.
4. Foreign
A foreign destination provides a mapping to a destination of the same name on a different bus and enables applications on one bus to access directly the destination on another bus. We can set its own destination properties which will override the destination defaults.
We can configure queue, topic space, and alias destinations with one or more mediations that refine how messages are handled by the destination.
Case Study
We have configured SIB in an application for a client, steps for which are provided in the attached document. Application provides batch as well as real time support through messaging server i.e. JMS.
References:
1. Websphere 5.1 to 6.1 migration.doc by Kapil Naudiyal
2. Web Links
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/concepts/cjj0000_.html
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/concepts/cjj0000_.html
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/concepts/cjj0000_.html
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.