xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Johns <rjo...@vignette.com>
Subject Re: Soap Provider classes need access to servlet data
Date Tue, 08 Aug 2000 21:30:39 GMT
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.


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
> 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
>     >
>     > 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
>     > 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
>     > 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
>     > 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
>     > 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

View raw message