| |
Wednesday 14th April 2004
COMMENTARY - WEB SERVICE STANDARDS CHECKPOINT
| LINKS
CBDI ROADMAP REPORT - The Web Services Protocol Stack
This (continuously updated) report assesses the status of various Web Service protocols and suggests a timeline for their adoption and relevant roadmap actions. It provides a useful reference and links to all the numerous protocols currently proposed or in the standards process. Last update March 2004.
The Web Services Protocol Stack
CBDI NEWSWIRE - Wednesday 7th April 2004
OASIS Moves ebXML towards SOA and Web Services
CBDI Newswire
CBDI VENDOR INSIGHT REPORT
GrandCentral and the Value Added Service Network
The long term vision for computing is huge and virtual, software services networks. Today we can start to envision this, but to most of us Web Services, utility and on demand computing are small steps in an inevitably long evolutionary cycle.
CBDI Insight Report
| Next month sees the third anniversary of the SOAP specification being submitted to W3C. Back then many thought the standardization process would be fairly rapid, after all the S in SOAP does stand for Simple! One of our most popular research areas is tracking the Web Services standards. We take a checkpoint and assess where we are in this long term project.
Whilst SOAP became a W3C Recommendation (standard) last year, and is now in widespread usage, there are a large number of Web Service protocols that have since been proposed beyond the original SOAP, WSDL and UDDI. Hardly a month passes by without new protocol proposals, and this superficial confusion may have influenced many organizations to play a "wait and see" game.
MAKING SENSE OF THE STANDARDIZATION PROCESS
But the time for sitting on the fence is now over; most organizations are adopting at least SOAP and WSDL, and many are looking closely at WS-Security (approved last week by OASIS) as critical elements of their technical strategy in the near future.
But if the place of these base protocols is reasonably straightforward, what about all the others ranging from transactionality, process orchestration and federation? In our WS Protocol Stack we have build a simple model which tracks the protocols through four states - Specification, Experimentation, Early Adoption and Mainstream. A good principle to adopt here is to align your own business need for risk to the roadmap states. If wide area long transactions are core business for you, then WS-Eventing and WS-Coordination should be major priorities.
IS COMPETITION IN STANDARDS DESIRABLE?
Another dimension of relative maturity is competition. Last year for example, BEA, IBM, Microsoft, SAP and others formed the WS-BPEL Technical Committee at OASIS, despite the existence of a similar WS-Choreography Working Group at W3C. No doubt Sun and Oracle’s leading role in WS-Choreography prevented IBM and Microsoft from joining at the time, although this hasn’t stopped most of the other vendors hedging their bets by participating in both.
The choice of standards body does sometimes provide insight. Although there was an OASIS TC in existence chartered to develop protocols for reliable messaging, it didn't stop IBM and Microsoft publishing their own specification on the same topic. However they have withheld the specification from the OASIS TC, even though they continue to refine it. This seems like a pure power play - the IBM and Microsoft standards development strategy is based on publication and submission of a developed standard to a new committee.
In rare moments of candour, major vendors have remarked that OASIS provide a neutral framework that has the potential to enable an easier and faster process, in which a balanced committee of vendors can rapidly deliver. In contrast the W3C can be a more academic environment where architectural elegance still counts for something, but debates can in consequence persist.
All the vendors involved in the standards processes will tell you that they collaborate in the standards development process, because they know they all need the end result. However it would be naive to imagine that the standards processes are entirely free of politics. The unholy alliance of IBM and Microsoft over the past four years has been amazingly effective in delivering results. But other vendors have been sidelined in the process. We are certainly wondering what will happen now that Microsoft and Sun seem to have developed collective amnesia, and are playing golf together.
A bad result would be that the involvement of a major third party would slow down the standards creation processes. But a good result would be that some of the overlapping Web Service protocol initiatives get resolved. For example:
> Reliable Messaging - OASIS Reliable Messaging TC vs WS-ReliableMessaging (a BEA, IBM, Microsoft and Tibco proposal)
> Process Orchestration - W3C WS-Choreography vs OASIS WSBPEL TC
> Coordination and Transactions - WS-Composite Application Framework vs WS-Coordination
REMEMBER THE VISION
It's hard to underestimate the impact that the Web Services standards will have on IT application architectures and business practices. Just a few years ago the industry was consumed with hard wired integration of existing applications. Today everyone understands this was a road to disaster and that open, heterogeneous integration is where we are headed. But once you have this open environment, the opportunities to create collaborative architectures at all levels is immense. In recent reports we have shown glimpses of how this vision will play out, (see references below) but the opportunities that come from eradicating the silos, enabling channel neutrality and implementing real time business intelligence will have profound effects on all aspects of business.
CONCLUSIONS
Last week we reported an announcement from OASIS in which they indicated plans for a merging of Web Services and ebXML technical architectures which is planned to take place over the next 18 months. This is a significant move, which reflects user pressure on the need for one common set of interoperability protocols, but equally reflects the maturity of the Web Services technology, that the ebXML community is now ready to embrace it.
In the broader scheme of things, the Web Services standards process is actually happening very rapidly. If at the end of a five year period we have common, mature, wide area standards for basic business interoperability, we will have come a very long way. What will take much more time is the reengineering of the vast base of enterprise applications that will soon be recognized as the primary inhibitor to flexible interoperability. But that's another story.
|
| | Read Full Article / Link to referenced materials |
|
Home