xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <jngadr...@activcard.com>
Subject RE: Soap Provider classes need access to servlet data
Date Tue, 08 Aug 2000 20:45:34 GMT
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.
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 HTTP 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 point, everything is still DOM Elements. Then, the
several EnvelopeProcessors are called and are going to perform operations on
the envelope and its context.
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 the 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
The advantage of that is that only this accessControlProcessor is tied to
the servlet front-end, 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 the 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. For instance, the
ExtendedStockQuoteService" could check if the user is authenticated and then
provide real-time quotes compared to delayed quotes for non-members.
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.
Software Engineer, ActivCard Inc.( http://www.activcard.com
<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 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.. 

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

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

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

Jean-Noel Gadreau 
Jean-Noel GADREAU 
Software Engineer, ActivCard Inc.( http://www.activcard.com
<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 <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. 


View raw message