Return-Path: Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list soap-dev@xml.apache.org Received: (qmail 58274 invoked from network); 8 Aug 2000 19:25:43 -0000 Received: from mail.activcard.com (HELO hub1.hub.activcard.com) (207.93.240.18) by locus.apache.org with SMTP; 8 Aug 2000 19:25:43 -0000 Received: from usexchg1.activcard.com (USEXCHG1 [192.168.133.9]) by hub1.hub.activcard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N60FYGSD; Tue, 8 Aug 2000 12:25:57 -0700 Received: by USEXCHG1 with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Aug 2000 12:20:40 -0700 Message-ID: From: Jean-Noel Gadreau To: "'soap-user@xml.apache.org'" , "'soap-dev@xml.apache.org'" Subject: RE: Soap Provider classes need access to servlet data Date: Tue, 8 Aug 2000 12:20:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0016D.BCE7E130" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0016D.BCE7E130 Content-Type: text/plain; charset="windows-1252" 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 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 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 ------_=_NextPart_001_01C0016D.BCE7E130 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable 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 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 rpcrouter.jsp.

Jean-Noel Gadreau
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

------_=_NextPart_001_01C0016D.BCE7E130--