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:59:36 GMT

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


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

  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

    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