Government Polytechnic, Solapur: Department of Computer Technology

JAVA MESSAGE SERVICE
Government Polytechnic, Solapur

Department Of Computer Technology
A Seminar on
JAVA MESSAGE SERVICE Name of the Student: JADHAV SAYALI GOKUL
Under Guidance of: Ms. Algundagi M.S.
GOVERNMENT POLYTECHNIC,SOLAPUR
Page 1
ABSTRACT
JMS is known as java massege service for sending massege from two or more client. It is a messaging standard that allows application components based on the Java Enterprise Edition (JEE) to create, send, receive, and read messages. There are two types of JMS model.One is point-to-point model and second is publish and subscribe model.
Page 2
INTRODUCTION
WHAT IS A JMS? VERSION HISTORY GENERAL IDEAS OF MESSAGEING ELEMENTS MODELS MESSAGE SYSTEM TYPES DESIGN GOLAS JMS DETAILS JMS OBJECTIVES WHAT DOES JMS NOT PROVIDE? DEVELOPING A JMS PROGRAM HEADER FILES STANDARD PROPERTIES MASSEGE BODY ADVANTAGES AND DISADVANTAGES OF JMS CONCLUSION
Page 3
Java Message Service

The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914. It is a messaging standard that allows application components based on the Java Enterprise Edition (JEE) to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous.[2] General idea of messaging Messaging is a form of loosely coupled distributed communication, where in this context the term 'communication' can be understood as an exchange of messages between software components. Messageoriented technologies attempt to relax tightly coupled communication (such as TCP network sockets, CORBA or RMI) by the introduction of an intermediary component. The latter approach allows software components to communicate 'indirectly' with each other. Benefits of this include message senders not needing to have precise knowledge of their receivers. The advantages of messaging include the ability to integrate heterogeneous platforms, reduce system bottlenecks, increase scalability, and respond more quickly to change.[3] Version history
JMS 1.0.2b (June 25, 2001)

Page 4
JMS 1.1 (March 18, 2002)
Elements The following are JMS elements: JMS provider An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM. JMS client An application or process that produces and/or receives messages. JMS producer/publisher A JMS client that creates and sends messages. JMS consumer/subscriber A JMS client that receives messages. JMS message An object that contains the data being transferred between JMS clients. JMS queue A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. A JMS queue only guarantees that each message is processed only once. JMS topic A distribution mechanism for publishing messages that are delivered to multiple subscribers.
GOVERNMENT POLYTECHNIC,SOLAPUR Page 5
Models The JMS API supports two models:

Point-to-point Publish and subscribe
Publish/subscribe model The publish/subscribe model supports publishing messages to a particular message topic. Subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber knows about each other. A good analogy for this is an anonymous bulletin board. The following are characteristics of this model:

Zero or more consumers will receive the message. There is a timing dependency between publishers and subscribers. The publisher has to create a message topic for clients to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected will be redistributed whenever it reconnects.
Using Java, JMS provides a way of separating the application from the transport layer of providing data. The same Java classes can be used to communicate with different JMS providers by using the JNDI information for the desired provider. The classes first use a connection factory to connect to the queue or topic, and then use populate and send or publish the messages. On the receiving side, the clients then receive or subscribe to the messages. What is a Messaging System?
In its essence, a messaging system allows separate, uncoupled applications to reliably communicate asynchronously. The messaging system architecture generally replaces the client/server model with a peer-to-peer relationship between individual components, where each peer can send and receive messages to and from other peers. Messaging systems provide a host of powerful advantages over other, more conventional distributed computing models. Primarily, they encourage "loose coupling" between message consumers and message producers. There is a high degree of anonymity between producer and consumer: to the message consumer, it doesn't matter who produced the message, where the producer lives on the network, or when the message was produced. This permits dynamic, reliable, and flexible systems to be built, whereby entire ensembles of sub-applications can be modified without affecting the rest of the system. Other advantages of messaging systems include high scalability (commercial implementations boast the ability to support tens of thousands of clients and tens of thousands of operations per second), easy integration into heterogeneous networks, and reliability due to lack of a single point of failure. Because of the reliable and scalable nature of messaging systems, they are used to solve many business and computing science problems. For example, they are the basis of such diverse applications as workflow, network management, communication services (voice over IP, voicemail, pager, email), customer care, weather forecasting, supply chain management, and many other systems. In addition, messaging systems are also invaluable as "glue" to bring together the disparate systems that inevitably result from mergers and acquisitions.
Message System Types Two messaging systems models are in common use.
Publish/Subscribe A publish/subscribe (pub/sub) messaging system supports an event driven model where information consumers and producers participate in the transmission of messages. Producers "publish" events, while consumers "subscribe" to events of interest, and consume the events. Producers associate messages with a specific topic, and the messaging system routes messages to consumers based on the topics the consumers register interest in. Point-To-Point In point to point messaging systems, messages are routed to an individual consumer which maintains a queue of "incoming" messages. Messaging applications send messages to a specified queue, and clients retrieve messages from a queue. Frequently vendors will support either point-to-point, or publish/subscribe messaging models, or both. Having looked at message systems in general, we now see how Java developers can take advantage of their power. The Java Message Service Java Message Service, part of the J2EE (Java 2 Enterprise Edition) suite, provides standard APIs that Java developers can use to access the common features of enterprise message systems. JMS supports the publish/subscribe and point-to-point models and allows the creation of message types consisting of arbitrary Java objects. Design Goals A fundamental design goal of JMS is to provide a consistent set of interfaces that messaging system clients can use independent of the underlying message system provider. This way, not only are client applications portable across machine architectures and operating systems, they're also portable across
messaging products. Client applications written to JMS will work without modification on all JMS compliant messaging systems. (This can be compared to the independence of Enterprise Java Beans components on the underlying middleware where the components run.) JMS was also designed to:

Minimize the effort required by messaging system providers to implement the JMS APIs for their products. Provide most of the functionality of common messaging systems.
Many messaging system vendors have implemented JMS for their products, allowing Java access to the functionality of their systems. JMS Clients Can Use Java Facilities JMS clients, since they are based on Java, can make use of existing Java APIs such as JDBC for database access, the JavaBeans components model, JNDI for naming services, JTA for client transaction control, or any of the J2SE and J2EE APIs for enterprise application services. JMS Details We now look at the details of building a messaging system client using JMS, starting with messages. What is a Message? In messaging systems the point of communication between applications is the message itself, so a developer using JMS must understand messages.. Although the definition of a message varies greatly between messaging systems, JMS provides a unified means of describing and accessing messages. A JMS message consists of three parts: Message header
For message identification. For example, the header is used to determine if a given message is appropriate for a "subscriber" Properties For application-specific, provider-specific, and optional header fields Body Holds the content of the message. Several formats are supported, including TextMessages, which wrap a simple String; and ObjectMessages, that wrap arbitrary Java objects (which must be serializable). Other formats are supported as well. TextMessages A TextMessage wraps a simple String object. This is useful in situations where only strings are being passed. It is expected that many messaging systems will be based on XML, and TextMessages are a natural container for these. Creation of a TextMessage object is simple, as these two lines of code indicate: TextMessage message = session.createMessage(); message.setText("hello world"); (We'll see the "session" object in the next section.) A TextMessage created in this way is ready to be published to a messaging system.
Page 10
ObjectMessages An ObjectMessage, as its name implies, is a message wrapping a Java object. Any serializable Java object can be used as an ObjectMessage. If multiple objects must be transmitted in a single message, then a Collection object (such as a List or a Set) containing several serializable objects can be used. This is how an Object message is created: ObjectMessage message = session.createObjectMessage(); message.setObject(myObject);
A similar process is followed to create subscribers, as well as JMS clients for point-to-point systems. Complete details of this process can be found in [1]. JMS objectives To better understand JMS, it helps to know the objectives set by the authors of the JMS specification. There are many enterprise messaging products on the market today, and several of the companies that produce these products were involved in the development of JMS. These existing systems vary in capability and functionality. The authors knew that JMS would be too complicated and unwieldy if it incorporated all of the features of all existing systems. Likewise, they believed that they could not limit themselves to only the features that all of the systems had in common. The authors believed that it was important that JMS include all of the functionality required to implement "sophisticated enterprise applications." The objectives of JMS, as stated in the specification, are to:

Define a common set of messaging concepts and facilities. Minimize the concepts a programmer must learn to use enterprise messaging. Maximize the portability of messaging applications. Minimize the work needed to implement a provider. Provide client interfaces for both point-to-point and pub/sub domains. "Domains" is the JMS term for the messaging models discussed earlier. (Note: A provider need not implement both domains.)
What JMS does not provide The following features, common in MOM products, are not addressed by the JMS specification. Although acknowledged by the JMS authors as important for the development of robust messaging applications, these features are considered JMS provider-specific. JMS providers are free to implement these features in any manner they please, if at all:

Load balancing and fault tolerance Error and advisory system messages and notification Administration Security Wire protocol Message type repository
JMS overview and architecture Applications A JMS application comprises the following elements:
JMS clients. Java programs that send and receive messages using the JMS API.
Page 12
Non-JMS clients. It is important to realize that legacy programs will often be part of an overall JMS application, and their inclusion must be anticipated in planning. Messages. The format and content of messages to be exchanged by JMS and non-JMS clients is integral to the design of a JMS application. JMS provider. As was stated previously, JMS defines a set of interfaces for which a provider must supply concrete implementations specific to its MOM product. Administered objects. An administrator of a messaging-system provider creates objects that are isolated from the proprietary technologies of the provider.
Administered objects Providers of MOM products differ significantly in the mechanisms and techniques they use to implement messaging. To keep JMS clients portable, objects that implement the JMS interfaces must be isolated from a provider's proprietary technologies. The mechanism for doing this is administered objects. These objects, which implement JMS interfaces, are created by an administrator of the provider's messaging system and are placed in the JNDI namespace. The objects are then retrieved by JMS programs and accessed through the JMS interfaces that they implement. The JMS provider must supply a tool that allows creation of administered objects and their placement in the JNDI namespace. There are two types of administered objects:
ConnectionFactory: Used to create a connection to the provider's underlying messaging system. Destination: Used by the JMS client to specify the destination of messages being sent or the source of messages being received.
Page 13
Although the administered objects themselves are instances of classes specific to a provider's implementation, they are retrieved using a portable mechanism (JNDI) and accessed through portable interfaces (JMS). The JMS program needs to know only the JNDI name and the JMS interface type of the administered object; no provider-specific knowledge is required. Developing a JMS program A typical JMS program goes through the following steps to begin producing and consuming messages: 1. Look up a ConnectionFactory through JNDI. 2. Look up one or more Destination s through JNDI. 3. Use the ConnectionFactory to create a Connection. 4. Use the Connection to create one or more Session s. 5. Use a Session and a Destination to create the required MessageProducer s and MessageConsumer s. 6. Start the Connection. At this point, messages can begin to flow, and the application can receive, process, and send messages, as required. In later sections, we'll develop JMS programs and you'll get to see this setup in detail. Messages At the heart of a messaging system are, of course, messages. JMS provides several message types for different types of content, but all messages derive from the Message interface. A Message is divided into three constituent parts:
The header is a standard set of fields that are used by both clients and providers to identify and route messages.
Page 14
Properties provide a facility for adding optional header fields to a message. If your application needs to categorize or classify a message in a way not provided by the standard header fields, you can add a property to the message to accomplish that categorization or classification. set<Type>Property(...) and get<Type>Property(...) methods are provided to set and get properties of a variety of Java types, including Object. JMS defines a standard set of properties that are optional for providers to supply. The body of the message contains the content to be delivered to a receiving application. Each message interface is specialized for the type of content it supports.
Header fields The following list gives the name of each header field of Message, its corresponding Java type, and a description of the field:
JMSMessageID -- type string Uniquely identifies each message that is sent by a provider. This field is set by the provider during the send process; clients cannot determine the JMSMessageID for a message until after it has been sent.
JMSDestination -- type Destination The Destination to which the message is sent; set by the provider during the send process.
JMSDeliveryMode -- type int Contains the value DeliveryMode.PERSISTENT or DeliveryMode.NON_PERSISTENT. A persistent message is delivered "once and only once"; a non-persistent message is delivered "at most once." Be aware that "at most once" includes not being delivered at all. A non-persistent message might be lost by a provider during application or system failure. Extra care will be taken to assure that a persistent message is not
Page 15
affected by failures. There is often considerable overhead in sending persistent messages, and the trade-offs between reliability and performance must be carefully considered when deciding the delivery mode of a message.
JMSTimestamp -- type long The time that the message was delivered to a provider to be sent; set by the provider during the send process.
JMSExpiration -- type long The time when a message should expire. This value is calculated during the send process as the sum of the time-to-live value of the sending method and the current time. Expired messages should not be delivered by the provider. A value of 0 indicates that the message will not expire.
JMSPriority -- type int The priority of the message; set by the provider during the send process. A priority of 0 is the lowest priority; a priority of 9 is the highest priority.
JMSCorrelationID -- type string Typically used to link a response message with a request message; set by the JMS program sending the message. A JMS program responding to a message from another JMS program would copy the JMSMessageID of the message it is responding to into this field, so that the requesting program could correlate the response to the particular request that it made.
JMSReplyTo -- type Destination Used by a requesting program to indicate where a reply message should be sent; set by the JMS program sending the message.
JMSType -- type string

Page 16
Can be used by a JMS program to indicate the type of the message. Some providers maintain a repository of message types and will use this field to reference the type definition in the repository; in this case, the JMS program should not use this field.
JMSRedelivered -- type boolean Indicates that the message was delivered earlier to the JMS program, but that the program did not acknowledge its receipt; set by the provider during receive processing.
Standard properties The following list gives the name of each standard property of Message, its corresponding Java type, and a description of the property. Support for standard properties by a provider is optional. JMS reserves the "JMSX" property name for these and future JMSdefined properties.
JMSXUserID -- type string Identity of the user sending the message.
JMSXApplID -- type string Identity of the application sending the message.
JMSXDeliveryCount -- type int Number of times delivery of the message has been attempted.
JMSXGroupID -- type string Identity of the message group to which this message belongs.
JMSXGroupSeq -- type int Sequence number of this message within the message group.
Page 17
JMSXProducerTXID -- type string Identity of the transaction within which this message was produced.
JMSXConsumerTXID -- type string Identity of the transaction within which this message was consumed.
JMSXRcvTimestamp -- type long The time JMS delivered the message to the consumer.
JMSXState -- type int Used by providers that maintain a message warehouse of messages; generally not of interest to JMS producers or consumers.
JMSX_<vendor_name> Reserved for provider-specific properties.
Message body There are five forms of message body, and each form is defined by an interface that extends Message. These interfaces are:
StreamMessage: Contains a stream of Java primitive values that are filled and read sequentially using standard stream operations. MapMessage: Contains a set of name-value pairs; the names are of type string and the values are Java primitives. TextMessage: Contains a String. ObjectMessage: Contains a Serializable Java object; JDK 1.2 collection classes can be used.
Page 18
BytesMessage: Contains a stream of uninterpreted bytes; allows encoding a body to match an existing message format.
Each provider supplies classes specific to its product that implement these interfaces. It is important to note that the JMS specification mandates that providers must be prepared to accept and handle a Message object that is not an instance of one of its own Message classes. Although these "alien" objects might not be handled by a provider as efficiently as one of the provider's own implementations, they must be handled to ensure interoperability of all JMS providers.
Advantages and Disadvantages of a Messaging System In the messaging service (or system), there is a server, and clients connect to this server to communicate with each other The messaging service architecture. The server provides some essential services such as message persistence, load balancing, and security. The server provides asynchronous communication and guaranteed delivery from senders to receivers. A messaging service is a great way for applications to communicate with each other, but it has some disadvantages:
You have to send header and other information with the message content. Therefore, the total amount of information is larger than the message content itself, which might increase network traffic. Every message goes to the receivers through a server, which makes communication slower than a direct connection. Your messaging service provider (vendor) might not support all the JMS specifications defined by Sun Microsystems.
Before designing your JMS projects, you should compare the disadvantages such as network traffic, slower communication, and
vendor-specific issues with the advantages such as loosely coupled or decoupled systems, portability, persistent messaging, and guaranteed delivery. Briefly, if you only need to insert some new records into a local database and you have a very reliable network, you might not need to use a messaging system. Keep in mind that a messaging-based application consumes additional resources. However, if you want to isolate networking problems in your client source code or if the database you want to access is in a different location, you might need to use a messaging service. A messaging service can ensure completion of transactions of an application properly such as manipulating data in a table of the database (for example, Insert, Delete, and Update statements), particularly if the database is unavailable (such as when using a laptop that is disconnected from the network). It will process the command (the message content) at a later time. Decoupling or loosely coupling is the best feature of a messaging service.
Page 20
Conclusion JMS provides a standard enterprise messaging system for J2EE applications. The WebLogic Server provides a robust and highperformance version of JMS and includes a number of JMS extensions. JMS is often used in conjunction with other J2EE APIs to build a complete enterprise application. The EJB 2.0 specification includes message-driven EJBs, which are an integration between JMS and EJB.
Page 21

Government Polytechnic, Solapur: Department of Computer Technology

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Government Polytechnic, Solapur: Department of Computer Technology

Uploaded by

Copyright:

Available Formats

JAVA MESSAGE SERVICE