xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Fell <s...@zaks.demon.co.uk>
Subject Re: C++ To Do List / Status
Date Sun, 27 Aug 2000 16:22:37 GMT
ok, after a long and hard battle with VMWare/Debian/X/Samba/CVS i have
a very basic transport class that supports http, and compiles / runs
on WIN32 (vc6/sp4) & Linux (gcc v2.95.2). I'm going to clean it up,
and post it. 


On Sat, 12 Aug 2000 15:41:26 -0700, in soap you wrote:

>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.
>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
>>Primary Items
>>1. SOAPEnvelopeWriter, SOAPEnvelopeReader, SOAPEnvelope, SOAPHeader and
>>SOAPPayload objects
>>2. SOAPTransport, SOAPHTTPTransport (with SSL support), and
>>   -> 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
>>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
>>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
>>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
>>creates an instance of the message handler, then passes in the payload +
>>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
>>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).

View raw message