Patterns of Web Service Versioning

One of the sessions I attended at JavaOne 2010 was titled: "Versioning Strategies for Service-Oriented Architectures."

I was particularly interested in this session in part because, as of this writing, there are no de-facto standardized mechanisms in place to version a web service.  This session presented several patterns and strategies that could be used to achieve effective versioning.

The speaker presented different scenarios that would require a service to be versioned.  It was quite interesting - he made the distinction between "formal" and "semantic" changes, and that both types would trigger the need for a new version of the service.  I'll admit that I had not thought about these different classes of changes, so it was really neat to witness the ideas expressed.

A formal change would be something "concrete" - such as adding a new piece of data to a message required by an operation. A semantic change might be something like the SLA requirements on the service changing - e.g., the SLA of a service changed from a 95% uptime requirement to a 99% uptime requirement.  Such a change would have ZERO impact on the WSDL, yet it is still a form of change, and thus, a new version of the web service would need to be rolled-out and thus versioning is required.

My colleague Dave Read and I were discussing the merits of the patterns covered in the session, and we both took note of the fact that many of the ideas presented were not really new; that many of the ideas were just new applications of existing principals and design patterns.  Here are some examples (in parenthesis is how the proffered pattern relates to an existing pattern or idiom):

• the speaker presented a pattern in which a mediator component would provide a layer of indirection to service clients; the mediator would route the request to the appropriate service implementation based on the contents of the message (see GoF Mediator pattern)
• the speaker presented a pattern in which the message itself could contain a version parameter, thus providing the necessary version context (see Format Indicator EI pattern)

For what it's worth, I'm fully aware and cognizant of the fact that several works, including: the GoF catalog and the EI patterns catalog, do not present new ideas per se, but are instead consolidations and refinements of ideas discovered over time.  It just struck me as interesting and noteworty the longevity and pervasiveness of many of the patterns in software development can have.  It really underscores the need for us, as software developers, to have a strong grasp of them.  In short, developers should have these patterns internalized.

More information on the session can be found here.  The speakers who presented were: Kiran Bhumana and Gopalan Suresh Raj.

JavaOne 2010 - Building a JAX-WS Web Service with JBoss Drools Integration

Building a JAX-WS Web Service with JBoss Drools Integration

This was the title of the session that I co-presented with my co-worker, David Read, at the JavaOne 2010 conference.  Specifically the presentation focused on a strategy for building a web service using various Java-based APIs, including: JAX-WS, JAXB, JAXR, and JSR-94.

In our presentation we touched upon the concepts of business rule engines, service registries, as well as some of the APIs used to access such components, however, there were many core theme at work.  The themes, broadly encapsulated in the works by Rod Johnson (here and here), shared a common thread - and that is the axiom that one should design to interfaces, and not technologies.

The value of this axiom is multi-faceted.  Designing to an interface means that callers of the interface are not tied at all to the underlying implementation (which may be using some vendor-specific API).  This allows for pluggable implementations without impacting callers when they need to be swapped.  Assuming of you course that you have a set of unit tests that operate against your interface, it should be fairly painless to swap implementations.

In the JavaOne presentation  my colleguaue and I delineate each of the components that make up the workings of the service: the marshaler component, the service object itself, a connector to talk to the registry, a connector to talk to the rule engine.  Each and every one of these objects publishes a pure Java interface that in no way is tied to a technology-specific API.  As an example our marshaler component (responsible for de-serialization and serialization of XML messages to and from our Java object model) contains the following interface:

public interface Marshaler {

    BookOrder unmarshal(Source pBookOrderSource);

    Source marshal(BookOrder pBookOrder);

}

In this example the marshaler interface does not expose any implementation hints; the reality is that we could have any number of implementations.  One implementation could leverage JAXB; another could leverage JDOM; another could leverage Apache Xerces, etc.  Objects that require the ability to marshal book order objects will do so via this interface; the implementation today could be based on JAXB.  Tomorrow however requirements could dictate that we use a different implementation.  Lightweight IoC containers, such as Spring, further reward developers for following this approach.  The reward is that implementations can be swapped-out by merely changing configuration, and not having to touch any code.

The interfaces represent semantic definitions of the components they are abstracting.  The yield of this added layer is complete pluggability and design portability.

 In my work as a consultant I have seen many organizations build enterprise solutions, but yet fail to follow such axioms.  The upfront cost to this is hidden.  In the long term, when the organization is contemplating the use of different products and systems, the cost of NOT following this axiom becomes very apparent.  For example when management wants to purchase that new and flexiblee rating engine (to give them an edge over competition) only to be told by their IT staff it will be too expensive and too much work to retro-fit the existing applications to integrate with it, will the costs of not following this axiom will be realized.

So the next time you need to design an integration with some sort of component, apply the engineering effort to create an interface-based abstraction around the component so as to achieve pluggability.  Following this basic principal of OO will enable you to create flexibility solutions, avoid vendor-lockin, and keep management happy.

You can access the presentation that Dave Read and I gave at JavaOne 2010 from my company's Slideshare page.  The source code to the demo application is posted at: http://bit.ly/blueslate-javaone2010

My Old Z

I sure do miss my old Z...that is all.