You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Simon Fell <so...@zaks.demon.co.uk> on 2000/08/27 18:22:37 UTC
Re: C++ To Do List / Status
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.
Cheers
Simon
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.
>
>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).
>
Re: C++ To Do List / Status
Posted by Simon Fell <so...@zaks.demon.co.uk>.
well, here it is. Its obviously far from complete, but does work.
Hopefully we can starting putting this together.
its been built & tested on
Windows 2000 Server with VC6/SP4
Linux/Debian 2.2 with gcc 2.95.2
I've been following the basic guidelines from Xerces for the code (no
STL or templates).
James, any chance you can post your code for Envelope classes ?
Cheers
Simon
On Sun, 27 Aug 2000 09:22:37 -0700, in soap you wrote:
>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.
>
>Cheers
>Simon
>
>
>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.
>>
>>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).
>>
Re: C++ To Do List / Status
Posted by Simon Fell <so...@zaks.demon.co.uk>.
well, here it is. Its obviously far from complete, but does work.
Hopefully we can starting putting this together.
its been built & tested on
Windows 2000 Server with VC6/SP4
Linux/Debian 2.2 with gcc 2.95.2
I've been following the basic guidelines from Xerces for the code (no
STL or templates).
James, any chance you can post your code for Envelope classes ?
Cheers
Simon
On Sun, 27 Aug 2000 09:22:37 -0700, in soap you wrote:
>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.
>
>Cheers
>Simon
>
>
>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.
>>
>>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).
>>