Mashed Articles

JMS or Java Message Service is the basis and standard API for asynchronous, reliable messaging.

After 10 years, a new (2nd) edition of the book “Java Message Service” was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.

Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.

Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),

Messaging solutions are still the core backbone for many ESB’s and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.

For people less acquainted with the Integration world, the word Bus in “Enterprise Service Bus” causes many to believe that an ESB is something distributed. But on the contrary, 95% of ESB deployments are hub and spoke. One or a few servers located centrally through which all the messages pass. Distributed execution of integration logic remains the exception.

Therefore, we should maybe introduce the “ESH“, the Enterprise Service Hub?

Notes:

1. Older integration solutions often had their adapters running on the same servers as the back-end applications or database, so away from the central message broker. But nowadays, also all the adapter logic is put in to the central hub.
2. Obviously, every ESB can deployed in a distributed manner, interconnected by some messaging solution. But that’s definitely not the standard approach.
3. Why is integration logic put centrally? One justification is to avoid disturbing the servers on which the back-end applications are running.
4. Maybe lighter-weight, open source ESB’s will make distributed execution of integration logic more popular. E.g. with such open source ESB’s deployed along with a J2EE application.

In this post, I’ll cover the 2nd question that I raised in my previous post: “where to do transformations (and routing, monitoring, …) of the web service interactions?” When a consumer and service use different service defintions, how to transform between both in a Microsoft world? Or re-phrased: where is the Microsoft EBS to mediate synchronous, request/response web services?

When searching on “Microsoft ESB”, one quickly ends up at Enterprise Service Bus Guidance. This is not a real product but documentation and components developed by Microsoft’s Architecture team. As BizTalk is a hub-and-spoke integration solution that persists every incoming message and it’s MessageStore, BizTalk isn’t really suitable to be an intermediary for synchronous, request/response service invocations. As such, BizTalk lacks crucial features to be called an ESB, although it remains a nice integration solution.

With no Microsoft ESB available, what are the options?

• Java based ESB: commercial (WebSphereESB, AquaLogic/OracleESB, Tibco BusinessWorks/ActiveMatrix, SoftwareAG, JCAPS/OpenESB) or open source (Synapse, WSO2 ESB)
• Runtime governance tools such as Amberpoint that are also capable of doing transformations. Microsoft has SOA Governance integration with Amberpoint and SOA Software.
• XML appliances

But none of these options are really appealing to the average Microsoft shop. If there is full access to the .net source code as one side (consumer or provider), some custom transformation logic can be added. But therre don’t seem to be any clear hooks for transformation in WCF.

Note: Microsoft’s new cloud computing – Azure – specifies an Enterprise Service Bus in its .Net Services. The preliminary documentation of the Microsoft .Net Service Bus talks about naming, different types of RelayBindings and security. But transformation and routing of messages isn’t covered (yet).