JMS Correlaton Patterns

A customer came up with the suggestion to use the CorrelationID pattern for correlating JMS request and responses. In this pattern, a client sets a (preferably unique) value in the JMSCorreleationID property of the request. The service copies request.JMSCorrelationID to reply.JMSCorrelationID. This was a way-of-working I hadn't encountered.

There are 2 main JMS correlation mechanisms that I had seen so far: 1) the MessageID pattern whereby the service copies the request.JMSMessageID to the response.JMSCorrelationID and 2) the use of temporary queues.

In the Enterprise Integration Patterns book, the use of the CorrelationID as a "Conversation Identifier" is confirmed. And indeed, the CorrelationID pattern has some nice advantages, e.g. the correlation can be based on some unique identifier the JMS client picks itself (e.g. from the payload), no need to keep an extra JMSMessageID as an extra state variable.

Unfortunately, the SOAP-over-JMS draft also prescribes copying the JMSMessageID of the request to the JMSCorrelationID of the response message. And this is e.g. what Spring-WS implements.

Book: Web Service Contract Design and Versioning for SOA

Just finished reading the early access version of the book "Web Service Contract Design and Versioning for SOA". Recommended book, well written!

As its title suggests, the primary focus is contract design. Less attention is paid to versioning. But the book goes into extensive detail wrt. XML Schema design, WSDL creation and use of related specs such as WS-Addressing and WS-Policy. Also the differences between different versions of e.g. SOAP and WSDL are well addressed.

This book really fills a gap: SOA books often remain at a too high level, standard WS development books dive directly into code and XML Schema books are unrelated to WS-*.

Every serious WS/BPEL/SOA developer or designer needs to have a good understanding of these base technologies, in particular XML schema. One of the better WS books since "Web Services Platform Architecture SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More".

Note: after reading such book, one must confess that WS-* is quite messy and more cleanup is needed; WS-I will need to write more or lengthier profiles!

HTTPS all the time?

Why don't web sites, web applications and web services use HTTPS by default? What prevents us from using HTTPS for all Internet communication? No more risk while accessing applications from public places such as hotels. No more risk of an ISP looking into your confidential network traffic.

Obviously, SSL takes some CPU power. I don't know how costly SSL is, but isn't this becoming negligible? On the other hand, there is SSL accelerator hardware being sold, so there must be some need for it.

Another challenge is the certificate management. Either services use one of the well known Certficate Authorities. But alternatively, clients should become better at managing self-signed server certificates or unknown CA certificates. Many client apps, including WS clients, would benefit from user friendly certificate and key mgt. No more Java keytool, but a user friendly configuration GUI.

XML gateways

If you're interested in learning more about XML gateways, 2 vendors provide reasonably detailed information. The technical documentation of CISCO's products is available online, both for their AON and ACE (ex-Reactivity) products. And IBM provides 4 Redbooks that go into quite some detail on DataPower. But other vendors such as Cast Iron, Layer7, Vordel and Intel (ex-Sarvega) all seem to consider their docs as a valuable assets not to be shared with the world.

Spring Integration is not an ESB

The Spring Framework is a popular application framework for Java Enterprise applications. Best known is its mechanism of "Inversion of control" or dependency injection. But the Spring Framework comes with many other features. Typically, Spring will define a clean set of interfaces and implementations on top of existing Java constructs.

Now, Spring is also popular in the world of integration: most open source ESB's - Mule, ServiceMix - are based on the Spring Framework. Recently Spring came up with its own "Spring Integration" sub-project. Although still in beta, this doesn't seem like a standard ESB. Rather, Spring Integration is more focused on integration "within" the application. Separating the integration logic from the business logic, but keeping it within the application itself. As such, one gets integration at the edges. In line with the Spring Framework itself, Spring Integration is obviously Java oriented, e.g. the Message object has a Java object as payload. It does not make any assumptions about payload format, XML or other. Spring Integration takes the Enterprise Integration Patterns book as a starting point, and that is something it does have in common with the many open source ESB's.

Another interesting sub-project is Spring Batch. This framework is focused on processing large data sets whereby the processing is split into multiple transactions and progress of batch jobs is maintained in database tables. This tool also comes with adapters and message conversion, but from a completely different angle.

Interesting to watch how the Spring team will grow these projects, along with Spring-WS and their upcoming REST implementation.

OSGi in Action

OSGi is becoming quite popular as the module system for Java Enterprise systems, including integration solutions. In open source integration solutions such as Mule, but also commercial ones such as Tibco ActiveMatrix.

The OSGi services look like a smaller scale SOA, within the Java VM. I can well imagine OSGi services being used to dynamically invoking different pieces of transformation or other integration logic from within an OSGi enabled ESB or mediation framework.

There were 2 sources of information that helped me get up-to-speed wrt OSGi: first of all the recorded talk on Paryles that Costin Leau gave about OSGi (and Spring) at the SpringOne conference. And secondly the draft chapters of the upcoming book "OSGi in Practice" by Neil Bartlett.

Creating XML schema's

When doing contract first Web Services design and development, the primary challenge is coming up with a good XML schema (XSD).

One of the options is to create a sample XML messages and generate an XML schema from that sample message. The XML editors Stylus Studio and XML Spy support the generation of an XML schema from an XML message. Unfortunately, my favorite XML editor - Oxygen - doesn't come with this feature.
Note: other otions are Trang and the xsd tool of the .Net framework

But apart from these 3 well known XML editors, I just came across a free XML editor that does support the generation of XML schema's: Liquid XML Studio as well. The Liquid XML editor also allows to easily add facets (minOccurs, maxOccurs, maxLength, ...) to the schema.

The generated schema's usually don't look nice and each tool has its own way of generating the XML schema. To re-factor the generated XML schema, the XML schema editor of the Eclipse IDE comes in handy. One of the options I like in particular is the re-factoring of an anonymous Element into a Complex type.