Wednesday, June 21, 2006

Rise and Fall of CORBA

Saw this on Justin's links. I agree with pretty much all of it. It solved a technical problem early-on (basic connectivity between heterogeneous systems) and then did two things:
  • Morphed into this appalling beast with numerous vertical committees and pointless horizontal specifications.
  • Failed to address it's technical short-comings (IIOP, Firewalls, IDL).
Michi Henning goes on to layout some lessons:
  • Have reference implementations.
  • Have proven usage of reference implementations before standardisation in non-trivial problem domains.
  • Have strong committees that don't allow frivolous specifications / features.
  • Use open-source for reference implementations - it's a survival of the fittest arena for spec. features. It also provides transparency for the process.
The industry is kinda going this way anyway, to some degree in Javaland. There's room for improvement.
Is the same true of Web Services? There are certainly some uncomfortable parallels.

SOAP and WSDL solves a basic problem namely basic connectivity between heterogeneous system, but this time, it's firewall friendly (SMTP, HTTP as transport protocols), language neutral, not opaque (you can view XML on the wire) and extensible.

Then we have a raft of new specifications either already here or quickly will be:
  • WS-Reliable Messaging - guaranteeing delivery over unreliable protocols (HTTP, SMTP, etc), sort of turning them into a JMS.
  • WS-Security - encryption and signing of messages
  • WS-AtomicTransaction - allowing multiple web-services to enroll in distributed transactions.
  • WS-Context - allowing mulitple web-services to share context (conversation identifiers).
  • WS-Trust - built on WS-Security, allowing exchange of credentials/security tokens from different domains.
  • WS-BPEL - coordination of web-services for business processes.
All of these have been developed by a selection of companies coming together to agree a standard, most have then been donated to an organisation for standardisation, e.g. oasis-open. While most will have reference implementations being put forward by one or more of the owning organisations along with the first release of the specification, they have not been developed in an open-source manner (though they may be donated to an open-source project at some point), nor have they been proven in real-world domains.

Quite rightly people have criticised this whole WS-* effort as being overly-complex and part of the reason for this is the lack of community developer involvement in the creation and evolution of these specifications.







0 Comments:

Post a Comment

<< Home