Jul 23
“Loosely coupled” is a heavily used term in SOA land. To me, loosely coupling means the use of a standardized contract/interface (aka canonical message format) and preferably also synchronous messaging such as JMS.
Found an interesting presentation that describes the “facets” of loosely coupling. And it compares the different types of web services with relation to “decoupling”.
Jul 21
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.
Nov 22
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.
