xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven McDowall" <...@aptest.com>
Subject RE: Soap Provider classes need access to servlet data
Date Tue, 08 Aug 2000 19:53:17 GMT
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..


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

  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

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


View raw message