Message-Oriented
Middleware
The
message-oriented middleware became widely used when providers created
architectures that could operate in a standard way on a variety of platforms
and enabled asynchronous communication between applications. These
providers gained popularity in enabling integration of mainframes and personal
computers.
Even
though there is much competition and variety in message-oriented middleware
products, they tend to fall into one of the following categories:
•Point-to-point
•Publish/Subscribe
•Request-reply
JMS Messaging Models
JMS
supports the point-to-point (PTP) and Publish/Subscribe
messaging
models. The models are very similar, except the following:
•The
PTP messaging model enables delivery of a message to exactly one recipient.
•The
Publish/Subscribe messaging model enables delivery of a message to multiple
recipients.
Request-reply
messaging model is more suited in a synchronous messaging environment where the
requester and replier are in conversational mode—the
requester
waits for a response from the replier before continuing work. It is not
explicitly supported in JMS.
Point-To-Point
Queue
When
using a PTP queue, multiple message producers can put messages onto a single
queue. The queue serializes the messages in a linear order. Multiple receivers
can take messages off the queue; the messages typically come off in a first-in,
first-out (FIFO) order; the oldest message on the queue is the first one to be
taken off.
A
message can be delivered only to one receiver. Receivers are also referred to
as consumers.
An
example of when to use a PTP queue would be at a call center.
•Calls
are routed into the network through a PBX. The PBX system places incoming calls
onto an Incoming Calls queue. When a service representative is available, the
representative requests for the next caller in the system.
•The
system pulls off the queue the caller who has been waiting the longest (FIFO
method) and routes the caller to the service representative.
•After
the conversation is established between an in-queue customer and a
representative, it becomes a synchronous communication. (This is similar to
request-reply mode).
This
is only an example and, in many cases, the responses are not just pure FIFO but
weightings assigned by the organizations.
Publish/Subscribe
Topics
Having
the publishers publish to a topic rather than directly to a list of subscribers
decouples the publishers and subscribers.
By
doing this, a publisher is not required to manage the number of subscribers (if
any) that must receive the message. By delegating the message delivery work to
the message-oriented middleware server (which manages the topic), the publisher
does not have to manage the delivery of guaranteed messages, fault tolerance of
its production, load balancing, or other issues. By decoupling a subscriber
from the publisher, the subscriber does not have to determine whether its
publisher is active. If the message-oriented middleware server is executing,
the needs of both the publishers and the subscribers are met.
An
example of using a Publish/Subscribe topic is a stock ticker application.
•A
typical system would set up a topic for each stock that is traded on the
exchanges.
•When
a trade is made on a stock, the respective exchange publishes a message to the
topic that is associated with the stock traded.
•Clients
who are interested in receiving updates about the status of their stocks use a
program to subscribe to the topics of each stock they are interested in.
•When
the topic update is recognized, the message server broadcasts the message to
all the interested (clients) stock ticker programs.
Oracle
WebLogic Server JMS Features
An
enterprise messaging system enables applications to asynchronously communicate
with one another through the exchange of messages. A message is a request,
report, and/or event that contains information needed to coordinate
communication between different applications. A message provides a level of
abstraction, which allows you to separate the details about the destination
system from the application code.
The
Oracle WebLogic Server implementation of JMS fully supports the point-to-point
and Publish/Subscribe models of the messaging middleware.
Oracle
WebLogic Server also provides acknowledgement-based (ACK) guaranteed message
delivery (GMD) by enabling persistent storage of messages until the receiver of
the message issues an acknowledgement of receipt.
Oracle
WebLogic Server JMS uses its built-in support for JDBC and JDBC connection
pools to persist JMS messages in a database.
Oracle
WebLogic Server supports transactional message delivery. Transactional message
delivery gives the developer the ability to put a JMS session into a
transaction context. In Oracle WebLogic Server JMS, the message is not visible
or available for consumption until the transaction is committed. A session can
optionally roll back the transaction, which has the transaction “drop” the
messages it had previously buffered.
Oracle
WebLogic Server allows clients to register themselves as durable subscribers. A
durable subscriber is a client that expects to receive all persistent messages
that are sent to a particular destination, whether the client is currently
executing or not. If the durable subscriber is not currently executing, Oracle
WebLogic Server stores the messages in a persistent store until the durable
subscriber reactivates and retrieves the stored messages.
Oracle
WLS JMS Architecture
The
major components of the WebLogic JMS Server architecture include:
•JMS
servers that can host a defined set of modules and any associated persistent
storage that resides on a WebLogic Server instance. JMS server configuration is
stored in the domain config.xml
file.
•JMS
modules that contain configuration resources (such as queues, topics, and
connections factories) and are defined by XML documents that conform to the weblogic-jms.xsd
schema
•Client
JMS applications that either produce messages to destinations or consume
messages from destinations
•Java
Naming and Directory Interface (JNDI), which provides a resource lookup
facility. JMS resources such as connection factories and destinations are
configured with a JNDI name. The run-time implementations of these resources
are then bound to JNDI using the given names.
•WebLogic
persistent storage (file store or JDBC-accessible) for storing persistent
message data
Typical
JMS Messaging Process
In
JMS implementations, developers use a connection factory to enable their
applications to connect to a queue or topic.
A
connection factory is a lightweight object stored on a Java Naming and
Directory Interface (JNDI) tree that is used to create connections to
destinations. A connection is a communication link to the JMS server that is
used to create sessions.
A
session is used to create senders, receivers, and empty messages. A session is
also used to demarcate transactions.
Destination,
a lightweight object stored on JNDI, is the target for the messages.
Transacted
Messaging
JMS
clients can participate in a distributed or local transaction. There are two
scenarios:
•On
the Producer side, a transaction begins and some operations, such as sending
messages, are performed. If the transaction commits, all the messages are sent
to the destination. If the transaction rolls back, none of the messages arrive
at the destination.
•On
the Consumer side, a transaction begins and some operations, such as processing
messages, are performed. If the transaction commits, the processed messages are
removed from the destination. If the transaction rolls back, the messages stay
in the destination.
JMS
Administrative Tasks
As
an administrator, you are responsible for configuring and monitoring most
aspects of JMS.
The
architecture of your system determines the type of JMS destinations to
configure. It is your responsibility to monitor the Oracle WebLogic Server JMS
and gather statistics. All these administrative tasks are discussed throughout
this lesson.
Oracle
WLS JMS Implementation
When
you implement JMS in WLS, you configure the following JMS resources:
•Configure
the necessary JMS servers and target them to the appropriate managed servers.
•Configure
JMS modules.
•Within
the JMS modules, you define the queue or topic resources.
•Then
using the subdeployment definitions, target the queues to the appropriate JMS
servers.