XML Messaging Using JBoss

It's common practice to share data using FTP, but an increasingly popular
alternative is to use a messaging service. As always, each approach
has its own pros and cons, depending on the nature of "what
to share," how easy it is to implement the technology, the need to use an
asynchronous process, etc.

In this article, I will focus on data sharing, with the common
producer-consumer model, using open source software such as:

The interactions between them are managed by
Java Management Extensions (JMX).
Please refer to their respective home pages if you are unfamiliar with these frameworks.

As for the Java Messaging Service (JMS)
provider, you can choose either WebSphere MQ or JBossMQ.
This is fully configurable in the jboss-service.xml file provided.
By using JMS, your application becomes "loosely coupled." Some benefits of using it are:

Messages can be prioritized.

Messages can be delivered synchronously or asynchronously.

Messages are guaranteed to be delivered.

This article is about how to use the set of open source tools
listed above, not about why I choose them, nor why I need them.
There are obviously a million and one different ways to deal with
the producer-consumer model. The idea behind using JMX is to have a more flexible
"federated" approach, so that different functions are handled by
different processes.

Case Study

Consider the following hypothetical scenario. We want to share two
different kinds of data, coming from two different applications and two
different data sources. One application (AppSource1) uses an Oracle
database and needs to share a subset of its business contact data. Another
application (AppSource2) uses a Sybase database and needs to share a subset
its currency data.

The data is shared at specific times:

From 08:00 to 18:00, daily, for the contact data

Every minute, daily, for the currency data.

The contact data, persisted in an interface table named IProducerContact,
is managed and controlled by the application AppSource1. The currency data
is persisted in an interface table, IProducerCcy, by the application
AppSource2. Both AppSource1 and AppSource2
are the producers.

The producers extract the data from the interface tables IProducerContact and IProducerCcy
and then send the data, in an XML format, to a JMS server.
The consumer processes each incoming message, which then populates two interface tables, IConsumerContact
and IConsumerCcy. Once in the interface tables, AppTarget is responsible for
extracting the data from them into the master database.

Figure 1 below depicts this scenario:

Figure 1. Flow of messages

JMX in JBoss

JMX is an optional package for J2SE that provides a standard set of interfaces and enables you to add management capabilities to your
applications. It allows developers to write more modular and loosely
coupled system components and reduce the complexity of large,
interoperating systems.

The core component of JMX is the managed bean, or MBean. A standard
MBean is a Java class that implements an interface, which has the
following characteristics:

Once you have defined your MBean and the XML file service, then you
can package them into a .sar file. This service archive file is ready
to be deployed into JBoss server.

Let's find out what happens when you deploy an MBean.
The sequence of an MBean initialization is in this order:

Call the constructor of the MBean.

Call the setter methods.

Call the startService() method.

When you delete or override the .sar file--or stop the JBoss
server, but you may not want to do this--the stopService() method is
called. This is the appropriate place to do clean-up operations,
like closing all open connections or sessions.

You can define a dependency between one MBean with another MBean by
using the depends tag:

In this example, the ProducerManager MBean depends on the MOMManager MBean
and DBManager MBean.

Again, what happens if you deploy a .sar file with the above file service? Here is the sequence:

Call the ProducerManager() constructor.

Call the setter method in ProducerManger (setOracle(), in this instance).

Call the MOMManager() constructor.

Call the setter method in MOMManager.

Call the DBManager() constructor.

Call the setter method in DBManager.

Call the startService() method in DBManager.

Call the startService() method in MOMManager.

Call the startService() method in ProducerManger.

When you delete or override that .sar file, here is the sequence:

Call the stopService() method in ProcedureManager.

Call the stopService() method in MOMManager.

Call the stopService() method in DBManager.

Note: Take a look at the order. When you have a dependency, the order is important.

The next thing that we need to know is how to call a method in
an MBean from another MBean. Given the file service mentioned above, how
the MOMManager MBean call a method in DBManager MBean?
The key is to use the invoke() method, such as:

The javax.management.MBeanServer.invoke() method is
powerful and can invoke methods of any given complexity by providing details about the method parameter signature and supplying the parameter values.

Note: The yourMethod() method must be defined in your MBean
interface and implemented in your MBean class.