Java EE 6 with Fine Beers - Beer 1

This is the first of several articles reporting my experiences while migrating an enterprise  application to Glassfish V3.

This post will cover one specific migration challenge: A partial migration supported by remote JMS connections.

Thank God there is Loose Coupling

About one year and half ago, in order to amend a diversity of integrations with on-line services of our business partners, I preferred to modularize the architecture by controlling slave integration modules with JMS. That's the way I designed and how it was implemented:

Once the slave modules have straightforward responsibilities they were chosen to be moved first to the new home. The plan was to keep the main application in the old Glassfish for a while, using JMS to communicate.

The question is:  How to configure MessageDriven Beans (V3 hosted) to consume from remote (V2 hosted) destinations ?

I was not able to find all the answers in Glassfish documentation. Indeed it gave me good directions, and it was helpful as reference. Interestingly the solution was clearly found in Java EE 5 tutorial, that depicts the issue of remote JMS resources using Glassfish:
An Application Example That Consumes Messages from a Remote Server.

Here is the bottom line of the configuration:

• The original Connection Factory and the original destinations are kept in V2.
• A "proxy" connection factory is created in V3, using the same name and referencing the original one, through AddressList property.
• The JMS destinations used by slaves were duplicated (dummy, same jndi name) in V3.
• In Glassfih, MDBs had to configured to use to a specific connection factory (the proxy) with sun-ejb-jar.xml, the proprietary deployment descriptor

The proxy connection factory can be created in V3 using CLI (asadmin):

create-jms-resource --property AddressList=V2-host-ip --restype javax.jms.ConnectionFactory remote-connection-factory-jndi-name

The sun-ejb-jar.xml files have to be provided as follow:
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>logical-mdb-name</ejb-name>
<mdb-connection-factory>
<jndi-name>remote-connection-factory-jndi-name</jndi-name>
</mdb-connection-factory>
</ejb>
</enterprise-beans>
</sun-ejb-jar>

Conclusions

• The main application doesn't need a change, it will continue to use its original JMS resources.
• Slave Modules only needed to include configurations in sun-ejb-jar.xml, with no source code changes.
• At the time that main application moves to V3 the only thing we need is to remove the AddressList property, turning the proxy connection factory into a real one.
• As a positive side effect of this partial migration scenario, we improved scalability, hosting components into different servers.

Last but Not Least
As I had promised let's celebrate this migration move with a nice Brazilian beer:

Eisenbahn (Rail Road, in German)

Type: Pilsen
Price: $$
Website: http://www.eisenbahn.com.br
Harmonizes with:  Sea Food, Some kinds of cheese: Brie, Camembert, Gruyère, Emmental