xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Octav Chipara <ochip...@cse.unl.edu>
Subject Re: Apache C++ SOAP Implementation Proposed Architecture
Date Tue, 08 Aug 2000 21:59:40 GMT

> 
> 
> SOAP Envelope Objects
> -------------------------------------
>           	EnvelopeWriter
> 		Creates and builds an instance of the SOAPEnvelope object
> 
>           	EnvelopeReader
> 		Parses and Reads an instance of the SOAPEnvelope Object
>           	SOAPEnvelope
> 		Represents any Valid SOAP V1.1 Envelope
> 
> 	SOAPHeader
> 		Base Class representing any valid SOAP V1.1 Header element.
> Any extensions to the SOAP implementation based on extended SOAP Headers
> would derived from the SOAPHeader Object.  For example, if you wanted to add
> security support into the SOAPEnvelope based on SOAP Headers then you would
> derive a SOAPSecurityHeader class from the SOAPHeader class, etc.  I'll give
> more details on this later.
> 
> 	SOAPPayload
> 		Base Class representing any valid SOAP V1.1 Payload.  Works
> the same way as the SOAPHeader.  The SOAPPayload object can be used directly
> to edit/read the payload of the SOAP Envelope, or you can derive new classes
> from the SOAPPayload to create Message specific payload handlers.  For
> example, if you intend to use SOAP for RPC, then you might derive a
> SOAPRPCPayload class from SOAPPayload and add methods such as "setMethod"
> and "setParameter", etc.



I totaly agree ... I have kind of a naming problem with the first two ...
but conceptually you are right.

> 
> 
> Transport Objects
> -------------------------------------
> 	EnvelopeTransport
> 		Interface representing the base functionality that all SOAP
> Envelope Transport instances must expose
> 
> 	HTTPTransport
> 		HTTP Based Envelope transport derived from the
> EnvelopeTransport interface
> 
> 	HTTSTransport
> 	SMTPTransport


This sounds correct.

> 
> Service Description Objects
> -------------------------------------
> 	DescriptionReader
> 		Interface representing the base functionality that all
> DescriptionReader instances must expose
> 
> 	DescriptionWriter
> 		Interface representing the base functionality that all
> DescriptionWriter instances must expose


I do not think that we should worry about the Description Writer. I think
a separate application would do the trick. I do not see this as this as
part of the main code ... I see it as more of a tool ...


> 
> 	NASSLReader
> 		Class capable of parsing and reading NASSL documents.
> Through the DescriptionReader interface, the NASSLReader will be capable of
> generating valid SOAPEnvelope objects
> 
> 	NASSLWriter
> 		Class capable of generating NASSL documents
> 
> 	SDLReader
> 	SDLWriter
> 	SCLReader
> 	SCLWriter
> 
> 
> 
> Dispatcher Objects
> -------------------------------------
> 	MessageDispatcher
> 		The Message Dispatcher is a special object that uses a
> configuration XML document to link the contents of a SOAPEnvelope to a
> specific set of code components (Handlers) specifically designed to handle
> the messages semantics.  For example, a message intended for standard RPC
> use would use a RPCHandler. 
> 
> 

OK ...

> Handler Objects
> -------------------------------------
> 	HeaderHandler
> 		Interface representing the base functionality that all SOAP
> Header Handlers must expose.  A Header Handler is any component specifically
> designed to process the semantics of a particular SOAP Header.  Header
> Handlers are linked to a Header through the use of a configuration XML file
> used by the Message Dispatcher Object
> 
> 	PayloadHandler
> 		Interface representing the base functionality that all SOAP
> Payload Handlers must expose.  A Payload Handler is any component
> specifically designe dto proces the semantics of a particular SOAP Payload.
> Payload Handlers are linked to a Payload through the use of a configuration
> XML file use by the Message Dispatcher
> 
> 
> Standard Handler Instances (derived from PayloadHandler)
> -------------------------------------
> 	CRPCHandler
> 		Handles RPC messages to generic C++ classes exposed by DLL's
> 
> 	JRPCHandler
> 		Handles RPC messages to java classes
> 
> 	COMRPCHandler
> 		Handles RPC messages to COM objects
> 
> 	CORBARPCHandler
> 		Handles RPC messagers to CORBA objects
> 
> 

This sound cool ... My only problem is what are you going to do to address
the platform independence issue.


PS: I would like to help in the development ... Please let me know how can
I help ... :-)


- Octav


Mime
View raw message