Friday, January 26, 2007

Is full interoperation realistic?

Wouldn't it be useful if applications could communicate over a network using a standard message format and protocol? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple?

Sure, but before long you'd have to address the 'full interoperation' requirements: distributed transactions (so application programmers don't spend most of their time writing error handling logic), security (for sensitive data), a directory server (so distributed applications can find each other; ideally secure and transactional), load balancing, distributed debugging, etc.

And since real world systems don't all run on a single vendor's hardware or software, most of these features would need standardising so applications running in different environments could communicate with each other.

Now if the probability of each feature interoperating correctly was, say, 99.9% and there were, say, six features, then the probability of all six features interoperating correctly would only be about 99.4% (0.9996).

You'd end up with a system that would be much more complex than was originally envisaged and the interoperation wouldn't be great.

But, hey, what if you stepped back and came up with a standard message format and protocol so that applications could communicate over a network? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple? Indeed it would ... if.

Many vendors are following the full interop. model with the likes of CORBA (e.g. via Java EE) and SOAP. Others, notably Microsoft, support full interop. but would much prefer a homogeneous (software) network also viewed as 'single vendor lock in' (or world domination).

I don't think there's a perfect, multi-vendor solution, desirable as this would be. The most flexible approaches that I've seen work in practice are distributed systems consisting of homogeneous 'islands' loosely connected with relatively simple protocols (such as MQ Series messaging, IIOP, or vanilla SOAP).

No comments:

Projects

OSGi (130) Virgo (59) Eclipse (10) Equinox (9) dm Server (8) Felix (4) WebSphere (3) Aries (2) GlassFish (2) JBoss (1) Newton (1) WebLogic (1)

Blog Archive