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: 1st pass: http provider gets context
Date Mon, 14 Aug 2000 20:18:18 GMT
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Monday, August 14, 2000 10:47 AM
To: soap-dev@xml.apache.org
Subject: Re: 1st pass: http provider gets context


Jean-Noel Gadreau wrote: 


The only problem I see (from my quick glance) with your implementation is
when you have a scope other than 'request'. What I don't like is that if 2
clients perform a call on the same object, you will need to be very careful
in the way you handle the 'setSoapContext', because otherwise, I would see
the following happening: 

I see the problem for 'application' scope, yes. But isn't it true that
client 1 and client 2 each have a 
separtae HttpSession? If that is the case, then shouldn't it work for
'session' scope as well? There's 
only one instance of a provider per session in this case. 
[Jean-Noel Gadreau] If you are using different sessions, you are probably
ok, but it could happen that 2 clients call for the same session (2 pages
opened in parallel for instance).  

For 'application' scope, yes, the onus is on the provider class to manage
[Jean-Noel Gadreau] I would rather have the SOAP Engine perform the
synchronization. It is propably possible to make sure that the
"setSoapContext()" and "invoke" are done in a synchronized block so that the
correct behavior happens. (I have not checked if it is already the case or


instead of 


My first thought would probably be to favor an approach where you pass the
context as a parameter (say the first parameter) of the method.

I wanted to avoid this to preserve loose coupling between the router and the
provider. However, I'm guessing 
there are many cases where the provider classes must be created specifically
for their soap duty anyway. and 
in such a case, maybe the importance of  loose coupling is diminished.   


I think many people will need to have access to some information from the
context (be it HTTP context or other). I think that it should be possible to
use Apache-SOAP in 2 ways : completely "non-intrusive", where you just take
an existing class and plug it in, and the "Apache-SOAP-aware" way, where you
know you will be running through the SOAP engine, but you want to use more

That makes sense. From a web application point of view, it sort of boils
down to what your url endpoint 
is, ie.,   /soap/servlet/RPCServletWithContext, or,
Avoiding a monolithic implementation where you pay for everything 
whether you use it or not is a good thing. Under this philosophy, would the
BSF stuff be refactored into specialized 
[Jean-Noel Gadreau] I would not have several endpoints for this, because it
would mean that the client depends on the implementation on the server. What
you can have is a EnvelopeProcessor which job will be to send to the
RPCCallProcessor or ExtendedRPCCallProcessor based on the actual object. I
think this can be handled quite transparently (even as it is right not). 


As for putting your change in what I am doing, I am not sure I will have
time for it right now but it should not be hard to put it in a special
"EnvelopeProcessor". I will try to get another version out soon.

No problem, especially since you're not comfortable with the changes. If we
(all of us) can decide on an 
approach for this 'specialized RPCCallWithContext' behavior, I will gladly
do the work. 
[Jean-Noel Gadreau] Once I get the overall architecture of the SOAPEngine /
EnvelopeProcessor nailed down, I will look at how to split things from the
ServiceManager / Object life-cycle standpoint, to isolate the HTTP stuff
from the rest. I think that we be a good time to see how to put your change


thanks for taking time. 
[Jean-Noel Gadreau] No problem :-)


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

View raw message