ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <>
Subject RE: IRC Chat Comments
Date Mon, 04 Sep 2000 17:24:23 GMT
Comments inline:

-----Original Message-----
From: Yuhichi Nakamura []
Sent: Saturday, September 02, 2000 8:52 PM
Subject: Re: IRC Chat Comments

>>James (Jim?),

Don't matter to me... I'll still know who you're talking about ;-)

>>I think this is a very good starting point for a layered/plug-in
>>I am also considering a plug-in architecture, developing a prototype.  I
>>addressing intermedairies,
>>and header processing there.  From this point, I have some comments on
>>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
>>the client application and
>>a transport class (it corresponds to your SOAPTransport).  In the same
>>when users develop server applications,
>>they can place SOAPHeaderProcessor classes between a server transport
class and
>>an actual server application.

Hmm.. I was thinking something along these lines.. please let me know if
this is something close to the architecture you are envisioning:

  The MS BizTalk Server uses an XML grammar called XLANG to schedule the
flow of a message (or messages) through a stream of application components
(scripts, dll, etc).  XLANG includes some basic flow logic (loops,
conditionals, etc).

  My end goal would be something similar to this architecture.

  First, the developer creates the workflow logic, called a schedule.  This
schedule would specify a number of nodes through which to route a particular
message throughout it's entire life cycle.  Each node would be represented
by a single Payload Handler and X number of Header Handlers.

  I haven't worked out all of the implementation details, but you should be
able to get a decent idea of the architecture here.  Each node can either be
represented by a code component on the server, or another SOAP Server (in
the case of intermediaries).

  What do you think?

>>Moreover, in an intermediary, users can put SOAPHeaderProcessor classes
>>a server transport class (receiver side) and a client transport (sender
>>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
>>of the envelope, we need to refer Body.
>>Does SOAPHeader have a referenct to Body element?

Yes it can.  But it doesn't have to.  Imagine we have a Header class that
digitally signs the Payload body.  Then we would have something like:

  SOAPDigSigHeader header = new SOAPDigSigHeader();
  SOAPPayload payload = new SOAPPayload();


We pass a reference to the Payload using the signPayload method.  The header
retains the reference to the payload for the life of the header (or payload)
or until the headers destroySignature method (or something equivalent) is

>>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).

I think either approach would work (coming from my COM background, I always
tend to think in terms of subclassing, etc :-) ..)

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

This makes a lot of sense.  Instead of SOAPTransport/SOAPProcessor, we use
SOAPSender and SOAPReceiver?

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

The SOAPDescription would serve three purposes:

   1. To provide clients with the basic description of SOAP requests
(exactly what SDL, NASSL and SCL do today)
   2. To describe the workflow schedule used by the processing stream (see
my comments regarding XLANG above)
   3. To provide a registry of Payload and Header Handlers.

Header Handlers could be registered globally (used by the
SOAPProcessor/SOAPReceiver directly, as in the case of verifying Digital
Signatures, decryption, etc) or registered locally (used by the

>>Apparently we need a class to register header handler classes.
>>seems to one that plays such role, but it is also an abstraction of
>>side transport.  (correct me if I am wrong)
>>I am not that SOAPProcessor is an adequate name because it has a mechanism
>>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.

Perhaps we could use a SOAPHandlerRegistry class?

>>This peforms an actual configuration of header handlers, transports, etc.
>>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.

I actually need an implementation of this very very soon, so, all the help I
can get would be great! :-)

- James

View raw message