This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Standards: Doomed to Repeat Itself?
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
George Santayana, a notable philosopher, coined the phrase, "Those who do not learn from history are doomed to repeat it." William Grosso has put together a presentation about the history of the CORBA standard. The presentation focues on the social and environmental factors that lead to the development of the CORBA standard. There are a lot of parallels in CORBA's history and the emerging web services standards.
CORBA defined in 1989, however vision based on the world of 1985. A world were PCs were just starting to emerge, businesses had dedicated machines with dedicated applications and the corporate network was still being built. The presentation explains that CORBA had several high points:
Limited Goals
Standardized Language Mappings
Very Efficient Protocol
Key Services Defined Early
Strong Support for Server Developers
However, Grosso says by the mid 1990s, CORBA hype had outgrown the original ambitions and CORBA proponents were claiming amazing things. He then highlights the low points of CORBA:
Interoperability Took Too Long
Specifications evolved slowly
Reliance on Fat Clients
Lowest Common Denominator Technology
Using IDL Too Complicated
Brittle Design Methodologies
Very little support for Application Lifecycle
Bizarre Mystique
No Support for Network Failures
RPC Model
If you look at this list, every one of them except perhaps one applies to Web Service standards. That leads me to a grim conclusion, for web services, we are doomed to repeat the failures of the past.
Why do standards evolve in this way, is there something fundamentally wrong in the way we create standards? Jim Waldo has a few keen insights on this matter. One of his main points:
A standards body is often a lousy place in which to invent a technology.
Waldo explains that there may be substantial discussion of technical merit in standard groups but he says that its really lip service. I also think that standards groups tend to choose the lowest common denominator of innovation. That is, standards groups tend to only approve innovation that they all collectively grasp, however in most cases innovation tends to be grasped only by a few.
Another problem with standards groups tend to create documentation rather than implementation. That is a fatal flaw which I explored in "Be Liberal in What You Accept, Conservative in What You Send". The lack of a standard compliance implementation undermines interoperability, the core essence of standardization.
It's interesting that standards groups give the participants an illusion of choice. Unfortunately, history clearly shows their fate is preordained.
Previous Topic
