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).
- 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.
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.
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