CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

The Web Services Protocol Stack By Lawrence Wilkes This 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.

Links to the various protocols, standards organizations, etc. are provided on Web service protocols summary table.

Web Services are a set of protocols based on XML (Extensible Markup Language). Many readers will be familiar with the following base protocols that formed the initial specification for Web Services.

• Simple Object Access Protocol (SOAP) - defines the runtime message that contains the service request and response. SOAP is independent of any particular transport and implementation technology.
• Web Services Description Language (WSDL) - describes a Web Service and the SOAP Message. It provides a programmatic way to describe what a service does, paving the way for automation.
• Universal Discovery, Description, Integration (UDDI) - UDDI is a cross industry initiative to create a standard for service discovery together with a registry facility that facilitates the publishing and discovery processes.

Figure 1 - Base Web Service Protocols

These have effectively become de facto standards, with effectively universal acceptance and widespread implementation by vendors. Figure 1 shows the way their application is typically illustrated.

These base protocols have enabled many companies to put straightforward Web Services into production. However, to improve the security and reliability of Web Services and to address more complex business scenarios, a wide range of additional protocols have since been proposed. Some of these have since been merged with others or morphed into new proposals. The current proposals are illustrated in figure 2 with further detail and links to the various specification is provided on Web service protocols summary table.

Web Services Architecture

The additional protocols have been proposed within the context of a modular framework that would allow,

1. Developers to only use the modules needed for their Web Services. Each module can be lightweight and not overburdened with irrelevant syntax.
2. Each module to evolve in isolation

There is no standard definition of the Web Services Protocol stack though the W3C Web Services Architecture Working Group did publish a Web Services Architecture document which provides an excellent context for the various protocols. Vendors often draw their own, but similar architecture. These should not be seen as proprietary, as the underlying standards are common. Our own interpretation is shown in Figure 2.

Figure 2 - The Current Web Service Protocol Stack

CBDI Assessment

Additional Protocols Required

Taking all the proposals in Figure 2 into consideration, the set of protocols required for secure, reliable 'Enterprise' Web Services is largely complete. Areas not fully addressed are

• Management. The OASIS WSDM Technical Committee is still in its early stages. WSDM will provide standard protocols for the Management Of Web Services (MOWS), and for Management Using Web Services (MUWS).
• Service and Business Level Agreements. These are identified by the W3C Web Service Architecture working group as part of the description layer, but as yet no proposals have been made in this area.
• WS-Security. The specifications for some elements of the WS-Security architecture have yet to be published. These are WS-Authorization and WS-Privacy.

Alternative Proposals

The degree of industry consensus on Web Service protocols has been significant. Though alternative proposals have been made in some areas, the formation of an appropriate working group in either W3C or OASIS has usually seen the subsequent convergence of all interested parties.

There are currently some areas where alternative proposals remain, namely in the areas of Reliable Messaging, Orchestration, and Transaction Coordination. These alternatives have generally reflected an IBM/Microsoft led initiative on one side, and one led by Sun/Oracle on the other.

However, Microsoft and Sun earlier this year agreed to settle various antitrust and other issues, and announced greater cooperation in Web Services. Since then Sun has joined with BEA, IBM, Microsoft and SAP AG to submit the latest version of the WS-Addressing specification to the W3C. This will merge with the WS-MessageDelivery specification which Sun supported earlier along with Iona Nokia and Oracle. This was followed by BEA, CA, IBM, Microsoft, Sun and TIBCO jointly publishing an update to the WS-Eventing specification, which proposes a way of communicating about events within and between Web services. This update sees CA, IBM and Sun joining BEA, Microsoft and TIBCO, who proposed the spec originally, and likely signals the prospect of greater interoperability with related specifications such as WS-Notification. Ca, Sun and WebMethods also joined with BEA, IBM, Microsoft, and SAP, in publishing the 2nd version of WSMetadataExchange.

These are welcome moves, and it augurs well for further cooperation in other pockets of overlapping proposals such as transaction co-ordination and choreography. Consequently, it looks like any concerns over competing Web Service protocols delaying standardization, and hence adoption, should now disappear.

There has also been some overlap between Web Services and the ebXML initiative. ebXML uses SOAP at the transport level, but has its own registry and orchestration. Though ebXML is an approved, robust standard, its applicability is far narrower than Web Services. As an evolution of EDI, it primarily addresses the B2B domain only. As such we believe the Web Service protocols that are designed to address multiple requirements and usage scenarios will prove more valuable in time and that ebXML will probably evolve to adopt additional Web Service protocols as they mature and are approved. Part of the work of the OASIS ebSOA TC is to evolve the ebXML architecture and address the transition to the adoption of more Web Service protocols.

Standardization Process

Though the proposal of various Web Services protocols has been a fast moving area, their transition into actual open standards is inevitably much slower. There are only a few protocols that have, or a close to completing the standards process proper. Some key proposals have yet to be submitted to any standards body. We advise continuous monitoring of what are currently the two main standards groups involved in Web Services,

• World Wide Web Consortium (W3C) - http://www.w3c.org
• Organization for the Advancement of Structured Information Standards (OASIS) - http://www.oasis-open.org

Web service protocols summary table indicates the current status of the various protocols in the standards process.

WS-Interoperability (WS-I)

WS-I is an open, industry group that was formed in 2002 to promote Web services interoperability across platforms, operating systems, and programming languages. Though this would appear to be the basic premise of Web Services and the role of standards bodies, WS-I still has a useful role to play, for example,

• Standards specifications are always open to interpretation to some extent. WS-I will provide guidelines and tools to help measure the conformance of various implementations, and to enable their interoperability
• As standards evolve, there is a need to understand what different versions might interoperate
• Publishing interoperability profiles to reflect the above, one of the key deliverables of WS-I.

http://www.ws-i.org

Adoption

The current status of these protocols is shown in Figure 3.

Figure 3 - Adoption of Web Service Protocols

Specification - Exists only as draft specification. Any usage requires hand coding.

Experimentation - early implementations provided by vendors permit experimentation, but are not recommended for production use. (e.g. technologies available from IBM Alphaworks do not support production use)

Early adoption - More robust implementations available and protocol well into standards process, encourages production usage by end user organizations

Mainstream - standard ratified, or wide scale de facto adoption

Roadmap Actions

Apart from infrastructure and tools vendors, and early experimentation, organizations should avoid handcrafting the use of Web Service protocols wherever possible. It should not be necessary for developers to learn the low-level XML syntax of Web Services, delegating the generation of it instead to the infrastructure products and development tools.

Organizations should establish a policy for compliance with standards, paying particular attention to evolving versions, and using WS-I profiles wherever relevant.

Roadmap Actions

Monitor progress of protocols through key standards bodies

Establish policy on protocol usage

Adopt protocols as WS-Profiles become available to ensure standards based interoperability. Create local profiles only where necessary, and plan to upgrade to WS-I as they are published

Coordinate use of protocols to ensure consistent implementation of versions and profiles. Publish best practices

Plan for phased implementation of emerging protocols with local extensions where necessary

Wherever possible wait for implementation of protocols in products

Links

Links to the various protocols, standards organizations, etc. are provided on Web service protocols summary table.

  Download as PowerPoint Presentation (Gold subscribers only)