Microsoft ESB and WS mediation

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 in 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 at one side (consumer or provider), some custom transformation logic can be added. But there doesn'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).

Microsoft .Net and JMS?

Recently I was challenged by a customer with strong Microsoft focus that required integration with a newly accquired application based on Java/JEE. Both the Microsoft .Net and Java side supported Web Services. The service contracts - message formats - were obviously different. The Java side also leveraged JMS for asynchronous communication.

That brought up 2 very interesting qustions:
1. How to link a .Net application to JMS?
2. Where to transform (and route, monitor, ...) the web service interactions?
In this entry, I'll cover the JMS question. In a next posting, I'll discuss the Web Service mediation question.

To start, there is no out-of-the-box solution: no generic .Net component to talk to JMS, no generic MSMQ/JMS brige or no standard .Net version of the JMS API. Below a list of other options:

• Most JMS providers come with some .Net (or COM) API, although all proprietary. E.g. IBM has WebSphere(R) MQ classes for .NET and XMS.Net. WCF bindings from JMS providers are hardly available: Tibco has announced one (is it available already?) and IBM has a prototype available.


• Some JMS implementations expose a REST like interface, so simple interactions over HTTP. In case of WebSphereMQ, this is the MQ Brige for HTTP.
• Microsoft BizTalk has a WebSphereMQ adapter already a long time and more recently, a TibcoEMS adapter is available as well. But BizTalk does not have a generic JMS adapter.


• JNBridge is a company providing .Net/Java interoperability products (and earlier COM/Java interoperability). JNBridge has .Net JMS adapters: one for BizTalk and one for .Net.


• And Host Integration Server has a MSMQ/MQSeries bridge.

The 1st or 2nd option have my preference. Although you're programming against a proprietary API, no BizTalk nor 3rd party software needed.

Note: using the JMS API with WebSphereMQ introduces an extra complexity because of the way JMS header fields are mapped to the MQ message structure. MQ uses the MQRFH2 header to store JMS specific properties. The Microsoft ESB Guidance comes with a a BizTalk Pipeline component that provides support for this MQRFH2 header.

Note: not 100% sure, but most probably the .Net or MSMQ adapters of Java based integration solutions such as WebSphereESB or JCAPS use JNBridge underneath.