       |  |
JMS Connect User's Guide
CHAPTER 1
Welcome to the Novell Integration Manager JMS Connect User's Guide. This Guide is a companion to the Integration Manager User's Guide, which details how to use all the features of Integration Manager except for the various Connect Component Editors. So, if you haven't looked at the Integration Manager User's Guide yet, please familiarize yourself with it before using this Guide.
Integration Manager provides separate Component Editors for each Connect, such as the JMS Connector. The special features of each Component Editor are described in individual Guides like this one.
Before you begin working with the JMS Connect, you must have it installed into your existing Integration Manager. Likewise, before you can run any Services built with this connector in the exteNd Application Server environment, you must have already installed the corresponding server software for this connector into the exteNd Application Server.
NOTE: To be successful with this Component Editor, you should be familiar with Message Oriented Middleware (MOM) concepts and the particular MOM environment (e.g., MQSeries) into which you will be deploying. While the pages that follow offer a brief introduction to important enterprise-messaging concepts, a truly comprehensive approach is beyond the scope of this guide. In any event, the discussion offered here is in no way meant to substitute for the documentation supplied by your JMS provider.
Novell Integration Manager is built upon a simple hub and spoke architecture. (See illustration below.) The hub is a robust XML transformation engine that accepts XML documents, processes the documents, and returns an XML document. The spokes or Connects are plug-in modules that "XML enable" sources of data that are not XML-aware, bringing their data into the hub for processing as XML. These data sources can be anything from legacy COBOL/VSAM managed information to Message Queues to HTML pages. Integration Manager Connects can be categorized by the integration strategy each one employs to XML enable an information source. The integration strategies are a reflection of the major divisions used in modern systems designs for Internet based computing architectures. Depending on your B2Bi needs, Integration Manager can integrate your business systems at the User Interface, Program Logic, and/or Data levels.
Hub and spoke architecture allows Integration Manager to provide enterprise-wide XML integration via Connects (EEs).
Java Messaging Service (JMS) is a Java-based interface for using Message Oriented Middleware (MOM) services, such as provided by IBM's MQSeries or Progress Software's SonicMQ. In order for distributed applications running on Java application servers to make full use of messaging systems, Java-language clients and Java middle-tier services must have a common way to "speak to" enterprise messaging products. JMS provides that capability.
Novell Integration Manager can integrate business systems at the User Interface, Program Logic, and/or Data levels.
The Integration Manager JMS Connect allows you to create Components that can send, receive, and/or browse messages in queues administered by a JMS-based MOM system, using transacted or non-transacted sessions. JMS-enabled Integration Manager services are able to enjoy the dual benefits of asynchronous processing and transport-layer independence that characterize enterprise messaging. Using the JMS Connect, you will be able to create powerful, flexible applications that make optimal use of system resources while carrying out potentially complex operations involving remote invocation of objects, assured "once only" delivery of notifications, and/or distributed transactions.
The JMS standard was built with several goals in mind:
Provide an Application Programming Interface suitable for creating and manipulating messages in formats compatible with existing MOM products.
Support many different message-content types, including messages containing Java objects.
Facilitate the development of heterogeneous applications that span operating systems, machine architectures, transport mechanisms, and computer languages.
JMS is a broadly applicable Java API that is intended to be layered over a wide range of existing and future Message Oriented Middleware systems, much the same way that JNDI (the Java Name and Directory Interface) is layered over existing name and directory services.
The complete JMS specification is available at http://java.sun.com/products/jms/.
An enterprise messaging system provides for the transport and storage of messages. Messages, in this context, are packets of information that are produced and/or consumed primarily by enterprise applications (rather than humans). They may contain key-value pairs, XML documents, serialized Java objects, or arbitrary byte streams.
One of the main attractions of Message Oriented Middleware is its ability to serve as an abstraction layer that hides the details of message transport and delivery from diverse clients that may need to communicate across networks that use different communication protocols. By acting as a communications gateway, MOM shields clients from connectivity issues that would otherwise impede development of distributed applications.
Another aspect of enterprise messaging that makes products like MQSeries and SonicMQ so useful is their ability to link processes in asynchronous fashion. Asynchronous processing means that the exchange of data between parties does not depend on either party being in direct, realtime contact with the other. The alternative to asynchronous processing is synchronous processing, wherein a host and a client (or a peer and a peer) must be in continuous conversation with each other for the entire duration of a session, without interruption. (An example of a synchronous interchange would be the use of a Remote Procedure Call in a CICS environment.) While synchronous operations are required for some types of interactions, there are many kinds of business processes that do not require synchronous communication between participants. For such processes, asynchronous interaction generally makes the most efficient use of resources and can dramatically improve system productivity.
A synchronous process is analogous to a restaurant in which every customer orders his meal directly through a conversation with the chef and the kitchen takes no other orders while the current customer's meal is being cooked. Customers line up and must wait, one by one, for every meal to be individually prepared. Asynchronous processing would be analogous to the more familiar scenario of waiters and waitresses conveying orders between customers, kitchen, and bar concurrently. In the latter case, the waiters serve as a messaging channel to the kitchen, where orders are "queued up" and finished meals are dispersed on an as-available basis. In this example (as in many business processes), much better efficiencies are possible with asynchronous order processing than with synchronous order processing.
The time-domain decoupling afforded by messaging systems helps make robust, fail-safe operation possible. One party can be busy—or even offline—when the other party sends (or receives) its message. The sender can continue processing without needing to wait for an acknowledgement from the receiver. A network or server can go down, yet not affect the transmission or receipt of a message.
Asynchronous messaging depends on the fact that messages are sent not to clients, per se, but to queues, which exist independently of the client processes that use them.
A queue is a holding area or repository in which data elements (messages, in this case) are stored for eventual retrieval. In a MOM environment, client applications needn't know how message queues are structured, maintained, or stored; the details of queue management are handled by the MOM vendor (or "JMS provider"). Like server nodes, queues are often clustered for purposes of reliability, scalability, and load balancing.
While FIFO (first-in/first-out) and LIFO (last-in/first-out) queues are familiar constructs in computing, no order of retrieval is presumed in a message queue. Rather, the retrieval order is open. This means custom prioritization schemes can be applied to messages so that retrieval order (i.e., consumption order) is dependent on a client's needs. Properly exploited, this feature can lead to more efficient overall system operation. Processing of low-priority messages can be deferred to a time when system resources are available; low-priority items needn't interfere with the processing of high-priority ones.
The process of inspecting messages without removing them from the queue is called browsing.
NOTE: The length of time messages are held in a queue, the maximum number of messages a queue can handle, and the manner in which resource overruns are handled are not defined by the JMS standard. Consult your MOM vendor's documentation to learn more about these issues.
While some latency occurs in all messaging systems, this does not mean that applications that use messaging are, of necessity, slow. The asynchronous processing made possible by messaging affords the possibility of multitasking inside an application, which could (depending on the application) actually boost throughput. For example, while a customer adds items to his shopping cart, the shopping-cart app can trigger an inventory-checking component, while another component can calculate shipping charges, while another component pulls customer information out of a database, etc., all operations taking place concurrently.
The choice of messaging model (Point-to-Point versus Publish/Subscribe) has important implications for latency. See "What Is Point-to-Point Messaging?" and "What Is Publish/Subscribe Messaging?" further below.
While the quality-of-service guarantees offered in Message Oriented Middleware solutions can vary greatly, and while real-world reliability often depends on administrative issues (such as cluster size and available resources), all JMS-based messaging services are required to offer assured, once-only delivery of messages as an option for applications where reliability is paramount. JMS also allows for configurations that provide a less robust quality of service, so that in cases where speed of delivery might be more important than assured, once-only delivery, a tailored solution can be built. The reliability of JMS-based messaging solutions is thus configurable.
In general, strong reliability guarantees are a common feature of JMS-based systems.
One of the things that makes JMS messaging attractive from a reliability standpoint is that message sessions can (optionally) incorporate transaction control. A transacted session groups an arbitrary set of produced and/or consumed messages into a single logical unit of work. When a transaction commits, all of its inputs (in terms of messages) are acknowledged and all outputs are sent. When a transacted message session rolls back, any produced messages are destroyed and any messages consumed during the session are recovered.
An an example, suppose an application builds a group of five messages. A requirement of the application is that the entire group of five messages must be sent as a batch; or else none of the five must be sent. Using a JMS Component, the application could be structured such that messages are built and sent individually, but if a connection closes prematurely (or any other error condition happens, involving any of the five messages), the entire group is rolled back.
NOTE: JMS does not require that MOM products support distributed transactions. But if such support exists, JMS does require that such support be implemented via the JTA (Java Transactions API) XAResource interface. Consult your JMS provider's documentation to see what kind of distributed transaction support, if any, is available in your MOM environment.
NOTE: Since distributed transactions are controlled via JTA, the use of message-session commit or rollback commands in this context will cause a JMS TransactionInProgressException to be thrown.
Two main messaging paradigms are implemented by MOM vendors: Point-to-Point (PTP) messaging, and Publish/Subscribe (which is discussed further below). Some vendors implement one or the other; some implement both.
NOTE: Point-to-point does not imply a synchronous connection in the context of messaging (as it does in some other contexts, such as discussions of RPC).
In the PTP model, any JMS client can—in theory—send messages to any other JMS client, subject only to administrative constraints. PTP is an asynchronous, queue-based, peer-to-peer model in which queues are typically created administratively and have indefinite lifespans. A queue is always available to receive and hold messages sent to it whether the client or clients using that queue are online or not.
With PTP, a queue functions much like a mailbox. One application might send messages to a queue; another application might retrieve messages from the same queue. A common case is that a client will have all its messages delivered to a single queue.
The Point-to-Point model is a queue-based, peer-to-peer model in which queues act, essentially, as mailboxes. Client applications can post to a queue, or (as with Application #2 above) browse, retrieve messages one-by-one, or continuously poll the message queue. Optionally, clients can implement a MessageListener that will act on messages as they are received.
The Publish/Subscribe (or pub/sub) messaging model—implemented by some (but not all) MOM vendors—differs from Point-to-Point in the following ways:
Queues are organized hierarchically into nodes called topics. (This is a typical implementation scheme, although in fact JMS places no restrictions on what a topic can represent.)
Each topic acts as a kind of mini-message-broker that accumulates and distributes messages addressed to it.
In a Publish/Subscribe system, queues are usually organized hierarchically into nodes called topics. Clients may subscribe and/or publish to any number of topics.
Clients in this kind of system use message producer/consumer objects called TopicPublishers and TopicSubscribers. A client may subscribe to more than one topic; and a client may be both a subscriber and a publisher.
TopicSubscribers can be durable or non-durable. If a client needs to have access to all messages on a given topic (including ones that may be published when the subscriber is offline), a durable TopicSubscriber must be used. Otherwise, the client will have access only to messages that are queued during the lifetime of a given message-retrieval session.
NOTE: Messages are served to subscribers in serial fashion. Because topics are shared resources (and because only one subscriber can be serviced at a time), the potential for latency is somewhat greater in pub/sub messaging than in PTP.
JMS supports two modes of message delivery.
The PERSISTENT mode instructs the message broker to write the message to a secure store to insure that the message is not lost in transit due to a system failure.
The NON_PERSISTENT mode does not require the JMS provider to log the message to stable storage; thus, the message can, in theory, be lost. (The tradeoff here is one of performance. There is less overhead with a NON_PERSISTENT message.)
A JMS provider is required to deliver a NON_PERSISTENT message at-most-once. This means that while a message may sometimes be lost, it will never be delivered twice.
By contrast, the delivery guarantee for PERSISTENT messages is once-and-only-once. This means a provider failure must not cause a message to be lost in transit; and the message must not be delivered more than once.
NOTE: Once-and-only-once delivery has the important limitation that it cannot and does not guarantee against message loss due to message expiration, resource overruns, or administrative destruction criteria. Configuring a message system for maximum reliability requires a thorough understanding of administrative issues surrounding the particular MOM solution in use.
Enterprise messaging products treat messages as persistible, lightweight entities that consist of a header, a body, and (in the case of JMS-aware products) a property list.The header contains fields used for message routing and identification. The body contains the application data being sent. Properties provide a mechanism for adding arbitrary descriptors (actually implemented as extra header fields) to messages so that clients—or their providers—can select or "filter" messages on the basis of application-specific criteria.
Among the message characteristics defined in the header are an expiration time (which sets the message's useful life); message priority (based on a number ranking, from zero to nine); and delivery mode (PERSISTENT or NON_PERSISTENT).
The header fields defined by JMS are:
In addition to these predefined header fields (which every JMS message is required to have), there are JMS-defined property fields (many of which are optional), provider-specific properties, and user properties.
The semantics of the various header and property fields are discussed in detail in Appendix C.
JMS defines five message body types:
MapMessage—a message in which the body consists of a set of key-value pairs, wherein the keys are Java Strings and the values are Java primitive types. Entries may be accessed by sequential enumeration or randomly by name. (The ordering of key-value pairs is undefined.)
TextMessage—a message in which the body is a java.lang.String.
StreamMessage—a message whose body consists of a stream of Java primitive values (which are filled and read sequentially).
ObjectMessage—a message containing a Serializable Java object. (For collections of objects, one of the collection classes defined in JDK 1.2 can be used.)
BytesMessage—a message comprising any arbitrary stream of uninterrupted bytes. (This category is intended for encoding a binary payload, or a special payload to match a vendor's native message format.) In Integration Manager, the content of a BytesMessage should be Base64-encoded.
NOTE: Regardless of type, all JMS messages are read-only once posted to a queue.
The JMS Connect allows you to define message payloads using any of the five canonical JMS body types. In addition, the JMS Connect offers two predefined message types (which are actually wrappers for two of the predefined JMS body types):
XML—Allows you to send or receive an XML document (based on any XML template of your choosing) as a message. The complete DOM representation of the XML document is available to you for mapping and/or manipulation via ECMAScript and XPath; and you can add new nodes to the template document. This message type wrappers the JMS-defined TextMessage type.
Copybook—Allows you to send or receive a COBOL copybook (as a BytesMessage).
See Chapter 4 for more information.
JMS provides two mechanisms for client retrieval of messages:
Synchronous message retrieval, wherein a timeout value can be specified for terminating the session should no response occur.
Asynchronous retrieval via a MessageListener object whose onMessage() method contains application logic for processing incoming messages.
NOTE: Here, the terms "synchronous" and "asynchronous" refer to the queue/client communication session rather than any relationship between sender and client. Senders can always post to queues, whether or not receiving clients are online; in that sense, all messages are asynchronously received.
In synchronous retrieval, a timeout value can be specified in milliseconds. If no expiration value is specified, the "receive" session will block indefinitely, until a message arrives. On the other hand, if a zero wait time is specified, queued messages that meet the applicable selection criteria (if any) will be retrieved—and the session terminated—immediately.
Asynchronous retrieval treats messages like events and allows clients to be notified immediately (and take action on) messages as they arrive. Application logic triggered by an onMessage() handler processes messages transparently, with a minimum of latency. A broadcaster/listener metaphor applies in this case.
One way to think of it is that in a synchronous-retrieval scenario, the client is pulling data from the queue; in the asynchronous case, the queue is pushing data at the client.
Some applications need to filter and/or categorize the messages they send or receive. In some instances, the receiving application can simply inspect the message body and decide—from the message contents—whether the message should be acted upon, or discarded. But it is often more efficient for selection criteria to be exposed in the message header, so that the message body need not be parsed in order to determine if the message is one that should be acted upon.
Exposing message selection hints in the header portion of a message is a common tactic when multiple receiving apps are pointed at the same queue. The application that is best suited to handling a given message type can harvest just the messages it needs, while other applications can act on messages better suited for them. Administratively, it is more efficient to set up one queue (with multiple receivers accessing it) than to set up multiple queues, each with a dedicated receiver.
Another factor to consider is that when potential selection criteria are visible (via the header) to a JMS provider, the provider can avoid delivering messages to clients that might not need them. In effect, filtering can be delegated to the JMS provider. (This strategy is important in Publish/Subscribe messaging.)
JMS defines a message selector that can be used for screening messages on a queue. The selector is an expression (with syntax similar to SQL92) that evaluates to true or false when header field and/or property values are substituted for their corresponding identifiers in the selector.
The Integration Manager JMS Connect implements selectors in the Message Filter tab of the Native Environment pane for all Browse and Receive actions; this allows you to filter incoming messages according to whatever criteria you select.
See Chapter 4 and Appendix B for more information.
A request-response scenario involves an application sending a message in anticipation of receiving a reply. For example, a credit-clearing application might package customer information into a message and send that message to a queue, where a receiving application retrieves the message, performs the necessary database queries and other processing, then replies to the original message.
This is different from the store/forward or "fire and forget" type of scenario in which a message producer simply places a message on a queue and terminates (or goes on to other processing). Messages that are sent in this fashion are sometimes called datagrams.
The JMS Connect supports both kinds of scenarios. However, the request-response scenario must (in this version of the connector) be implemented using individual Send Message and Receive Message actions. (That is, there is no one action type that encapsulates a request-response session.) If the request message and response message share the same queue, the associated send and receive actions can occur serially in the same JMS Component. But if the outgoing message will be placed on a different queue than the incoming reply, then two separate JMS Components must be created, since only one queue can be used per JMS Component.
See Chapter 4 for additional information.
The JMS standard defines numerous message-system behaviors and data types but does not address administrative concerns, performance tuning, security, configuration issues, nor a variety of other JMS-provider functions.
Among the areas not addressed by JMS are:
Consult your MOM vendor's documentation for information about any of these features.
The JMS Connect creates JMS Components which can be incorporated into Integration Manager services. Much like the XML Map Component, the JMS Component is designed to map, transform, and transfer data between incoming or outgoing messages and XML templates. It is specialized to make JMS calls into JMS-aware messaging systems; automatically fill out needed header information based on information you supply via a setup wizard; and handle details of packaging message contents according to constraints imposed by JMS.
Like any data-exchange operation, the JMS Component relies on a Connection Resource. The Connection Resource in turn specifies important information regarding ports, channels, user identity, password, queue location, and so forth. Once you've set up a JMS Connection Resource, you can use it to set up a JMS Component that sends messages to (or retrieves messages from) the queue specified in the resource.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...