VIEWS: 0 PAGES: 44 POSTED ON: 4/3/2013
Messaging in Java 24.04.2012 Rafał Witkowski Marek Kałużny Agenda Enterprise Application Integration Messaging Overview JMS Architecture DEMO(s) 1. Instant Messaging 2. Chat Enterprise Application Integration Enterprise Application Integration The need of integration ... Enterprise Application Integration Integration Challenge Systems that need to be linked together very often: - reside on different operating systems - use different database solutions and different computer languages - are legacy systems that are no longer supported by the original vendor Enterprise Application Integration EAI definition, by Gartner Group „Unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.” Messaging plays a key role in heterogeneous integration area Messaging Overview What’s messaging? • Messaging approach will mean that two or more applications will exchange information in the form of messages. • A message is a self-contained package of business data and network routing headers. • The business data contained in a message can be anything - usually contains information about some business transaction. • Messages inform an application of some event or occurrence in another system. Message-Oriented Middleware Message-Oriented Middleware • Allows two or more applications to exchange information in the form of messages • Provides a mechanism for integrating applications in a loosely coupled, flexible manner. • Provide asynchronous delivery of data between applications on a store and forward basis. The applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary. • Provides assured delivery of messages and relieves application programmers from knowing the details of remote procedure calls (RPC) and networking/communications protocols. • Usually provide fault tolerance, load balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages. Centralized architecture Typically, a centralized architecture uses a hub-and- spoke topology. There is one centralized message server and all clients connect to it. Message Oriented Middleware Vendors • Open Source • Apache ActiveMQ • Glassfish Open Message Queue • Object Web JORAM • Commercial • BEA Systems MessageQ • IBM MQSeries • TIBCO Rendezvous Software Bus • Progress SonicMQ • Microsoft MSMQ Messaging c.d. • Applications exchange messages through virtual channels called destinations. • Message being sent is addressed to a destination not a specific application. • Any application that subscribes or registers an interest in that destination may receive the message • Destination can be either a queue or a topic that correspond to communication model Messaging Models 1. Point to Point 2. Publish and Subscribe Point to Point • Allows JMS clients to send and receive messages both synchronously and asynchronously via virtual channels known as queues. • Message producers are called senders and message consumers are called receivers. • Messages sent to a queue are received by one and only one receiver, even though there may be many receivers listening on a queue. Point to Point • Point-to-point messaging supports asynchronous “fire and forget” messaging as well as synchronous request/reply messaging. • The point-to-point model supports load balancing, which allows multiple receivers to listen on the same queue, therefore distributing the load. • JMS provider takes care of managing the queue, ensuring that each message is consumed once and only once by the next available receiver in the group. • Point-to-point also offers other features, such as a queue browser that allows a client to view the contents of a queue prior to consuming its messages—this Publish and Subscribe • Messages are published to a virtual channel called a topic. • Message producers are called publishers, whereas message consumers are called subscribers. • Messages published to a topic using the publish-and- subscribe model can be received by multiple subscribers • Every subscriber receives a copy of each message – message is broadcasted. Publish and Subscribe • The pub/sub model tends to be more decoupled than the p2p model in that the message publisher is generally unaware of how many subscribers there are or what those subscribers do with the message. • Nondurable subscribers are temporary subscriptions that receive messages only when they are actively listening on the topic. • Durable subscribers will receive a copy of every message published, even if they are “offline” when the message is published. JMS Architecture What is JMS? The Java Message Service specification 1.1 states: “JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.” Java Message Service c.d. • JMS provides a standard, portable way for Java programs to send and receive messages through a MOM product • Programs written with JMS can run on any MOM that implements the JMS standard. • Portability - JMS API is provided by Oracle as a set of interfaces, MOM providers implement these interfaces. • As a developer, you build a JMS application by defining a set of messages and a set of client applications that exchange those messages. JMS Objectives • 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. What JMS does not provide 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 Application Components • JMS clients. Java programs that send and receive messages using the JMS API. • 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. Supplied concrete implementations of JMS interfaces specific to given 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 • JMS Portability – objects that implement the JMS interfaces must be isolated from a provider’s proprietary technologies (which is achieved by administered objects). • Administered Objects that implement JMS interfaces, are created by an administrator of provider’s messaging system and are placed in the JNDI namespace. Administered Objects c.d. 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. Administered objects are retrieved using a portable mechanism (JNDI) and accessed through portable interfaces (JMS). Message Message is divided into three constituent parts: • The header is a standard set of fields that are used by both clients andvproviders to identify and route messages. • Properties provide a facility for adding optional header fields to a message. • 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. Message types • 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 • BytesMessage: Contains a stream of uninterpreted bytes; allows encoding a body to match an existing message format. JMS Interfaces JMS Common Interface Peer to Peer Publish and Subscribe ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher QueueReceiver, MessageConsumer TopicSubscriber QueueBrowser JMS Interfaces ConnectionFactory ConnectionFactory is an administered object that is retrieved from JNDI to create a connection to a provider. It contains a createConnection() method, which returns a Connection object. JMS Interfaces Connection Connection encapsulates an active connection to a provider. Methods: • createSession(boolean, int): Returns a Session object. The boolean parameter indicates whether the Session is transacted or not; the int indicates the acknowledgment mode. • start(): Activates the delivery of messages from the provider. • stop(): Temporarily stops delivery of messages; delivery can be restarted with start(). • close(): Closes the connection to the provider and releases all resources held in its behalf. JMS Interfaces Session Session is the single-threaded context for sending and receiving messages. Methods: • createProducer(Destination): Returns a MessageProducer object to send messages to the specified Destination. • createConsumer(Destination): Returns a MessageConsumer object to receive messages from the specified Destination. • commit(): Commits all consumed or produced messages for the current transaction. • rollback(): Rolls back all consumed or produced messages for the current transaction. • create<MessageType>Message(...): A variety of methods that return a <MessageType>Message JMS Interfaces Destination Destination encapsulates a destination for messages. It is an administered object that is retrieved from JNDI. JMS Interfaces MessageProducer MessageProducer is used to send messages. Methods: • send(Message): Sends the indicated Message. • setDeliveryMode(int): Sets the delivery mode for subsequent messages sent; valid values are DeliveryMode.PERSISTENT and DeliveryMode.NON_PERSISTENT. • setPriority(int): Sets the priority for subsequent messages sent; valid values are 0 through 9. • setTimeToLive(long): Sets the duration before expiration, in milliseconds, of subsequent messages sent. JMS Interfaces MessageConsumer MessageConsumer is used to receive messages. Methods: • receive(): Returns the next message that arrives; this method blocks until a message is available. • setMessageListener(MessageListener): Sets the MessageListener; the MessageListener object receives messages as they arrive, that is, asynchronously . JMS Interfaces MessageListener MessageListener is an interface with a single method -- onMessage(Message) -- that provides asynchronous receipt and processing of messages. This interface should be implemented by a client class and an instance of that class passed to the MessageConsumer object with the setMessageListener(MessageListener) method. As a message arrives at a destination, it is passed to the object with the onMessage(Message) method. Developing JMS Client 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. Simple scenario – MessageSender 1. Retrieve JMS Administered Objects from JNDI repository Simple scenario – MessageSender 2. Create required JMS objects 3. Send message Simple scenario – MessageReceiver 1. Create message receiver. Simple scenario – MessageReceiver 2. Implement receiver interface. 3. Implement receiving method. DEMO REFERENCES • Java Message Service, 2nd edition, Mark Richards, Richard Monson-Haefel, and David A. Chappell by O’Reilly • Introducing the Java Message Service, Willy Farrell by IBM • JMS 1.1 Specification, by Oracle Thank you!