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 James Snell <js...@lemoorenet.com> on 2000/08/13 00:18:30 UTC
C++ To Do List
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).
>>
Re: C++ To Do List / Status
Posted by Simon Fell <so...@zaks.demon.co.uk>.
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>.
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
Posted by James Snell <js...@lemoorenet.com>.
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
Posted by James Snell <js...@lemoorenet.com>.
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
Posted by Simon Fell <so...@zaks.demon.co.uk>.
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
Posted by Simon Fell <so...@zaks.demon.co.uk>.
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).