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:51 GMT

Jean-Noel Gadreau wrote:

>  I have sent an e-mail a few days ago explaining (more or less) what changes I was about
to do, in
> case someone is interested. If you want more details on the changes I am working on,
you can have
> a look to an e-mail called "Evolutions on XML-SOAP". I can forward it to you if you want.
> maybe repost it would be good. I'm new to this list.
>  To me, the SOAPAction is just a duplicate of the (URI , localname) in the SOAP-Body
( I think the
> spec specifically says that), so you don't really need the SOAPEngine to know about this
> specific stuff. The way I see it, when the SOAPEngine gets the request, it has already
created an
> "Envelope", which is to me just some checks that it is a valid "SOAP-Envelope". At this
> everything is still DOM Elements. Then, the several EnvelopeProcessors are called and
are going to
> perform operations on the envelope and its context.
> How are these EPs deployed to the SoapEngine? Do they chain results to one another in
> some implicit order?
>  To solve the "getSession()" problem (I have basically a similar problem), my idea was
to have the
> EnvelopeContext passed to the EnvelopeProcessors. The servlet puts some information in
> context, and all the processors can add/change this information. For instance, an
> "AccessControlProcessor" could put some information about whether the user is authenticated.
To do
> that, it could access the HttpServletRequest that was put in the context by the Servlet.
> This seems cool.
>  The advantage of that is that only this accessControlProcessor is tied to the servlet
> so that is you have a SMTP delivery system, you just need to change this processor in
the engine.
> In my proposal, I was also mentionning a kind of "extended RPCCall" where the class providing
> service (like StockQuoteService) would take as first parameter the "EnvelopeContext".
This way,
> this class performing the service can have access to all the information in the context.
> instance, the ExtendedStockQuoteService" could check if the user is authenticated and
then provide
> real-time quotes compared to delayed quotes for non-members.
> This means that every method on the provider would have to take the EnvelopeContext
> parm. Not awful, but why not give a provider the option of implementing an interface,
> as iService, that had a method in it called setEnvelopContext(...). The provider could
> be reflected to see if it implemented the interface and if it did, call setEnvelopContext
> on it. The setEnvelopContext would be guaranteed to be called before each method
> invocation, so the session related stuff would be fresh.
> Personally, I wouldn't be opposed to it being manditory for a provider to implement
> such an  interface.
> If you guys are interested, I can post something as soon as it kinda compiles so you
can see more
> what I am talking about.Jean-Noel
> =============
> 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: Steven McDowall [mailto:sjm@aptest.com]
> Sent: Tuesday, August 08, 2000 12:53 PM
> To: soap-dev@xml.apache.org; soap-user@xml.apache.org
> Subject: RE: Soap Provider classes need access to servlet data
>      I like it .. Sounds very clean and extensible..I think you'll find my Servlet version
>      good base since I decomposed the HTTP part and XML processing away fromthe RPC logic,
>      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
>      theEnvelope after processing it.. RPC Call, etc. etc. In your context, it would
>      determine which EnvelopeProcessorto invoke to process the SOAP thing.. If
>      EnvelopeProcessor was an "Abstract" sort of class, one could sub-class that to provide
>      the real functionsone wanted to perfrom as Rich, etc. wanted (and perhaps provide
>      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
>           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
>           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

View raw message