Java Messaging Services

1. Java Messaging Services Presentation By Anurudh Gupta

2. Agenda • Introduction • What is Messaging • History • Problems Messaging solves • JMS API Architecture • JMS API Programming Model • JMS XML Pairing • JMS with J2EE • Limitations • Sample Demo

3. Messaging Messaging means that programs communicate with each other by sending data in message and not calling each other directly Messaging middleware It isa software that allows two entities to communicate by sending and receivingmessages. In the same way that today’s e-mail systems allow communication between two or more people, Messaging allows communication among two or more applications, without requiring human intervention. Theseapplications can reside independently on a wide variety of hardware devices.

4. One of the most fundamental aspects of messaging is its asynchronous nature- the sender of the message does nothave to wait for the recipient to receive the information.

5. History Messaging technologies have been with us since the 1970s when they were used primarily to facilitatecommunication among back-office mainframe applications running on dedicated network connections. Themessaging paradigm has become popular again due to changing business practices and technological advancessuch as the widespread acceptance of the Internet , and theproliferation of mobile networked devices such as laptop PCs, handheld digital assistants, and other web-enabledinput devices.

6. What problems does messaging solve? • Disparate system integration • Exchanging information with business partners • Automating common business functions • Challenges of building next generation applications

7. Messaging to automate business functions 1.Price discount 3. Check Inventory 2.check business rules 4.Place Order Ware house Inventory Manufacture Retail Outlet

8. Challenges of building next generation applications Automobile Manufacturer B Automobile Manufacturer A Automotive e-marketplace Parts Supplier W Parts Supplier Y Parts Supplier X Parts Supplier Z

9. Global Business transactions Canada USA Brazil Americas UK China Asia/Pac Europe India Korea France Germany

10. Messaging is not the only way RPC –based mechanism • CORBA • JAVA RMI • MICROSOFT DCOM

11. Application Client Application Client ? Application Client Application Client Application Client Application Client Tightly Coupled RPC Based Architecture

12. Application Client Message Server Application Client Application Client Application Client Application Client Loosely Coupled Messaging Based Architecture

13. Java Messaging Service • The Java Message Service is a Java API that allows applications to create, send,receive, and read messages. • Designed by Sun and several partner companies, theJMS API defines a common set of interfaces and associated semantics that allowprograms written in the Java programming language to communicate with othermessaging iimplementations. • The JMS API minimizes the set of concepts a programmer must learn to usemessaging products, but provides enough features to support sophisticated messagingapplications. It strives to maximize the portabilityof JMS applicationsacross JMS providers in the same messaging domain. • The JMS Specification was first published in August 1998. The latest versionof the JMS Specification is Version 1.0.2b

14. Key JMS features • Flexible programming model • Publish/Subscribe • Point –To- Point • Resilience • Flexible event- based mechanisms • Transaction support • Subject-based routing

15. JMS API Architecture • A JMS application is composed of the following parts: • AJMS provideris a messaging system that implements the JMS interfaces andprovides administrative and control features. An implementation of the J2EEplatform at release 1.3 and above includes a JMS provider. • JMS clientsare the programs or components written in the Java programminglanguage that produce and consume messages. • Messagesare the objects that communicate information between JMS clients.

16. Administered objectsare preconfigured JMS objects created by an administratorfor the use of clients. There are two kinds of administered objects • Destinations • Connection factories • Native clientsare programs that use a messaging product’s native client APIinstead of the JMS API. If the application was originally created before theJMS API became available, it is likely to include both JMS and native clients.

17. Messaging Domains • Point-to-Point Messaging Domain A point-to-point (PTP) product or application is built around the concept of messagequeues, senders, and receivers. Each message is addressed to a specific queue, andreceiving clients extract messages from the queue(s) established to hold their mes-sages.

18. Potential Receiver Sender Queue Potential Receiver Message Broker Point-to-Point Messaging

19. PTP messaging has the following characteristics • Each message has only one consumer. • There are no timing dependencies between a sender and a receiver of a message. • The receiver can fetch the message whether or not it was running whenthe client sent the message. • The receiver acknowledges the successful processing of a message.

20. Publish/Subscribe Messaging Domain In a publish/subscribe (pub/sub) product or application, clients address messages toa topic. Publishers and subscribers are generally anonymous and may dynamicallypublish or subscribe to the content hierarchy. The system takes care of distributingthe messages arriving from a topic’s multiple publishers to its multiple subscribers.

21. Subscriber Publisher Topic Subscriber Message Broker Publish /Subscribe Messaging

22. Pub/Sub messaging has the following characteristics • Each message may have multiple consumers. • There is a timing dependency between publishers and subscribers, because aclient that subscribes to a topic can consume only messages published after theclient has created a subscription, and the subscriber must continue to be activein order for it to consume messages.

23. The JMS API relaxes this timing dependency to some extent by allowingclients to create durable subscriptions. • Durable subscriptions can receive messagessent while the subscribers are not active. • Durable subscriptions provide theflexibility and reliability of queues but still allow clients to send messages to manyrecipients.

24. Message Consumption • Messaging products are inherently asynchronous in that there is no fundamentaltiming dependency between the production and consumption of a message. However, the JMS Specification uses this term in a more precise sense

25. Messages can beconsumed in either of two ways: Synchronously: Asubscriber or a receiver explicitly fetches the message fromthe destination by calling the receive method. The receive method can blockuntil a message arrives, or it can time out if a message does not arrive within aspecified time limit. Asynchronously: A client can register a message listener with a consumer. Amessage listener is similar to an event listener. Whenever a message arrives atthe destination, the JMS provider delivers the message by calling the listener’s onMessage method, which acts on the contents of the message.

26. The JMS API Programming Model • THE basic building blocks of a JMS application are • Administered objects (Connection factories and Destinations) • Connections • Sessions • Message producers • Message consumers • Messages

27. Connection Factory Creates Connection Creates Message Producer Message Consumer Session Creates Creates Receives From Creates Sends to Message Destination Destination

28. Connection Factories A Connection factoryis the object a client uses to create a connection with a provider. A connection factory encapsulates a set of connection configuration parametersthat has been defined by an administrator. Context ctx = new InitialContext(); QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup(“QueueConnectionFactory”);

29. Destinations A destination is the object a client uses to specify the target of messages it producesand the source of messages it consumes. In the PTP messaging domain, destinations are called queues In the pub/sub messaging domain, destinations are called topics,

30. Connections A connection encapsulates a virtual connection with a JMS provider. It could representan open TCP/IP socket between a client and a provider service daemon. We use a connection to create one or more sessions. Like connection factories, connections come in two forms: they implementeither the QueueConnectionor the TopicConnection interface.

31. Sessions A session is a single-threaded context for producing and consuming messages. We use sessions to create message producers, message consumers, and messages. Sessions serialize the execution of message listeners; Public javax .jms.[Topic/Queue] Session createSession(boolean transacted,int acknowledgeMode)

32. Session.AUTO_ACKNOWLEDGE: The session automatically acknowledges a client’sreceipt of a message either when the client has successfully returned froma call to receive or when the MessageListener it has called to process the mes-sagereturns successfully. • Session.CLIENT_ACKNOWLEDGE: A client acknowledges a message by callingthe message’s acknowledge method. In this mode, acknowledgment takesplace on the session level: acknowledging a consumed message automaticallyacknowledges the receipt of all messages that have been consumed by its session. • Session.DUPS_OK_ACKNOWLEDGE: This option instructs the session to lazily acknowledgethe delivery of messages. This is likely to result in the delivery ofsome duplicate messages if the JMS provider fails, so it should only be usedby consumers that can tolerate duplicate messages.

33. Message Producers A message produceris an object created by a session that is used for sending messagesto a destination. The PTP form of a message producer implements the QueueSenderinterface. The pub/sub form implements the TopicPublisher interface. queueSender.send(message); topicPublisher.publish(message);

34. Message Consumers A message consumeris an object created by a session that is used for receiving messagessent to a destination A message consumer allows a JMS client to register interest in a destinationwith a JMS provider. The JMS provider manages the delivery of messages from a destination to the registered consumers of the destination. The PTP form of message consumer implements the QueueReceiver interface. The pub/sub form implements theTopicSubscriber interface.

35. Message Listeners A message listeneris an object that acts as an asynchronous event handler for messages. It implements the MessageListenerinterface, which contains one method,onMessage.In theonMessage method, we define the actions to be taken when amessage arrives.

36. Message Selectors If our messaging application needs to filter the messages it receives, we can use aJMS API message selector, which allows a message consumer to specify the messagesit is interested in. Message selectors assign the work of filtering messages tothe JMS provider rather than the application.

37. Messages A JMS message has three parts, which are • Header • A JMS message header contains a number of predefined fields, which containvalues that both clients and providers use to identify and route messages. • Properties (optional) • You can create and set properties for messages if you need values in addition tothose provided by the header fields. You can use properties to provide compatibilitywith other messaging systems, or you can use them to create message selectors

38. A body (optional) The JMS API defines five different message body formats, also called messagetypes, which allow you to send and receive data in many different forms, and whichprovide compatibility with existing messaging formats.

39. Message Type Body Contains • TextMessage A java.lang.String object (for example, the contents of an eXtended Markup Language file) • MapMessage A set of name-value pairs, where names are String objects, and values are primitive types in the Java programming language. • BytesMessageA stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format. • StreamMessageA stream of primitive values in the Java programming language.It is filled and read sequentially. • ObjectMessageA Serializable object in the Java programming language • Message Composed of header fields and properties only. This • message type is useful when a message body is not required.

40. Message Persistence • A persistent message is guaranteed to be delivered at least once-it is not considered sent until it has been safely written in the file or database. • Non-persistent messages are not stored. They are guaranteed to be delivered at least once unless there is a system failure, in which case messages may be lost

41. Weblogic Implementation

42. JMS XML Pairing XML Message Type ? • In practice XML messages can be placed in TextMessage messages • The pairing of XML and Java messaging promotes highly flexible designs that can better accommodate the rapid change that distributed system face in today’s business environment • Data represented in XML is polymorphic i.e same data can be used in variety of contexts

43. JMS with J2EE • When the JMS API was first introduced in 1998, its most important purpose was toallow Java applications to access existing messaging-oriented middleware (MOM)systems, such as MQSeries from IBM • Since that time, many vendors have adopted and implemented the JMS API,so that a JMS product can now provide a complete messaging capability for an enterprise.

44. At the1.3 release of the J2EE platform(“the J2EE 1.3 platform”), the JMS API is an integral part of the platform, and application developers can use messaging with components using J2EE APIs (“J2EE components”). • The JMS API in the J2EE 1.3 platform has the following features: • Application clients, Enterprise JavaBeans ™ (EJB ™ ) components, and webcomponents can send or synchronously receive a JMS message. • Applicationclients can in addition receive JMS messages asynchronously. • A new kind of enterprise bean, the messagedriven bean, enables the asynchronousconsumption of messages. • A JMS provider may optionally implementconcurrent processing of messages by message-driven beans. • Message sends and receives can participate in distributed transactions.

45. Limitations • Integration with Legacy Messaging System(Vendor Dependent) • Does not address wire protocols and non JMS message interchange • It doesn't dictate a security model beyond a simple username and password at connection time

46. Where Can We Use JMS • The provider wants the components not to depend on information about othercomponents’ interfaces, so that components can be easily replaced. • The provider wants the application to run whether or not all components are upand running simultaneously. • The application business model allows a component to send information to anotherand continue to operate without receiving an immediate response.

47. JMS Implementations • Allaire Corporation - JRun Server • BEA Systems, Inc. • Brokat Technologies (formerly GemStone) • IBM • iPlanet (formerly Sun Microsystems, Inc. Java Message Queue) • Oracle Corporation • Pramati • SilverStream Software, Inc. • Sonic Software • SpiritSoft, Inc. (formerly Push Technologies Ltd.) • Talarian Corp. • TIBCO Software, Inc. • FioranoMQ,

48. IBGen Scenario • Demo Timer Change in Properties Notifies Weblogic Message Queue Client Sends a message ReceivesMessage Generate XML

49. Links • http://java.sun.com/products/jms/ • http://www.sonicsoftware.com/

50. Thanks(for the patience)