v3.0 Architecture proposal: WSDD and ICF

[Stephen Graham/Raleigh/IBM <sg...@us.ibm.com>]

Folks:
Here is a document outlining a proposal for a couple of components (Web
Services Deployment Descriptor (WSDD) and Intermediary Chaining Framework
(ICF)) in the SOAP v3.0 architecture work.  This work can be regarded as
refinements to some of the SOAP v3.0 architecture proposals posted to date.
There is of course much work to do, but this proposal is a start.

The document is quite long (sorry), but much of the length is due to the
inclusion of several examples of WSDL and a proposed related format called
WSDD, or Web Services Deployment Descriptor.  XML is bulky.  We also took
the time to explain in some detail a Purchase Order scenario and how it
exercises the WSDD and ICF components.

(See attached file: WSDD Use Example v10a.pdf)

This document reviews a scenario motivating the benefits of describing
intermediaries ( aka headerhandlers, messagehandlers, etc.) in terms of web
services.  This results in an extensible component model for the SOAP v3.0
engine and a very natural deployment programming model for web services
engineers to describe the processing on input, output and fault flows
related to their web service.  The web services engineer uses a WSDD file
to configure the "kinds" of intermediaries that must appear on the input,
output and fault flows to his/her web service.  The SOAP engine itelf is
responsible for associating an intermediary web service implementation for
each intermediary "kind" described in a WSDD.  Intermediary web services
can be "deployed" resident in the engine, or can they can be remotely
invoked.  An engine component (called for now the ICF) builds chains of
these intermediaries for each input, output and fault flow described by the
service and encapsulates the detail of invoking the intermediary web
service.  As a side effect, the WSDL describing the target web service is
updated to reflect any requirements the intermediaries may have (eg a
digital Signature header is required on the input flow).

At runtime, the engine is responsible for receiving the message from the
transport listener, converting the message into a cannonical form
(variously called SOAPMessage, SOAPContext or MessageContext object),
retrieving the input chain generated by the ICF generator, and invoking the
chain.  The chain walks through each intermediary, invoking the
intermediary web service, merging the results of the intermediary into the
SOAPMessage and eventually invoking the target web service.  The output or
fault flows go through the ICF in symmetric fashion.

Of course the WSDD can be used recursively.  Because the intermediaries are
themselves web services, there can be chains associated with the input,
output and fault flows of the intermediary web service itself.  The
document reviews a scenario where this facility is quite useful.

Please post comments on this document to the soap-dev mailing list.

I look forward to your comments.
sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies
++++++++