        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
JMS Connect User's Guide
APPENDIX A
JMS defines two administered objects: Destinations and ConnectionFactories. The former kind of object associates a topic name or queue with a physical resource; the latter exposes the methods by which a client can connect to a JMS provider's service daemon. Both kinds of objects involve resources that are under administrative control. JMS clients are able to find administered objects by looking them up in a namespace using JNDI.
In Publish/Subscribe messaging, asynchronous delivery occurs when the message broker (or topic manager) calls the MessageListener's onMessage() method. In the synchronous case, by contrast, the receiving application obtains messages by requesting them.
One of the five JMS-defined message types. The body of this type of message consists literally of a byte array; hence, it can represent any kind of payload.
Customer Information Control System: An IBM protocol for conducting and monitoring transactions with mainframes.
In a transacted message session, calling the session's commit() method causes any produced messages to be (irreversibly) sent and any consumed messages to be acknowledged (and thus removed from the queue). See also Transaction and Rollback.
A connection represents the collection of server-side and client-side objects needed to establish and manage sessions. Connections can be of the QueueConnection type or the TopicConnection type. Creation of connections occurs via a ConnectionFactory object (accessible via JNDI).
A record structure consisting of individually defined COBOL data descriptors.
Although not a JMS-defined term, the word datagram is frequently used in messaging. It generally refers to a short message, often an administrative notification of some kind, sent in "fire and forget" manner (i.e., with no expectation of any reply).
JMS Queues and Topics extend javax.jms.Destination. Thus, a JMS destination is equivalent to a queue or topic. Destinations are created administratively and bound to a JNDI name at the time of creation.
Document Object Model. An industry standard way of describing or representing the containment hierarchy for an XML or HTML file.
A message receiver in a Publish/Subscribe setting (see "Publish/Subscribe," below) can register to receive messages even when offline. Such a subscriber is said to be durable, since the receiver's status persists beyond any given session.
Term used to describe the order in which bytes are stored in computer memory. Big-endian is an order in which the most significant value in the sequence is stored at the lowest memory address (the opposite of little-endian). Intel has traditionally used a little-endian architecture, where most other chip makers have favored a big-endian architecture.
Java Messaging Service. A Sun-developed Java interface for message services, defining indsutry-standard objects and behaviors for Message Oriented Middleware. A JMS-compliant MOM implements the interfaces defined in JMS.
Any MOM system that implements the JMS interface.
Java Naming and Directory Interface: a standard extension to the Java platform, giving Java applications a unified interface to multiple naming and directory services.
Java Transaction API: a Java API for delimiting distributed transactions.
One of five JMS-defined message types, consisting of name/value pairs. The keys are Java Strings and the values are Java primitive types.
A Java interface that applications can implement in a Publish/Subscribe system that allows the application to receive automatic notification of incoming messages.
Message Oriented Middleware. A software system (e.g., IBM's MQSeries software) that implements enterprise messaging.
A pane in the JMS Component Editor that displays various attributes (such as header fields and body content) associated with a message.
One of the two JMS-defined delivery modes (the other being PERSISTENT; see below), guaranteeing at-most-once delivery. Because the message is not written to nonvolatile storage at any point, system outages can result in loss of the message when this mode is used; however, overhead is lower with this mode than with PERSISTENT.
One of the five JMS-defined message types, in which the body contains a serialized Java object.
One of the two JMS-defined delivery modes (the other being NON_PERSISTENT). Use of the PERSISTENT mode guarantees that a message will be delivered once and only once. The message is written to nonvolatile storage to avoid any possibility of loss in transit.
One of two main messaging paradigms in popular use (the other being Publish/Subscribe messaging). In PTP systems, queues are not organized by topic but instead typically "belong" to dedicated receivers (client apps), who treat queues much like mailboxes. Clients send messages to and receive messages from other clients with a minimum of administrative intervention. Receiving apps may optionally implement selectors (or filters) that allow for preferential retrieval of messages based on special criteria.
One of two main messaging paradigms in popular use (the other being Point-to-Point messaging). In Publish/Subscribe, queues are often called topics. (See below.) They differ from ordinary queues in that topics are designed to be shared by numerous "listeners," whereas in Point-to-Point messaging a queue is customarily associated with one receiving app (or at least a small, well-defined number of users). Because topics are shared, a message is not removed from a topic until every registered listener has received it. Also, filtering (which in Point-to-Point messaging is done via message selectors) is under administrative control in Pub/Sub systems, rather than being under the control of receiving apps. Clients that post messages to a topic are said to be "publishers," while clients that consume those messages are "subscribers."
In JMS-based messaging systems, messages are sent not to clients but to queues—which is to say, storage repositories set up to handle messages. Interposing queues between senders and receivers assures that even when a client is unavailable, messages addressed to the client are still able to be cached for later retrieval. Queues are typically created administratively and exposed to message clients as static resources.
Remote Procedure Call: A protocol in which a program or procedure is remotely invoked via a synchronous session with a mainframe or server.
In a transacted message session, calling the session's rollback() method causes any produced messages to be discarded (not sent) and any consumed messages to be left on the queue as if nothing happened. See also Commit and Transaction.
In Point-to-Point messaging, a client can use a selector to filter messages based on header content. The selector is basically a conditional statement (i.e., a statement that evaluates to true or false) involving a header or property value, written in a syntax similar to SQL92. (See Appendix C.)
A session is a lightweight JMS object for producing and consuming messages. A session retains retrieved messages until they have been acknowledged. All send and receive actions are scoped to sessions.
An implementation of Structured Query Language (commonly used for database queries); the basis for JMS message selector syntax.
One of the five JMS-defined message types, wherein the body of the message consists of Java primitive values. The body of this type of message is intended to be read sequentially using methods like readLong(), readString(), etc.
One of five JMS-defined message types. The body of a TextMessage is a String.
The effective lifespan of a message. Message expiration is calculated on the basis of the time when the message was sent plus the Time-to-Live value.
In Publish/Subscribe messaging (see "Publish/Subscribe" above), messages queues are often called topics. In essence, a topic is a queue; it differs from a queue mostly in the way it is administered. Topics are typically shared by many users and may form nodes in a content hierarchy (although this is not a requirement of JMS). Many users may "publish" to one or more topics. Conversely, a given topic may have many "subscribers."
JMS message sessions can group one or more receive, send, or browse actions into a transaction, which means all operations are conducted as a unit. If a transaction succeeds, all of its constituent operations succeed. If a transaction fails, all operations are "rolled back" to restore the original state that existed before the session began. Note that JMS commit and rollback methods are scoped to the JMS session and therefore do not affect other program operations.
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...