ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Kopecky <>
Subject Re: IRC Chat Comments
Date Sun, 03 Sep 2000 12:10:34 GMT
Hello James. 8-)

This is a good initial design, here are my comments:

1) To avoid confusion I would rename SOAPDescription to SOAPService,
since service description languages are used to _describe_services_
and SOAPService provides API for working with the service, not with
the description of the service.

2) Does your design allow for id/href references between headers and
body? It was you who first told me this was possible. 8-)

3) As I understand it the only difference of your SOAPPayload and
SOAPHeader classes is in the location of the resulting XML in the
Envelope tree. If we could find a simple way to tell a SOAPPayload
where in the Envelope to put itself, we could derive SOAPHeader by
inheritance from SOAPPayload. Or both these classes could be inherited
from a common SOAPPart (the name can be changed).

4) I still don't understand (nobody has ever attempted to explain it)
why you would not use the "client-side tools" on the server side. It
seems like adding the reverse functionality to all the client-side
tools would make them appropriate to ease handling SOAP messages on
the server side. That would make Envelope, Payload, Header and
Description (Service) common to both sides. That's exactly the
approach we took in IdooXoap - the low level doesn't care whether it's
the server or the client, it only knows a lot about SOAP messages. 8-)

I see you approached from the c++ side, but I think we agreed on the
IRC that "version 3.0" which is supposed to have exactly this kind of
API would actually be more of a rewrite rather than a change of 2.0.

                            Jacek Kopecky
                            Idoox s.r.o.

On Fri, 1 Sep 2000, James Snell wrote:

 > 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:
 >     SOAPEnvelope
 >     SOAPPayload
 >     SOAPHeader
 >     SOAPTransport
 >     SOAPDescription
 > 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
 > attached.  
 > 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,
 > etc).
 > Now, let's look at the server.
 > On the server, we would have the following types of components:
 >    SOAPProcessor
 >    SOAPDescription
 >    SOAPHeaderHandler
 >    SOAPPayloadHandler
 > 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