Bug 176493

Description Chris Brealey 2007-03-06 09:54:57 EST

The Web Services Explorer has its own built-in message/transport stack that handles the serialization and deserialization of SOAP 1.1 envelopes, the formation and parsing of HTTP 1.1 headers and payloads, and the creation of Java Sockets. The WSE has its own code to manage proxy firewalls, to speak http or https, to handle 30x redirects, to manipulate SOAP envelopes and bodies, and more.

This approach was originally taken to (1) work around limitations in the java.net component of earlier JREs, particularly for https transports and authenticating firewalls, and (2) avoid creating a dependency within the WSE on any specific third-party Web service engine for the purpose of manipulating SOAP envelopes and avoid the inevitable churn of reacting to upgraded or newly architected Web service engines (eg. Apache SOAP to Axis 1.x to Axis 2...)

Meanwhile, a large number of Web service, often coined "WS-*", specifications or standards have been drafted chiefly under the OASIS [1] and W3C [2] consortia to bring new qualities of service to the Web services industry. WS-I [3] is actively defining and maintaining profiles to clarify how these standards and specifications should be interpretted in order to foster a high degree of interoperability between different open source and vendor implementations of the standards. Runtimes such as Axis 1.x and, to a much greater extent, Axis2 and its constituent modules are supporting an ever increasing set of these standards and profiles.

The WSE with its own message/transport stack is able to speak basic WSDL 1.1 and SOAP 1.1. It does not understand WS-Security or WS-Secure Conversation. It does not understand how to acquire tokens via a WS-Trust service. It does not speak SOAP 1.2 or MTOM. It does not know how to participate in a WS-Reliable Messaging exchange with a service, or handle asynchronous message exchange patterns involving SOAP messages with WS-Addressing elements. It does not understand WS-Coordination, WS-Atomic Transactions or WS-Business Activity.

Many of these standards are already heavily used in the industry, or are gaining momentum. It is becoming increasingly apparent that the WSE cannot play with such Web services, and increasingly important that it be able to.

In order for the WSE to be able to invoke Web services that exploit these standards, either the WSE's message/transport stack must be upgraded to handle all these standards, or it must be possible for extenders and adopters to replace the WSE's built-in basic message/transport stack by a Web service runtime engine that supports the desired standards.

The former approach is extremely costly, and tips the bulk of the WSE into the role of a Web service runtime, not a Web service tool. The latter approach will keep the WSE focussed on doing what it does well: providing a user interface for end users to explore WSDL and invoke operations with the help of forms and XML views representing the payload of the SOAP envelope without having to care about the WS-* standards or protocol transports in play on the wire. How an XML payload gets embedded within a SOAP envelope and transmitted to a service is a job for whatever Web service runtime engine is plugged-in beneath the WSE.

The purpose of this RFE is to define an extension point and API via which adopters, including WTP itself, can plug-in their own message transports in a fashion that requires no changes or enhancements to the WSE's GUI. How any given message transport stack determines which WS-* standards to enable or disable and how they should be configured is left to the providers of the transport stacks. This may lead to subsequent requirements against the WSE to provide a way to inject new JSP-generated UI controls into the WSE's various frames and forms, however, any such requirements are beyond the scope of this RFE.

More thoughts on the requirements of the extension point and API to come.

[1] http://www.oasis-open.org/home/index.php
[2] http://www.w3.org/
[3] http://www.ws-i.org/