|< Day Day Up >|| |
Figure 13-1 shows the Runtime pattern and Product mapping for the Message Connection variation of the Direct Connection application pattern within the business domain of an organization, using the Java Message Service.
Figure 13-1: Direct Connection——Message Connection— JMS Product mapping
This product mapping uses WebSphere MQ as the transport mechanism for JMS messages. The product mapping uses a WebSphere MQ queue manager on each server to transport the messages. The source application uses JMS to place messages on a local queue. WebSphere MQ is then responsible for ensured delivery of this message to the proper destination, in our case, the WebSphere MQ queue manager on the target application server.
The following sections outline design guidelines for application integration using JMS. We start with an introduction to JMS, then discuss JMS messaging styles, messaging patterns, and provider considerations in the IBM WebSphere Application Server V5.0 JMS environment.
The Java Message Service (JMS) API enables a Java programmer to access message-oriented middleware such as WebSphere MQ from the Java programming model. JMS has two messaging styles:
Point-to-point model using queues
Publish/subscribe model using topics
Communications are asynchronous, so clients can receive messages without making a request and send messages without waiting for a reply. Communications are loosely coupled. The sender and receiver do not have to be active or aware of each other, as the messaging system handles the delivery of messages.
JMS is only a specification. Each enterprise messaging system vendor must provide classes that implement the specification for their specific messaging system.
As shown in Figure 13-2, the JMS architecture has the following components:
An administration tool for creating JMS connection factories and destinations (or administered objects) in the JNDI namespace.
A JMS provider that is a messaging system implementing the JMS interfaces. J2EE 1.3 application servers, such as WebSphere V5.0, must include a JMS provider.
JMS clients produce and consume messages. They use JNDI to look up connection factories and destinations so they can connect to the JMS provider to send and receive messages.
Figure 13-2: JMS components
A number of factors affect the design of systems using JMS. In this section we discuss some of the issues you should consider when building an application.
As shown in Figure 13-3, point-to-point messaging involves working with queues of messages. One or more clients might send messages to a queue, but a message is taken out by only one client. Messages remain in the queue until they are removed, so the availability of the receiver client does not affect the ability to deliver a message. In a point-to-point system, a client can be a sender (message producer), a receiver (message consumer), or both. In JMS, point-to-point types are prefixed with "Queue."
Figure 13-3: JMS point-to-point model
In point-to-point messaging, there are generally three messaging patterns:
Message producer or send-and-forget
We look at these messaging patterns in more detail in "Synchronous versus asynchronous design considerations" on page 284.
In contrast to the point-to-point model of communication, the publish/subscribe model, shown in Figure 13-4, enables the delivery of a message to multiple recipients. A sending client publishes the message to a topic to which multiple clients can be subscribed. A durable subscription stores messages when the consumer is not connected, whereas a non-durable subscription discards messages when the consumer is not connected. In a publish/subscribe system, a client can be a publisher (message producer), a subscriber (message consumer), or both. In JMS, pub/sub types are prefixed with "Topic."
Figure 13-4: Publish/subscribe model
We look at the pub/sub pattern in more detail in "Synchronous versus asynchronous design considerations" on page 284.
Another design choice is the JMS message type to use. JMS provides the following message types:
Each message type contains specific interfaces pertaining to its content and allows specific operations on the messages.
JMS messages are composed of the following parts:
Header: Contains information to identify and route messages.
Properties: Custom values that can optionally be added to messages. Properties can be:
Application-specific: Properties used by JMS applications.
Standard: JMS properties.
Provider-specific: Properties that are specific to a messaging provider.
Body: The message data.
A couple of message properties are also important to look at:
Delivery mode: When delivery must be assured by the business requirements, persistent messages are needed. But when this is not needed, performance can be gained by the use of non-persistent messages.
Message expiration: When using non-persistent messages, message expiration can be used to discard messages that have remained on a queue or topic for longer than required. This prevents unprocessed messages from building up over time.
In the Web application environment, choosing an asynchronous or synchronous approach to JMS communication will significantly affect the design of the application. The effects could ripple as far as the user interface interaction (or user experience) or they could be felt only in the low-level design and behavior of the underlying application. In this section we look at both the user interaction differences and the system design considerations.
For the purpose of discussion, let's consider an example Web application that provides Web banking and needs to connect to an enterprise application that is hosting the bank account data.
First, it is important to go over some basic Web application principles. The Web is a stateless environment; typically a request is received and the reply sent back immediately within the same client session. A Web server is not normally able to initiate a connection to a Web client out of the blue. Information about the requesting client is retained while the request is being serviced and not lost until a reply is sent back. The Web is a typical request/reply model. Most Web applications are built using this model and this style of user interaction, where the user can expect a reply back from the server that will be the result of making a request.
Using our Web banking example, let's assume a Web request requires information from the enterprise application about the bank balance. The JMS interaction between the Web application and the enterprise application can be achieved using:
Message consumer pattern
Using this approach, we fit the standard Web model by providing a complete round trip for the client request that results in a reply. Users do not have to visit another results page to see the results of their request.
As shown in Figure 13-5, the Web application sends a request message, then waits for a reply. The response message needs to be linked to the request message using the request message ID as the correlation ID of the response message.
Figure 13-5: Request/reply pattern
The overriding factor in a request/reply pattern is the time delay before a reply gets back. You should remember that request/reply is a synchronous communication over an asynchronous transport. For request/reply, two queues are needed: one for the sender to send messages and one for receiving the responses back. The request/reply consists of two units of work.
Putting the message on a queue.
Receiving the response, and for example, inserting the message in a database.
These actions can never be one unit of work because the real put of the message only takes place after the commit. No message will be sent without a commit, and when no request message is sent, no reply will arrive!
An example of a request/reply scenario is getting your account balance. A message is first sent with the account ID, then the application waits until a response message is sent back with the balance of the account, with the results logged to an application database.
Request/reply design considerations include:
Applications should not be designed without appropriate timeout or re-try capability. Non-persistent messages and message expiration can help with management of reply messages not received within the timeout window.
If the message producer is implemented as a session EJB, then in the request/reply JMS model, the EJB must wait (or block) until the enterprise application has replied before it can continue processing. Blocking in an EJB is not generally recommended because it restricts the EJB container's ability to effectively manage its resources. Care must be taken to ensure that the EJB is not waiting indefinitely and that there is a timeout in place.
In send-and-forget (or fire and forget), shown in Figure 13-6, the Web application will initiate the request to the enterprise application using a JMS destination, but it will not wait for the outcome. This design has important repercussions on the user interaction. A message consumer pattern could be used for receiving the reply from the enterprise application. The user must at some point go to a result page to see their bank balance when it has been retrieved from the enterprise application.
Figure 13-6: Send-and-forget pattern
From an implementation point of view, the blocking EJB dilemma is avoided. However, a new page is required to allow the customer to come back to check their last balance request from the local database. This design alleviates the need for a blocking EJB, but the user experience is drastically different from the request/reply model.
Send-and-forget design considerations include:
Non-persistent messages can be processed much quicker by the JMS provider because they do not incur any disk I/O (for persistence). The decision to use persistent or non-persistent messages will generally be governed by the business requirements.
In the case of getting a balance, no funds transfer occurs; as such, a lost message has little impact and may not warrant persistent messages.
Message consumers can be implemented by message-driven beans that are invoked by the container when a message arrives on a destination. When a message arrives, the EJB container passes the message to an instance of a user-developed message-driven bean.
This pattern can be used by a catalogue application receiving updates for changes in the online catalogue. In this scenario, a message-driven bean receives an incoming message and updates a database, as shown in Figure 13-7. The pattern is typically useful in a business-to-business situation where no user interaction is needed.
Figure 13-7: Message consumer
Message consumer design considerations include:
Use message-driven beans only for handling the message. Move the business logic to another bean, which will be invoked by the message-driven bean. This way it is also possible to call the business logic out of another channel, like a servlet, which has been activated by a user.
Message-driven beans can't throw exceptions to the user, so exceptions have to be logged in an error report.
Using this approach, we can provide the user with an immediate reply without them having to explicitly go to a separate Web page to see the results. However, this can only be achieved if a local copy of data is used.
The source application will register interest in information from the target application upon startup. Periodically, the target application will publish information to the subscribers (source application). The message consumer pattern can be implemented at the subscriber site to receive the publications of the target application. The source application will store this information in a local database and use it when a Web request is being serviced.
Using this approach, the source application can operate in its native modes (stateless and request/reply) and the user can see the results of their request within the same user transaction. However, the information may be slightly outdated.
Publish/subscribe design considerations include:
Never cache a non-durable subscription, use durable subscriptions instead.
For further information about how IBM WebSphere MQ can be used in the pub/sub model, refer to the redbook MQSeries Publish/Subscribe Applications, SG24-6282.
It is not inherently incorrect to select any of the messaging patterns discussed, provided the selection is implemented correctly. The user's requirements and experience will dictate which decision is the correct one.
A request/reply JMS communication model is ideal in a Web environment. However, if EJBs are to be the implementers of the enterprise access, care needs to be taken during implementation to prevent blocking calls from EJBs. If the user is willing to accept a different user interaction model, then asynchronous fire-and-forget is also an acceptable option. The middle ground could be achieved using full publish and subscribe; however, the accuracy of the information may be at stake.
The request/reply blocking stateless EJB must be implemented such that appropriate timeout and re-try conditions are applied.
The EJB 2.0 specification does point out that only one client will have access to an instance of a stateless EJB while it is servicing a client-invoked method. If, however, a blocking wait occurs for an indefinite period, the container may run short of available instances of the specific EJB to service other clients and thus slow down the overall performance of the application.
For further information, refer to:
There are a number of options for where to implement your JMS message producers and consumers in the J2EE application architecture. These options include:
If the Model-View-Controller (MVC) pattern is invoked, then the model is typically where the producer would be implemented. In J2EE application architecture, this is likely to be a session EJB.
However, it is possible to implement the message producer almost anywhere. A simple JavaBean could also implement the message producer and fit in with the MVC pattern.
If the producer is participating in a transaction of some kind, then session EJBs may be a better implementation choice. Transaction creation and management is gained almost for free within EJBs, whereas it would have to be explicitly created and managed within other implementation choices such as JavaBeans.
Servlets can also be used as message producers. They offer a simpler programming model than EJBs. Servlets, however, are usually implementers of the controller aspect of the MVC pattern, and do not take advantage of the EJB container facilities.
Just as there are for producers, there are a number of implementation choices for consumers. When consumers are used in request-reply scenarios, you then have the choice to implement this in a servlet or an EJB. Implementing the consumer as an EJB has the advantage of container transaction management and security management. But the disadvantage is that an EJB will be blocked until a response arrives. Some extra programming is needed to disregard a response when it takes too much time.
Another option for consumers is a message-driven bean. The request and reply will be loosely coupled when using a message-driven bean, which makes it more complex. A message-driven bean is a good solution for subscription and message consumer patterns.
In line with the J2EE 1.3 specification, IBM WebSphere Application Server V5.0 has an embedded JMS provider, or messaging service, included in the application server. This internal JMS provider can be used for asynchronous JMS communications with other WebSphere applications. The internal messaging service cannot be used for messaging with other messaging systems, such as WebSphere MQ. If you need to communicate with other systems using WebSphere MQ, then you need to install WebSphere MQ as a JMS provider on WebSphere Application Server.
With most middleware-oriented software, there are client and server components. The client is usually a smaller piece of software that provides local access to the remote server. The server implements all of the functionality and the client provides a relatively light facade for accessing the server's function.
The WebSphere MQ client provides access to all of the WebSphere MQ API and is typically used where there are limited hardware or system administration requirements. The WebSphere MQ client is also able to connect to multiple queue managers on different platforms.
The server provides richer administration functionality to take advantage of the full suite of MQ functionality, such as failover support or scalability configuration options.
During development, the client option is useful where machine resources are limited. Any complex changes to the WebSphere MQ configuration will, however, require the server version. The embedded WebSphere JMS provider available in the WebSphere Studio test environment can also be used during development.
|< Day Day Up >|| |