xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: C++ To Do List
Date Sat, 12 Aug 2000 22:41:26 GMT
Xerces-C is what I am using for the SOAPEnvelope classes.  OpenSLL is fine
as long as it has ports for all of the major OS's (I'm not too familiar with
the product).

- James

-----Original Message-----
From: Simon Fell [mailto:soap@zaks.demon.co.uk]
Sent: Saturday, August 12, 2000 3:27 PM
To: soap-dev@xml.apache.org
Subject: Re: C++ To Do List


I can take #2 if you're ok with using OpenSLL for SSL support ?

Which parser are we using ?, Xerces-C has some multi platform network
support we should be able to re-use.

Cheers
Simon

On Sat, 12 Aug 2000 15:18:30 -0700, in soap you wrote:

>Here's a basic to do list for the C++ implementation I've been working on.
>I'm working on Step 1, if any body would like to pick up any of the other
>steps, let me know which one.
>
>- James Snell
>
>
>
>TODO:
>
>Primary Items
>
>1. SOAPEnvelopeWriter, SOAPEnvelopeReader, SOAPEnvelope, SOAPHeader and
>SOAPPayload objects
>
>2. SOAPTransport, SOAPHTTPTransport (with SSL support), and
>SOAPSMTPTransport
>   -> These are the client side transports.  SOAPTransport would be the
>basic Interface description. SOAPHTTPTransport and SOAPSMTPTransport being
>the actual code implementations.  Basically, they would receive an instance
>of a SOAPEnvelope and transmit it over the wire.
>
>3. Transport Protocol Listener bindings (to receive and dispatch messages
to
>the SOAPProcessor)
>   -> Apache MOD, IIS ISAPI, Netscape NSAPI, etc
>
>   -> These are the server side bindings.  All they will basically do is
>forward the received message on to the SOAPProcessor component.  I think it
>would be cool to include SMTP-based Server side bindings also, so if
anybody
>has any ideas I'd love to hear 'em.
>
>4. SOAPProcessor And Configuration Engine
>   -> Here's what I'm thinking:
>
>      1. Message Is Received by the listener, forwarded on to the processor
>      2. The processor uses an XML based configuration file to link a
>particular type of message to a particular message handler.  Also defined
in
>the configuration are mappings linking particular SOAP Header's (identified
>by their namespaces) to a particular Header Handler component.
>      3. The processor creates an instance of each releveant Header
Handler,
>creates an instance of the message handler, then passes in the payload +
all
>of the references to the various Header Handlers in use for processing by
>the Message Handler.
>
>5. MessageHandler and HeaderHandler Interfaces and Language Bindings (C++,
>COM, CORBA, Java, Perl)
>   -> The MessageHandler's and HeaderHandler's perform all of the actual
>custom work.  HeaderHandlers basically provide contextual support for the
>MessageHandler by 1) providing access to the information passed in SOAP
>Headers and 2) executing the code relevant to the proper handling of the
>Header as defined in the Header specification (I'll try to explain this
more
>in depth later).
>
>6. SOAPRPCPayload, SOAPRPCHandler (with multiple language bindings) objects
>
>   -> The SOAPRPCPayload is a custom implementation of the SOAPPayload
>interface used on the client for building SOAP Envelopes.  It will expose
>such functions as "setMethod" and "setParameter".
>
>   -> The SOAPRPCHandler is a custom implementation of the MessageHandler
>interface used on the server for processing RPC-style SOAP messages.  I
>imagine that a different SOAPRPCHandler can be used for various language
>bindings (the custom MessageHandler essentially becomes a bridge to the
>targeted language).



Mime
View raw message