Re: [service-orientated-architecture] WebServices to repeat CORBA's mistakes : "The Rise and Fall of CORBA"

[Anne Thomas Manes]

Interesting article -- it's primarily about all the things wrong with standards consortia. (There are many.) Michi asserts that standards consortia should adopt three basic principles:

1. Standards consortia should only standardize existing best practices.
2. All standards should have a reference implementation.
3. Standards should be implemented before approved.

I definitely agree with point 3. (Note that both W3C and OASIS require implementations and interop testing as part of the standardization process.) I think point 2 is a little unrealistic unless you have a single organization that's responsible for the specification. (Only JCP requires a reference implementation, and in JCP, each JSR is controlled by one company.) I disagree with point 1. If you only standardize existing stuff, you never innovate. The standardization process should identify the major issues/limitations with the current best practices and fix them.

Michi goes on to suggest that open source practices follow these rules better than the standards consortia. While I'm a huge proponent of open source practices, and I think some of the best innovation comes from open source, I don't think open source is an appropriate venue for defining standards. Open source produces a huge amount of competing and incompatible efforts. That enables innovation, but it doesn't produce standards. And the community at large will never accept the concept of a benevolent dictator defining industry standards. Who should be the benevolent dictator for XML? HTTP? CIM? FIX? SWIFT? SQL? etc? The reason that we have standards consortia is to establish forums for equal representation in the standardization effort. I have fundamental issues with all standards consortia governance models, but I don't think reverting to an open source model will fix them.

This little paragraph that Alexander quotes below is really a throw-away comment, and Michi doesn't back it up with any kind of evidence.

Web services, the current silver
bullet of middleware, uses a process much like the OMG's and, by many
accounts, also suffers from infighting, fragmentation, lack of
architectural coherence, design by committee, and feature bloat. It
seems inevitable that Web services will enact a history quite similar
to CORBA's.

Most of the article focuses on why CORBA "failed". He mentions quite a few technical and political flaws in CORBA, but then seems to pin everything on the OMG standardization process. (Personally, I think CORBA did pretty well for 10 years, but our requirements changed, and CORBA doesn't fit the new requirements.) Michi tosses out the above comment, but then doesn't talk at all about the WS-* standardization process, nor any of the technical or political issues associated with WS-*. His assertion that web services will inevitably follow the same path as CORBA is completely undefended.

In fact there are very significant differences between the standardization efforts behind WS-* and those behind CORBA. First, there is no one standards consortium responsible for WS-*. And second, the initial specifications are developed using a process that's more like the open source model than the OMG model. Most WS-* specs have been developed this way: A small group of very talented people from a small number of vendors get together in private and defined a specification, build a bunch of implementations, test them for interoperability, and iterate the specification based on their implementation experience. Although the spec definition process is closed, each iteration of the spec is published to the general public, and everyone was invited to build implementations and join the interoperability testing effort. Eventually, after a specification has been rigorously tested and refined, the vendors submit it to a standards consortium for ratification (W3C, OASIS, IETF, or DMTF). At that point, everyone has an opportunity to participate in the process. This process may not be especially open, but it delivers solutions at a rate comparable to open source (and certainly much faster than a consortium-based process).

I'm not saying that I think WS-* will last forever. I'm just saying that Michi's assertion doesn't hold water. I'm pretty certain that requirements will change in the future, and at some point WS-* will no longer fit our requirements. Innovation happens. But I do think that WS-* will last for at least another 5 years, which will give it a lifespan equivalent to CORBA.

Anne

On 6/20/06, Alexander Johannesen <[EMAIL PROTECTED]> wrote:

The Rise and Fall of CORBA
Michi Henning, ACM Queue

[...] Web services, the current silver
bullet of middleware, uses a process much like the OMG's and, by many
accounts, also suffers from infighting, fragmentation, lack of
architectural coherence, design by committee, and feature bloat. It
seems inevitable that Web services will enact a history quite similar
to CORBA's.

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=396

Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________

__._,_.___

SPONSORED LINKS

Computer software	Computer aided design software	Computer job
Soa	Service-oriented architecture

---

YAHOO! GROUPS LINKS

•  Visit your group "service-orientated-architecture" on the web.
   
•  To unsubscribe from this group, send an email to:
   [EMAIL PROTECTED]
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

__,_._,___