xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Johns <rjo...@vignette.com>
Subject Re: 1st pass: http provider gets context
Date Mon, 14 Aug 2000 17:46:51 GMT


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.

For 'application' scope, yes, the onus is on the provider class to manage synchronization.

>
> setSoapContext(context1);
> setSoapContext(context2);
> callFunction1();
> callFunction2();
>
> instead of
>
> setSoapContext(context1);
> callFunction1();
> setSoapContext(context2);
> callFunction2();
>
> 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
> information.

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, /soap/servlet/RPCServlet.
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
classes?

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

>

thanks for taking time.


Mime
View raw message