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 Jean-Noel Gadreau <jn...@activcard.com> on 2000/08/08 21:20:39 UTC
RE: Soap Provider classes need access to servlet data
I am currently working on a little more generic version that is organized as
follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information is
put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take both
the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be independant
of the servlet (and therefore be reused in the server you are mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea is
to have several "EnvelopeProcessors" that can be used to perform different
tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed and
adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Moving rpcrouter.jsp to a servlet is a good first step. And if the logic in rpcrouter
is being refactored into more reusable, and functionally distinguishable parts, that's
a good thing too. So, I'm not saying I disagree with what's happening, I'm just trying
to determine if this soap-layer we are calling xml-soap is going to solidify and be
a predictable platform on which to base archetectural decisions for our products.
Certainly one thought I have is to build a very specialized version of what I need
and be done with it. But, I believe fairly strongly in standard platforms and open-source
projects have the benefit of a lot of collective wisdom and experience.
So having said that, I'd like to know how providers fit into the architecture?
If I understand you, there would be a flavor of EnvelopProcessor, say
RpcEnvelopProcessor that would decode the soap block, map it to a provider
class instance and invoke a method on that instance. Is that right?
In any case there will be some thing like a provider -- which is the part of the
architecture that fulfills the soap request. These must be deployed by the client
application. Right now this happens via an xml deployment descriptor --
1 per provider.( It would be nice to have an xml deployment descriptor file
that allowed multiple providers.)
A provider should be scoped in at least these ways:
1) session: in which case the provider instance is created for every new session and
has the same lifespan as the session. In this way, the provider itself can be used to
store session specifc data, like for example, an ejb stub. When the HttpSession
goes away, so does the provider instance and any session specific data.
The downside is perhaps excess memory allocation and garbage collecting of
providers. But, these providers could be fairly light weight objects that more or'
less delegate to heavy weight, possibly remote objects.
2) application: in which case the provider instance is created once and for all intents
and purposes it becomes an extension of the servlet.
Another way to handle scoping might be to get rid of it. All providers would
be application scoped. A provider would have to implement an interface
such as iService that had (at least) a method called 'setContext' that would
be called on the provider prior to invoking a method call. This would allow
those providers that need to be aware of the session lifecycle, a way to
get hold of the servlet's session where it could store and retrieve session scoped
data, ie., an ejb stub.
thanks
Steven McDowall wrote:
> Rich,I don't see where the changes Jean-Noel proposes changes the "Architecture" per se.. At
> least, not ata high level. From what I gather, he is abstracting out the HTTP and RPC aspects of
> the current RPC Server to be more extensible. The end result will still be an RPCServlet thing
> that we all know and love plus the ability of having other "things" (like a SOAPServlet that can
> be a sub-class ofsomething..very much along the lines of what you proposed..)Again, where does the
> overall "architecture" change ?As for your question.. I think since xml-soap is still so new (and
> by extension even IBM-SOAP)the lead architect is "consensus" with final say by the committers,
> especially the orignal IBMones (Sanjiva, Matt and Sam..)-Steve
>
> -----Original Message-----
> From: Rich Johns [mailto:rjohns@vignette.com]
> Sent: Tuesday, August 08, 2000 2:51 PM
> To: soap-dev@xml.apache.org
> Subject: Re: Soap Provider classes need access to servlet data
>
> I'm new to this group, having previously spent some time on soap-user.
> I'm confused immediately. So does this work you are about to checkin
> mean that the xml-soap architecture is about to change? Forgive my
> ignorance -- but is there a lead architect that oversees the direction of
> the architecture?
>
> thanks.
>
>
> Jean-Noel Gadreau wrote:
>
> >
> >
> > I am currently working on a little more generic version that is organized as follows:
> >
> > 1) A servlet gets the request and uses the "SOAPEngine" get create an Envelope out of
> > it.
> > 2) A context is created by the servlet (and some transport information is put in the
> > context (such as client IP, HttpServletRequest,...).
> >
> > 3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take both the
> > envelope and the context, process it and return you the response envelope.
> >
> > 4) The servlet then writes this envelope back to the client.
> >
> > What I am trying to achieve with this is:
> > - move all the processing in the "SOAPEngine" so that it can be independant of the
> > servlet (and therefore be reused in the server you are mentioning).
> >
> > - have the servlet only deal with the HTTP part
> > - provide flexibility on what processing is done on the server. My idea is to have
> > several "EnvelopeProcessors" that can be used to perform different tasks (like
> > routing, RPCCall, ...) .
> >
> > I am almost done with the servlet part (by taking what Steven proposed and adapting
> > it) and I will try to merge this with the Servlet that was committed by Sanjiva. I am
> > working on a "RPCCallEnvelopeProcessor" that would contain everything the
> > rpcrouter.jsp (or servlet) is doing. I hope to be able to post some patches against
> > the CVS version by the end of the week that would contain the servlet, a basic
> > "SOAPEngine", and the RPCCallEnvelopeProcessor, so that it will provide the same
> > features as the rpcrouter.jsp.
> >
> > Jean-Noel Gadreau
> > =============
> > Jean-Noel GADREAU
> > Software Engineer, ActivCard Inc.(http://www.activcard.com )
> > E-mail: jngadreau@activcard.com
> > Tel (main): 510-574-0100
> > Tel (direct): 510-574-1736
> >
> >
> >
> > -----Original Message-----
> > From: Glenn Judd [mailto:glennj@cs.cmu.edu]
> > Sent: Tuesday, August 08, 2000 11:34 AM
> > To: soap-user@xml.apache.org
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> >
> >
> > (I haven't followed this discussion too closely, so I
> > apologize in advance if this is out of context.)
> >
> > I'm interested in using SOAP with no JSP, RPCRouter, etc.
> > That is, simply as messaging protocol (both RPC style,
> > and one way messages). I will probably be using http,
> > but listening on my own port (not 80), so routing
> > shouldn't be necessary.
> >
> > The current implementation seems to assume JSP. So,
> > I'm looking at writing my own SOAP layer (that would
> > only support my encoding scheme etc. in order to
> > keep things simple). Naturally, I'd prefer not to
> > if there were a (reasonably thin) generic implementation.
> > Is there any plan to add this functionality, or am
> > I better off writing my own.
> >
> > Glenn
> > glennj@cs.cmu.edu
>
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Moving rpcrouter.jsp to a servlet is a good first step. And if the logic in rpcrouter
is being refactored into more reusable, and functionally distinguishable parts, that's
a good thing too. So, I'm not saying I disagree with what's happening, I'm just trying
to determine if this soap-layer we are calling xml-soap is going to solidify and be
a predictable platform on which to base archetectural decisions for our products.
Certainly one thought I have is to build a very specialized version of what I need
and be done with it. But, I believe fairly strongly in standard platforms and open-source
projects have the benefit of a lot of collective wisdom and experience.
So having said that, I'd like to know how providers fit into the architecture?
If I understand you, there would be a flavor of EnvelopProcessor, say
RpcEnvelopProcessor that would decode the soap block, map it to a provider
class instance and invoke a method on that instance. Is that right?
In any case there will be some thing like a provider -- which is the part of the
architecture that fulfills the soap request. These must be deployed by the client
application. Right now this happens via an xml deployment descriptor --
1 per provider.( It would be nice to have an xml deployment descriptor file
that allowed multiple providers.)
A provider should be scoped in at least these ways:
1) session: in which case the provider instance is created for every new session and
has the same lifespan as the session. In this way, the provider itself can be used to
store session specifc data, like for example, an ejb stub. When the HttpSession
goes away, so does the provider instance and any session specific data.
The downside is perhaps excess memory allocation and garbage collecting of
providers. But, these providers could be fairly light weight objects that more or'
less delegate to heavy weight, possibly remote objects.
2) application: in which case the provider instance is created once and for all intents
and purposes it becomes an extension of the servlet.
Another way to handle scoping might be to get rid of it. All providers would
be application scoped. A provider would have to implement an interface
such as iService that had (at least) a method called 'setContext' that would
be called on the provider prior to invoking a method call. This would allow
those providers that need to be aware of the session lifecycle, a way to
get hold of the servlet's session where it could store and retrieve session scoped
data, ie., an ejb stub.
thanks
Steven McDowall wrote:
> Rich,I don't see where the changes Jean-Noel proposes changes the "Architecture" per se.. At
> least, not ata high level. From what I gather, he is abstracting out the HTTP and RPC aspects of
> the current RPC Server to be more extensible. The end result will still be an RPCServlet thing
> that we all know and love plus the ability of having other "things" (like a SOAPServlet that can
> be a sub-class ofsomething..very much along the lines of what you proposed..)Again, where does the
> overall "architecture" change ?As for your question.. I think since xml-soap is still so new (and
> by extension even IBM-SOAP)the lead architect is "consensus" with final say by the committers,
> especially the orignal IBMones (Sanjiva, Matt and Sam..)-Steve
>
> -----Original Message-----
> From: Rich Johns [mailto:rjohns@vignette.com]
> Sent: Tuesday, August 08, 2000 2:51 PM
> To: soap-dev@xml.apache.org
> Subject: Re: Soap Provider classes need access to servlet data
>
> I'm new to this group, having previously spent some time on soap-user.
> I'm confused immediately. So does this work you are about to checkin
> mean that the xml-soap architecture is about to change? Forgive my
> ignorance -- but is there a lead architect that oversees the direction of
> the architecture?
>
> thanks.
>
>
> Jean-Noel Gadreau wrote:
>
> >
> >
> > I am currently working on a little more generic version that is organized as follows:
> >
> > 1) A servlet gets the request and uses the "SOAPEngine" get create an Envelope out of
> > it.
> > 2) A context is created by the servlet (and some transport information is put in the
> > context (such as client IP, HttpServletRequest,...).
> >
> > 3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take both the
> > envelope and the context, process it and return you the response envelope.
> >
> > 4) The servlet then writes this envelope back to the client.
> >
> > What I am trying to achieve with this is:
> > - move all the processing in the "SOAPEngine" so that it can be independant of the
> > servlet (and therefore be reused in the server you are mentioning).
> >
> > - have the servlet only deal with the HTTP part
> > - provide flexibility on what processing is done on the server. My idea is to have
> > several "EnvelopeProcessors" that can be used to perform different tasks (like
> > routing, RPCCall, ...) .
> >
> > I am almost done with the servlet part (by taking what Steven proposed and adapting
> > it) and I will try to merge this with the Servlet that was committed by Sanjiva. I am
> > working on a "RPCCallEnvelopeProcessor" that would contain everything the
> > rpcrouter.jsp (or servlet) is doing. I hope to be able to post some patches against
> > the CVS version by the end of the week that would contain the servlet, a basic
> > "SOAPEngine", and the RPCCallEnvelopeProcessor, so that it will provide the same
> > features as the rpcrouter.jsp.
> >
> > Jean-Noel Gadreau
> > =============
> > Jean-Noel GADREAU
> > Software Engineer, ActivCard Inc.(http://www.activcard.com )
> > E-mail: jngadreau@activcard.com
> > Tel (main): 510-574-0100
> > Tel (direct): 510-574-1736
> >
> >
> >
> > -----Original Message-----
> > From: Glenn Judd [mailto:glennj@cs.cmu.edu]
> > Sent: Tuesday, August 08, 2000 11:34 AM
> > To: soap-user@xml.apache.org
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> >
> >
> > (I haven't followed this discussion too closely, so I
> > apologize in advance if this is out of context.)
> >
> > I'm interested in using SOAP with no JSP, RPCRouter, etc.
> > That is, simply as messaging protocol (both RPC style,
> > and one way messages). I will probably be using http,
> > but listening on my own port (not 80), so routing
> > shouldn't be necessary.
> >
> > The current implementation seems to assume JSP. So,
> > I'm looking at writing my own SOAP layer (that would
> > only support my encoding scheme etc. in order to
> > keep things simple). Naturally, I'd prefer not to
> > if there were a (reasonably thin) generic implementation.
> > Is there any plan to add this functionality, or am
> > I better off writing my own.
> >
> > Glenn
> > glennj@cs.cmu.edu
>
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
Rich,
I don't see where the changes Jean-Noel proposes changes the "Architecture"
per se.. At least, not at
a high level. From what I gather, he is abstracting out the HTTP and RPC
aspects of the current
RPC Server to be more extensible. The end result will still be an RPCServlet
thing that we all know
and love plus the ability of having other "things" (like a SOAPServlet that
can be a sub-class of
something..very much along the lines of what you proposed..)
Again, where does the overall "architecture" change ?
As for your question.. I think since xml-soap is still so new (and by
extension even IBM-SOAP)
the lead architect is "consensus" with final say by the committers,
especially the orignal IBM
ones (Sanjiva, Matt and Sam..)
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 2:51 PM
To: soap-dev@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
I'm new to this group, having previously spent some time on soap-user.
I'm confused immediately. So does this work you are about to checkin
mean that the xml-soap architecture is about to change? Forgive my
ignorance -- but is there a lead architect that oversees the direction of
the architecture?
thanks.
Jean-Noel Gadreau wrote:
I am currently working on a little more generic version that is
organized as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information
is put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea
is to have several "EnvelopeProcessors" that can be used to perform
different tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed
and adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
Rich,
I don't see where the changes Jean-Noel proposes changes the "Architecture"
per se.. At least, not at
a high level. From what I gather, he is abstracting out the HTTP and RPC
aspects of the current
RPC Server to be more extensible. The end result will still be an RPCServlet
thing that we all know
and love plus the ability of having other "things" (like a SOAPServlet that
can be a sub-class of
something..very much along the lines of what you proposed..)
Again, where does the overall "architecture" change ?
As for your question.. I think since xml-soap is still so new (and by
extension even IBM-SOAP)
the lead architect is "consensus" with final say by the committers,
especially the orignal IBM
ones (Sanjiva, Matt and Sam..)
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 2:51 PM
To: soap-dev@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
I'm new to this group, having previously spent some time on soap-user.
I'm confused immediately. So does this work you are about to checkin
mean that the xml-soap architecture is about to change? Forgive my
ignorance -- but is there a lead architect that oversees the direction of
the architecture?
thanks.
Jean-Noel Gadreau wrote:
I am currently working on a little more generic version that is
organized as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information
is put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea
is to have several "EnvelopeProcessors" that can be used to perform
different tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed
and adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
I'm new to this group, having previously spent some time on soap-user.
I'm confused immediately. So does this work you are about to checkin
mean that the xml-soap architecture is about to change? Forgive my
ignorance -- but is there a lead architect that oversees the direction of
the architecture?
thanks.
Jean-Noel Gadreau wrote:
>
>
> I am currently working on a little more generic version that is organized as follows:
>
> 1) A servlet gets the request and uses the "SOAPEngine" get create an Envelope out of it.
> 2) A context is created by the servlet (and some transport information is put in the context (such
> as client IP, HttpServletRequest,...).
>
> 3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take both the envelope and the
> context, process it and return you the response envelope.
>
> 4) The servlet then writes this envelope back to the client.
>
> What I am trying to achieve with this is:
> - move all the processing in the "SOAPEngine" so that it can be independant of the servlet (and
> therefore be reused in the server you are mentioning).
>
> - have the servlet only deal with the HTTP part
> - provide flexibility on what processing is done on the server. My idea is to have several
> "EnvelopeProcessors" that can be used to perform different tasks (like routing, RPCCall, ...) .
>
> I am almost done with the servlet part (by taking what Steven proposed and adapting it) and I will
> try to merge this with the Servlet that was committed by Sanjiva. I am working on a
> "RPCCallEnvelopeProcessor" that would contain everything the rpcrouter.jsp (or servlet) is doing.
> I hope to be able to post some patches against the CVS version by the end of the week that would
> contain the servlet, a basic "SOAPEngine", and the RPCCallEnvelopeProcessor, so that it will
> provide the same features as the rpcrouter.jsp.
>
> Jean-Noel Gadreau
> =============
> Jean-Noel GADREAU
> Software Engineer, ActivCard Inc.(http://www.activcard.com )
> E-mail: jngadreau@activcard.com
> Tel (main): 510-574-0100
> Tel (direct): 510-574-1736
>
>
>
> -----Original Message-----
> From: Glenn Judd [mailto:glennj@cs.cmu.edu]
> Sent: Tuesday, August 08, 2000 11:34 AM
> To: soap-user@xml.apache.org
> Subject: Re: Soap Provider classes need access to servlet data
>
>
>
> (I haven't followed this discussion too closely, so I
> apologize in advance if this is out of context.)
>
> I'm interested in using SOAP with no JSP, RPCRouter, etc.
> That is, simply as messaging protocol (both RPC style,
> and one way messages). I will probably be using http,
> but listening on my own port (not 80), so routing
> shouldn't be necessary.
>
> The current implementation seems to assume JSP. So,
> I'm looking at writing my own SOAP layer (that would
> only support my encoding scheme etc. in order to
> keep things simple). Naturally, I'd prefer not to
> if there were a (reasonably thin) generic implementation.
> Is there any plan to add this functionality, or am
> I better off writing my own.
>
> Glenn
> glennj@cs.cmu.edu
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
I'm new to this group, having previously spent some time on soap-user.
I'm confused immediately. So does this work you are about to checkin
mean that the xml-soap architecture is about to change? Forgive my
ignorance -- but is there a lead architect that oversees the direction of
the architecture?
thanks.
Jean-Noel Gadreau wrote:
>
>
> I am currently working on a little more generic version that is organized as follows:
>
> 1) A servlet gets the request and uses the "SOAPEngine" get create an Envelope out of it.
> 2) A context is created by the servlet (and some transport information is put in the context (such
> as client IP, HttpServletRequest,...).
>
> 3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take both the envelope and the
> context, process it and return you the response envelope.
>
> 4) The servlet then writes this envelope back to the client.
>
> What I am trying to achieve with this is:
> - move all the processing in the "SOAPEngine" so that it can be independant of the servlet (and
> therefore be reused in the server you are mentioning).
>
> - have the servlet only deal with the HTTP part
> - provide flexibility on what processing is done on the server. My idea is to have several
> "EnvelopeProcessors" that can be used to perform different tasks (like routing, RPCCall, ...) .
>
> I am almost done with the servlet part (by taking what Steven proposed and adapting it) and I will
> try to merge this with the Servlet that was committed by Sanjiva. I am working on a
> "RPCCallEnvelopeProcessor" that would contain everything the rpcrouter.jsp (or servlet) is doing.
> I hope to be able to post some patches against the CVS version by the end of the week that would
> contain the servlet, a basic "SOAPEngine", and the RPCCallEnvelopeProcessor, so that it will
> provide the same features as the rpcrouter.jsp.
>
> Jean-Noel Gadreau
> =============
> Jean-Noel GADREAU
> Software Engineer, ActivCard Inc.(http://www.activcard.com )
> E-mail: jngadreau@activcard.com
> Tel (main): 510-574-0100
> Tel (direct): 510-574-1736
>
>
>
> -----Original Message-----
> From: Glenn Judd [mailto:glennj@cs.cmu.edu]
> Sent: Tuesday, August 08, 2000 11:34 AM
> To: soap-user@xml.apache.org
> Subject: Re: Soap Provider classes need access to servlet data
>
>
>
> (I haven't followed this discussion too closely, so I
> apologize in advance if this is out of context.)
>
> I'm interested in using SOAP with no JSP, RPCRouter, etc.
> That is, simply as messaging protocol (both RPC style,
> and one way messages). I will probably be using http,
> but listening on my own port (not 80), so routing
> shouldn't be necessary.
>
> The current implementation seems to assume JSP. So,
> I'm looking at writing my own SOAP layer (that would
> only support my encoding scheme etc. in order to
> keep things simple). Naturally, I'd prefer not to
> if there were a (reasonably thin) generic implementation.
> Is there any plan to add this functionality, or am
> I better off writing my own.
>
> Glenn
> glennj@cs.cmu.edu
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
RE: Soap Provider classes need access to servlet dataI like it .. Sounds
very clean and extensible..
I think you'll find my Servlet version a good base since I decomposed the
HTTP part and XML processing away from
the RPC logic, so there is probably a lot of good code to grab :-)
Perhaps we could/should use the SOAPAction (currently unused) to determine
what the SOAPEngine should do with the
Envelope after processing it.. RPC Call, etc. etc. In your context, it would
determine which EnvelopeProcessor
to invoke to process the SOAP thing..
If EnvelopeProcessor was an "Abstract" sort of class, one could sub-class
that to provide the real functions
one wanted to perfrom as Rich, etc. wanted (and perhaps provide some useful
methods like getSession(), etc.
to provide data they want on a context basis)..
This sounds very promising to me..
-Steve
-----Original Message-----
From: Jean-Noel Gadreau [mailto:jngadreau@activcard.com]
Sent: Tuesday, August 08, 2000 2:21 PM
To: 'soap-user@xml.apache.org'; 'soap-dev@xml.apache.org'
Subject: RE: Soap Provider classes need access to servlet data
I am currently working on a little more generic version that is organized
as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information is
put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea is
to have several "EnvelopeProcessors" that can be used to perform different
tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed and
adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
RE: Soap Provider classes need access to servlet dataI like it .. Sounds
very clean and extensible..
I think you'll find my Servlet version a good base since I decomposed the
HTTP part and XML processing away from
the RPC logic, so there is probably a lot of good code to grab :-)
Perhaps we could/should use the SOAPAction (currently unused) to determine
what the SOAPEngine should do with the
Envelope after processing it.. RPC Call, etc. etc. In your context, it would
determine which EnvelopeProcessor
to invoke to process the SOAP thing..
If EnvelopeProcessor was an "Abstract" sort of class, one could sub-class
that to provide the real functions
one wanted to perfrom as Rich, etc. wanted (and perhaps provide some useful
methods like getSession(), etc.
to provide data they want on a context basis)..
This sounds very promising to me..
-Steve
-----Original Message-----
From: Jean-Noel Gadreau [mailto:jngadreau@activcard.com]
Sent: Tuesday, August 08, 2000 2:21 PM
To: 'soap-user@xml.apache.org'; 'soap-dev@xml.apache.org'
Subject: RE: Soap Provider classes need access to servlet data
I am currently working on a little more generic version that is organized
as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information is
put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea is
to have several "EnvelopeProcessors" that can be used to perform different
tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed and
adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
RE: Soap Provider classes need access to servlet dataI like it .. Sounds
very clean and extensible..
I think you'll find my Servlet version a good base since I decomposed the
HTTP part and XML processing away from
the RPC logic, so there is probably a lot of good code to grab :-)
Perhaps we could/should use the SOAPAction (currently unused) to determine
what the SOAPEngine should do with the
Envelope after processing it.. RPC Call, etc. etc. In your context, it would
determine which EnvelopeProcessor
to invoke to process the SOAP thing..
If EnvelopeProcessor was an "Abstract" sort of class, one could sub-class
that to provide the real functions
one wanted to perfrom as Rich, etc. wanted (and perhaps provide some useful
methods like getSession(), etc.
to provide data they want on a context basis)..
This sounds very promising to me..
-Steve
-----Original Message-----
From: Jean-Noel Gadreau [mailto:jngadreau@activcard.com]
Sent: Tuesday, August 08, 2000 2:21 PM
To: 'soap-user@xml.apache.org'; 'soap-dev@xml.apache.org'
Subject: RE: Soap Provider classes need access to servlet data
I am currently working on a little more generic version that is organized
as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information is
put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea is
to have several "EnvelopeProcessors" that can be used to perform different
tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed and
adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
RE: Soap Provider classes need access to servlet dataI like it .. Sounds
very clean and extensible..
I think you'll find my Servlet version a good base since I decomposed the
HTTP part and XML processing away from
the RPC logic, so there is probably a lot of good code to grab :-)
Perhaps we could/should use the SOAPAction (currently unused) to determine
what the SOAPEngine should do with the
Envelope after processing it.. RPC Call, etc. etc. In your context, it would
determine which EnvelopeProcessor
to invoke to process the SOAP thing..
If EnvelopeProcessor was an "Abstract" sort of class, one could sub-class
that to provide the real functions
one wanted to perfrom as Rich, etc. wanted (and perhaps provide some useful
methods like getSession(), etc.
to provide data they want on a context basis)..
This sounds very promising to me..
-Steve
-----Original Message-----
From: Jean-Noel Gadreau [mailto:jngadreau@activcard.com]
Sent: Tuesday, August 08, 2000 2:21 PM
To: 'soap-user@xml.apache.org'; 'soap-dev@xml.apache.org'
Subject: RE: Soap Provider classes need access to servlet data
I am currently working on a little more generic version that is organized
as follows:
1) A servlet gets the request and uses the "SOAPEngine" get create an
Envelope out of it.
2) A context is created by the servlet (and some transport information is
put in the context (such as client IP, HttpServletRequest,...).
3) The SOAPEngine contains a "EnvelopeProcessor" that is going to take
both the envelope and the context, process it and return you the response
envelope.
4) The servlet then writes this envelope back to the client.
What I am trying to achieve with this is:
- move all the processing in the "SOAPEngine" so that it can be
independant of the servlet (and therefore be reused in the server you are
mentioning).
- have the servlet only deal with the HTTP part
- provide flexibility on what processing is done on the server. My idea is
to have several "EnvelopeProcessors" that can be used to perform different
tasks (like routing, RPCCall, ...) .
I am almost done with the servlet part (by taking what Steven proposed and
adapting it) and I will try to merge this with the Servlet that was
committed by Sanjiva. I am working on a "RPCCallEnvelopeProcessor" that
would contain everything the rpcrouter.jsp (or servlet) is doing. I hope to
be able to post some patches against the CVS version by the end of the week
that would contain the servlet, a basic "SOAPEngine", and the
RPCCallEnvelopeProcessor, so that it will provide the same features as the
rpcrouter.jsp.
Jean-Noel Gadreau
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 11:34 AM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
(I haven't followed this discussion too closely, so I
apologize in advance if this is out of context.)
I'm interested in using SOAP with no JSP, RPCRouter, etc.
That is, simply as messaging protocol (both RPC style,
and one way messages). I will probably be using http,
but listening on my own port (not 80), so routing
shouldn't be necessary.
The current implementation seems to assume JSP. So,
I'm looking at writing my own SOAP layer (that would
only support my encoding scheme etc. in order to
keep things simple). Naturally, I'd prefer not to
if there were a (reasonably thin) generic implementation.
Is there any plan to add this functionality, or am
I better off writing my own.
Glenn
glennj@cs.cmu.edu