Monday, May 01, 2006

Web Services, interoperability and portability

I've been meaning to write this entry for a couple of weeks, but just haven't had the time. The original impetus for this came about because of a recent client engagement that reminded me of previous similar interactions. At the heart of the problem lies the difference between interoperability and portability, a discussion that isn't new by any means, and neither is it a Microsoft versus everyone else argument: J2EE and CORBA both suffer too.

Where the recent confusion arises is around the hype associated with Web Services: too often people will say things like (and I'm paraphrasing) "Web Services are meant to be interoperable, allowing you to talk to other vendor implementations and hence removing vendor lockin." Now everyone working in this sector of the industry knows (I hope) what this actually means: product A from vendor 1 can interact with product B from vendor 2 because the on-the-wire representation is defined within some set of standards with which both products comply. Unfortunately what the customer/end-user tends to hear is subtly different: "blah blah blah the same application can run on different vendor deployments blah blah blah." and when you come to educate them on the difference (e.g., Web Service standards don't talk about implementation language bindings, there's still scope for proprietary extensions within standards
and there's still no agreed Web Services architecture), they either look at you as though you'd just arrived from Mars or that you've taken their favourite toy away!

In no cases I've been involved with has the customer decided to ditch the move to Web Services (though some have seen Microsoft as a better route to achieving portability and interoperability, simply because the landscape isn't so fragmented - but there are other downsides to consider!), but they've asked the question "why?". Unfortunately that's not the right question either: it should be "how?". There are a number of steps that would need to be taken, one of which could be to go down the OMG route of a single organisation defining all language bindings and everyone agreeing to use them (Java almost has it). But I don't think that's going to happen (and in some respects I think it shouldn't): there's simply never going to be enough technical or political reasons to do so.

Ultimately I think this is an education problem. We need to make sure we clearly define what we mean by interoperability and portability (straighforward to do, you would think) and try not to gloss over the differences. Interoperability is extremely important as far as Web Services are concerned (at the moment I'd say it is the single most important aspect) and correctly discussed, customers will agree.

1 comment:

Anonymous said...

Hi Mark,

Maybe you've seen this; maybe you haven't, but here's my thoughts on portability and interoperability. The extremely short version is that I think it's in everyone's interests to try and get their vendors to use portable, existing API specifications where possible to implement the emerging Web services specifications.

Contrary to what vendors would like to think, there's no guarantee that they will be the best fit for your business objectives next year or even next week. Another point for consideration is the alarming rate of acquisitions and obsolescence of technologies and/or implementations in the current marketplace. Any enterprise or system architect worth their salt should be paying attention to these things when they select vendors so they understand the tradeoffs involved. Maybe it is worth it to meet a tactical business objective, but part of the point of having an architecture is having some idea of how it will evolve over time. This evolution shouldn't be driven by the technology choices you make today or be driven by the business objectives, fates and fortunes of the vendors you choose.