Messaging

advertisement
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-andspoke 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-andsubscribe 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 messagingsystem 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
MessageConsumer
QueueReceiver,
QueueBrowser
TopicSubscriber
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.
2.
3.
4.
5.
Look up a ConnectionFactory through JNDI.
Look up one or more Destination s through JNDI.
Use the ConnectionFactory to create a Connection.
Use the Connection to create one or more Session’s.
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!
Download