ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <>
Subject Re: IRC Chat Comments
Date Sun, 03 Sep 2000 03:52:07 GMT

James (Jim?),
I think this is a very good starting point for a layered/plug-in architecture.
I am also considering a plug-in architecture, developing a prototype.  I am
addressing intermedairies,
and header processing there.  From this point, I have some comments on your

Subclassing of Header class
In our prototype, we do not subclass SOAPHeader, instead, we requires
users to define their own SOAPHeaderProcessor classes.  In our definition,
SOAPHeaderProcessor is provides a
SOAP-in and SOAP-out method, and users place some SOAPHeaderProcessors between
the client application and
a transport class (it corresponds to your SOAPTransport).  In the same manner,
when users develop server applications,
they can place SOAPHeaderProcessor classes between a server transport class and
an actual server application.
Moreover, in an intermediary, users can put SOAPHeaderProcessor classes between
a server transport class (receiver side) and a client transport (sender side).
In summary, we have a pipeline or cascading architecture in the prototype.
Therefore, the end-to-end messaging can be considered as a chain of
SOAP-in/SOAP-out components
including header handlers and transport abstractioin classes.
I want to make sure your header subclassing approach.  When we sign on the body
of the envelope, we need to refer Body.
Does SOAPHeader have a referenct to Body element?

Subclassing of Payload class
I do not have a strong opinion this class.  However, instead of Subclassing of
Payload, we may be able to add Payload
preprocessor (e,g, RPCEncoding).

SOAPTransport is typically a client or sender side abstraction for transport.
On the other hand, SOAPProcessor is a receiver side transport abstraction (and
more?).  When we take a look at JMS (Java Messaging System), it has a
QueueSender and QueueReceiver classes.  I think this kind of distinction should
be required for a clear design.

At the server side, HeaderHandlers are cofigured based on SOAPDescription.
However, they are configured in SOAPProcessor AND PayloadHandler (Is it right).
Regarding your DSig example, I think signature should be verified
a handler registered to SOAPProcessor, then passed to PayloadHandler.  Does it
make sense?

Apparently we need a class to register header handler classes.  SOAPProcessor
seems to one that plays such role, but it is also an abstraction of receiver
side transport.  (correct me if I am wrong)
I am not that SOAPProcessor is an adequate name because it has a mechanism to
invoke appropriate header handlers for
incoming messages.  Apart from the naming, I think SOAPProcessor can be used for
intermediaries and even client.  For example, we may want to sign and encrypt a
message in this order.  If we registere handler classes to SOAPProcessor,
it invokes signature and encryption handlers in this order.

This peforms an actual configuration of header handlers, transports, etc.  At
this moment, I have no idea on this.

p.s. Are you going to detail your architecture design?  I am wondering if I can
contribute to such activity.

Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413

From: James Snell <> on 2000/09/02 01:38

Please respond to

To:   "''" <>
cc:    (bcc: Yuhichi Nakamura/Japan/IBM)
Subject:  IRC Chat Comments

Sorry I had to miss the chat the other day, but I've read through the
transcripts and like what I saw.  My input is this:

Our primary focus has to be on the creation of an extensible plug-in
architecture.  By the comments made during the chat, I believe that this is
something we all agree on.  Here's the tack that I propose we take.

The client side tools are centered around five base classes:


These classes are nothing more than thin wrappers for the Xerces C and Xalan
C components, and handle the specific semantics of generating SOAP Requests.

The SOAPPayload class represents the body of the message.  It provides a set
of methods (API still being defined) for attaching an arbitrary DOM Node to
the body of a SOAP Envelope.  The SOAPPayload class could be used directly,
or used as the base of any number of derived classes.  A developer would
derive a new class from SOAPPayload to specifically handle specific types of
messages or XML documents.

For example, in order to more easily deal with the semantics of a RPC
message, we would create a SOAPRPCPayload class that derives from the
SOAPPayload class.  This new class would extend the interface of the
SOAPPayload by adding methods such as "setMethod" and "setParameter", etc.

SOAPHeaders would be handled in much the same way.  The SOAPHeader class
exposes a base set of methods that deal directly with attaching arbitrary
DOM Nodes as headers in the SOAP Envelope header section, as well as the
task of adding the mustUnderstand and actor attributes to the node being

In order to extend SOAP by layering in new application services through the
use of Headers, developers would simply derive new SOAP Header classes from
the SOAPHeader base.  For example, if we wanted to create an implementation
of the XML Digital Signatures for SOAP, then we could create a
SOAPDigSigHeader class that derives from SOAPHeader.  The SOAPDigSigHeader
would expose specific methods for creating and embedding the digital
signature within the SOAP Envelope.

SOAPDescription is a class that handles the automatic encoding of SOAP
Envelopes based on whichever Service Description grammar we decide to move
forward with.  The SOAPDescription class would automatically create an
instance of the SOAPEnvelope class (and underlying XML Document) based on
the Schema's declared within the Service Description.  Using the base
SOAPHeader and SOAPPayload API's, the SOAPDescription would set all of the
necessary parameters for the message.  When special extended functionality
(contained in other arbitrary code modules), then an approach similar to
that used in the Apache MOD architecture could be used -- dynamically
loading the necessary code modules to perform specific tasks.  The specifics
of this are a little more in depth than I'd like to go right now, but I
think this might be a good approach to take.

SOAPTransport is a generic base class that defines the core API of
transmitting Requests and parsing Responses.  Developers would have to
derive specific transport protocol implementations from the base
SOAPTransport class (SOAPHTTPTransport for instance, or SOAPSMTPTranport,

Now, let's look at the server.

On the server, we would have the following types of components:


The SOAPProcessor is the core of the server side classes.  When a SOAP
message is received, whichever mechanism is used as the listening interface
passes the message off to the SOAP Processor.  The SOAP Processor examines
the message for basic SOAP compliance, then, using a xml-based configuration
file, associates each part of the message (each Header and Payload) with a
specific Handler component.  The XML-Configuration file basically says that
all XML components with XYZ Namespace declaration are to be passed off to
the ABC Handler Class.

The SOAPDescription (same as the client side SOAPDescription) is used to
validate the structure of the incoming SOAP request (all required parts are
present and accounted for as well as proper schema, etc), and also as the
mechanism for automatically encoding responses for incoming messages that
require a response (such as RPC-style messages).

The SOAPHeaderHandler is an abstract class that defines the base API of all
SOAP Header Handlers.  A Header Handler is any code module designed to
handle the specific semantics of any arbitrary SOAP Header (identified by
its declared namespace).  In other words, just like we had a custom
SOAPDigSigHeader class for the client side, we would have a custom
SOAPDigSigHeaderHandler class on the server to deal with parsing and
validating the digital signature embedded in the SOAP envelope.

Any single SOAP message can invoke any number of SOAP Header Handlers.

The SOAPPayloadHandler is an abstract class that defines the base API of all
SOAP Payload Handlers.  A Payload Handler is any code module designed to
handle the specific semantics of any arbitrary SOAP Payload (identified by
its declared namespace).  For example, we might create a
SOAPRPCPayloadHandler to handle the specifics of a RPC-style message sent by
the client.

The relationship between the SOAPHeaderHandler and the SOAPPayloadHandler is
very important.  SOAP Headers provide context to SOAP Paylods.  The
SOAPProcessor will create an instance of each required Header Handler and
pass those instances into the Payload Handler.  It is up to the Payload
Handler to properly deal with the Context provided by the Headers.  In other
words, if an XML Digital Signature header is passed into the RPC Message
Handler, it is up to the Message Handler to validate the digital signature
before executing the RPC request.

Again, many of the specific SOAP extensions (custom Payload and Header
Handlers) are going to be implemented in separate physical code modules
(DLL's for instance).  To handle this, all we need is to implement a similar
mechanism that Apache uses to import MODs.

Optional Components:

Some optional things we might want to look at implementing is something
along the lines of what the BizTalk server does with messages.  When a
message is received, a developer has the option of automatically routing it
through a series of steps using what is known as an XLANG schedule (you can
read more about this on the Microsoft MSDN site).  Our SOAP Processor's
XML-configuration file, in conjunction with the Service Description file,
could accomplish pretty much the same kind of workflow architecture, routing
a series of messages through a series of steps according to a developer
defined schedule.  (This is basically the same concept as routing a HTTP
request through multiple chained servlets on a Java web server).

Any way, those are my thoughts on the subject.  It would be my hope that the
C/C++ implementation we put together meets the above specification at least
in spirit.  If so, I'd like to see the java implementation changed to meet
the same specification.

- James Snell

View raw message