One body is desirable and sufficient, particularly since there will be related ongoing developments from other standards bodies such as OASIS and the World Wide Web consortium (W3C). WS-I does not produce the detailed specifications from scratch, but coordinates and administers details of the accepted and developingstandard protocols.
The proposal from WS-I covers four specific areas in the first place, (i) messaging, (ii) description of standard messages and implementation details, (iii) discovery or how to advertise a Web Service, (iv) security.
Security is a continual problem in the Internet world and could become a more serious one if hackers are allowed into business-to-business e-commerce systems. Compliance with the data protection acts will also be significant, a problem exaggerated by the potential of these B2B applications crossing international boundaries. The associated areas being addressed, but not yet resolved, by WS-I are mechanisms to provide end-to-end integrity, privacy, authentication and authorisation relevant to Web Services.
Web Services are based on three major standards, all closely related to XML, SOAP (simple object access protocol), WSDL (Web Services description language) and UDDI (universal description, discovery and integration). The first two are now well accepted, the latter one in the "promising" state, yet to be incorporated by W3C. There will be a number of other standards added as time goes by, in particular related to higher levels "up the stack". The latest one to be addressed by WS-I is referred to as Web Services choreography, XML-based mechanisms for B2B collaboration, including supply chain systems. In the promising category here is a proposal based on IBM's WSFL and Microsoft's XLang technologies; all this cooperation between IBM and Microsoft is quite bewildering! This proposal is called Business Process Execution Language for Web Services (BPEL4WS), surely in line for the prize of worst name yet. Given the possibility of multiple systems in a chain it is essential that such a standard is accepted and applied quickly. There is a problem arising already in that a number of early adopters have developed systems limited to two participants, which will need redeveloping to encompass multiple partners.
SOAP is potentially a major problem area, not in SOAP itself, but in misuse of it, SOAP stems from a Microsoft standard for implementing Remote Procedure Calls (RPC) in a simple fashion. Unfortunately an RPC is not suitable for a distributed e-commerce system, a robust message-passing architecture is essential. This concept was pioneered by a number of software products aimed at financial services. It came to prominence when IBM released MQSeries products and Microsoft responded with Windows Messaging. Since then MQSeries has been embedded in IBM's key transaction. office and workflow products and services, including Java-based systems such as WebSphere. SOAP includes message-passing (asynchronous) options, as needed, but it also includes RPC (synchronous) features. It is essential in Web applications that use of these features is avoided - learn the lesson from financial services of old!
The Web Services specifications go beyond the basic message passing systems to cover message content standards. This is where XML and XML Schema come in. In effect Web Services will interact by interchange of formal documents. The significance of XML in this case is that messages are basically self-defining; the meta data defining the content is also transmitted in the mark-up. In the short term this is of little value, in fact it is a disadvantage because the messages are much longer than encoded data, but as systems become more complex and changes must be made it becomes a real blessing. It is going to be far easier to maintain a system based on documents. This is true of most distributed applications, but it is of critical importance when multiple, incompatible systems and applications must work together, without modifying the actual applications. This is a new challenge to the IT industry and Web Services is the answer. Self documentation and ease of maintenance go hand in hand.
The final point to note is that the above outlines the work being done to help developers of Web business-to-business applicationsmake their systems cooperate with each other and yet develop those systems using their own preferred technology. Web Services applications such as directory services, SOAP routing, etc. need to become more mature, which means we need the stability promised by WS-I. As quickly as possible,
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.