Mashed Articles

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.

At the risk of offending all those who love to talk for hours about cores, caches and clock speeds, I have to say that I personally find discussions about the innards of silicon chips and how they are wired together intensely boring. In fact, I’ve probably already used all the wrong words and phrases, even in that first sentence, which is no doubt going to annoy some people further.

So, when Tony, Martin and I were invited to a dinner to meet with some of AMD’s European executives, I was understandably in two minds about attending, especially as I am also not really into all this wining and dining stuff as some other analyst are.

I went along, though, and I’m glad I did. Sure, I found myself sucked into the odd eye glazing conversation that I only partially understood, but something that came across clearly was that AMD is investing quite a bit in ‘reaching through’ relationships with its direct customers (largely the OEMs) to the ultimate customers – Enterprises, SMBs and consumers.

Of course there is nothing new or unique in this, in fact I ran a team at Nortel Networks back in the early 00’s which did exactly the same thing (in that case, reaching through the mobile operators to understand how 3G related to their subscribers). The basic idea is that you can gain insights and tune your R&D based on direct end user/buyer input that would not be possible if you worked second hand through your customer as an intermediary. To do this well, however, you really need people who understand that end user environment and the trends that are taking place within it, and that’s not necessarily the same people that deal with your core product design from an internal perspective.

Anyway, this end-user oriented view of the world shifted discussions to more familiar territory for me during the dinner, and I enjoyed hearing people like Giuseppe Amato, who goes under the title “Director, Value Proposition Team”, explaining how the whole process works in relation to data centre evolution, high performance computing and mobile working. It changed my perception of AMD quite a bit from simply “the alternative to Intel” to that of an independent player that is committed to driving industry development in its own way.

While I am not qualified to comment on the relative merits of AMD technology versus the competition, nor its ability to execute in the cut throat world of OEM deals and supply chains, I now have a much better appreciation of why what AMD does actually matters. It is not just about price/performance or performance per watt of energy consumed, it is about shifting thresholds to make things economically or practically possible in the mainstream market that previously were not. That’s why the “what if you could….?” conversations with end customers as suppliers like AMD reach through to them are so important. And also why, for the first time in my life, I actually had some genuinely interesting conversations about silicon that were directly relevant to the world in which I live.