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 Wed, 06 Sep 2000 00:51:47 GMT

I added comments:

JS> Hmm.. I was thinking something along these lines.. please let me know if
JS> this is something close to the architecture you are envisioning:
JS>   The MS BizTalk Server uses an XML grammar called XLANG to schedule the
JS> flow of a message (or messages) through a stream of application components
JS> (scripts, dll, etc).  XLANG includes some basic flow logic (loops,
JS> conditionals, etc).
JS>   My end goal would be something similar to this architecture.
JS>   First, the developer creates the workflow logic, called a schedule.  This
JS> schedule would specify a number of nodes through which to route a particular
JS> message throughout it's entire life cycle.  Each node would be represented
JS> by a single Payload Handler and X number of Header Handlers.
JS>   I haven't worked out all of the implementation details, but you should be
JS> able to get a decent idea of the architecture here.  Each node can either be
JS> represented by a code component on the server, or another SOAP Server (in
JS> the case of intermediaries).
JS>   What do you think?
It makes a lot of sense to me.  Our framework only provides a simple (the
container class, into which users can add SOAPHeaderProcessor's for processing
requests and responses.  In that sense, the container class is a fixed flow
Although SOAPHeaderProcessor is extensible, I have not come up with a concrete
I am not familiar with XLANG, but such extension seems promising.

JS> Yes it can.  But it doesn't have to.  Imagine we have a Header class that
JS> digitally signs the Payload body.  Then we would have something like:
JS>   SOAPDigSigHeader header = new SOAPDigSigHeader();
JS>   SOAPPayload payload = new SOAPPayload();
JS>   header.signPayload(payload);
JS> We pass a reference to the Payload using the signPayload method.  The header
JS> retains the reference to the payload for the life of the header (or payload)
JS> or until the headers destroySignature method (or something equivalent) is
JS> called.

It seems OK with your sample.  However, I could not imagine how to combine this
idea with
your workflow architecture.

Let me give you an excerpt from our sample program:

        SequentialPipe seq = new SequentialPipe();
        ClientEndpoint ep = new ClientEndpoint(new HttpConnection(), targetURL);
        seq.addRequestProcessor(new SignatureHandler(.....));
        seq.addResponseProcessor(new SignatureHandler(......));

SequentialPipe is a container to include header processors mentioned above.
SignatureHandler is a class to sign on payload, adding signature header entry to
the envelope.
ClientEndpoint is an abstraction of transport protocol.
This sample shows how to configure header processors (and transport).  At
SOAP envelopes flow along with the configuration.  I feel that
clear separation of flow design (configration) and data (envelope) contribute to
the comprehensive design.  On the other hand, when we have subclasses of header
class such
as SOAPDSigHeader, how do data and logic flow along the configuration?
I want to understand the architecture design more precisely.

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

JS> This makes a lot of sense.  Instead of SOAPTransport/SOAPProcessor, we use
JS> SOAPSender and SOAPReceiver?
We need to first clarify the design.

JS> The SOAPDescription would serve three purposes:
JS>    1. To provide clients with the basic description of SOAP requests
JS> (exactly what SDL, NASSL and SCL do today)
JS>    2. To describe the workflow schedule used by the processing stream (see
JS> my comments regarding XLANG above)
JS>    3. To provide a registry of Payload and Header Handlers.
JS> Header Handlers could be registered globally (used by the
JS> SOAPProcessor/SOAPReceiver directly, as in the case of verifying Digital
JS> Signatures, decryption, etc) or registered locally (used by the
JS> PayloadHandlers).

Let me wait for the official announcement of UDDI.  You will see it soon. (Sep,

JS> Perhaps we could use a SOAPHandlerRegistry class?
SOAPHandlerRegistry seems just a static library.
SOAPProcessor seems to indicate a particular configration of header/payload
I just want to say that there is not clear separation of transport/processor at
the server side.

JS> I actually need an implementation of this very very soon, so, all the help I
JS> can get would be great! :-)
Let me send code to Apache as soon as I get an approval from our management.

View raw message