sábado, 23 de mayo de 2015

JMS Encapsulation

How many times have you implemented JMS? There are quite a lot Message Oritented Middleware (MOM) based architectures out there or if not at least JMS communication is required.This leads you to implement JMS everytime you need. It might be within the same system between different components or if you finish a project and move to another one, sometimes you reimplement JMS.

Spring offers a great JMS template that does all the plumbing for us but still you need to reimplement some features.

I decided to create this JMS Wrapper and to give it some key communication responsibilities. For instance, how many times have you deal with a JMS broker failure and the client is not configured as fault tolerant? I talked to management and the different areas within the Mexican Stock Exchange (BMV) that use JMS and the idea was pretty welcome. I read quite a lot about JMS and ended up implementing this JMS Wrapper to fit basic communication needs.

In terms of software architecture, this is a component that acts as a connector. Communication responsibilities are delegated to this component, some availability features, like reestablishing communication once JMS broker is alive, are key responsibilities and of course, encapsulation. You define through the main interface the functional responsibilities without coupling with a JMS provider. Features are responsibilities of this JMS Wrapper not part of the JMS Provider, so if a broker does not implement a responsibility you may extend this JMS Wrapper in order to provide it. Again, you avoid coupling with the JMS provider.

This JMS Wrapper was originally implemented to be used only within the BMV systems. After some chats to management we decided to open source it. Someone might need it!

Feel free to fork it!
https://github.com/gusvmx/BmvMQ

I implemented the .Net version as well. I'm gonna publish it soon