You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Wouter Cloetens <wc...@raleigh.ibm.com> on 2000/08/07 15:49:33 UTC
Re: Soap Provider classes need access to servlet data
On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
>It would be nice if a provider could have, say the HTTPSession,
>so that it could cache session related data in it and let the servlet
>engine manage the session.
By HTTPSession you mean an HttpSession, identified by a session id in a cookie?
SOAP clients could then read the new session cookie returned by the initial request and
set that on subsequent requests.
It wouldn't be a bad idea to set a cookie for the scope of the SOAP rpcrouter URL for
security and session persistence reasons. E.g. if the client is a browser applet, other
URIs invoked on the same server will share the same session, opening the hole for
those services to invoke SOAP services using your context etc. (It may very well do this
with Page and Application scope - I don't have a webserver supporting JSP1.0 to test,
and I can't be bothered to go read the specs).
>What if there was an interface, ie., iSoapService, that all provider classes implemented.
>The interface would allow the rpcrouter to set some
>useful servlet related data, ie., the session, on the provider before
>invoking the method call.
>public interface iSoapService
>{
> public void setSession( Session s );
> // maybe others... ??
>}
The drawback of that approach is that you're forcing the target provider class to
implement your provider interface, making deployment of SOAP services less seamless
than it is today.
>The only other approach I've found to accomplish this is to insert MyServlet
>in front of rpcrouter. MyServlet uses the currentThread as a key
>and stores the session so that downstream my provider class can get the
>session. MyServlet then calls RequestDispatcher method include() on rpcrouter
>to let the soap call
>complete. Then, when rpcrouter returns from the include(), MyServlet
>removes the session from the cache.
That current thread kludge sounds familiar (I implemented multipart mime that way). :-)
Once again, the drawback is that the service provider class has to be familiar with the
session context concept.
This is similar to session beans in the EJB world. A session bean is created initially by
the client. Its instance variables are stored. On future calls to the same session bean, the
bean (~ session context you're describing) is retrieved or recreated. The methods
invoked on it can then access their session data, stored as instance variables. The
lifecycle is managed by the client. The session bean lives (even across server restarts,
the instance data is serialised to a persistent datastore) until the client destroys it. The
client has to maintain the remote object reference (~ session id in cookie to identify
HttpSession).
The difference is that a session bean is a single class (well, that's what it boils down to).
Your approach stores the session data separately in some session context object,
accessible to various provider classes. One danger is that they may be unrelated and
interfere with eachother if the session context is simple, e.g. key string/value object pairs
in the HttpSession, where the keys are not necessarily unique across independently
developed providers. The client should also be able to specify the session to handle
multiple simultaneous sessions.
Now, this is how I understand the current lifecycle management. A session can only be
maintained for a single provider class. The deployment descriptor indicates a session
scope. When first called, the servlet/JSP creates a new HttpSession, instantiates an
object of the provider class and stores the object in the HttpSession with the service's ID
(urn) as a key. The target method is invoked, the response is returned along with a
session cookie in the header. If the client calls again with the session cookie set, the
same object, with the same instance variables, is pulled from the HttpSession and a
method invoked on it. The provider object's life ends when the session times out (maybe
the timeout value can be set by the client in some way).
If you need multiple services to share a single session context, then make the one
provider class a facade for them, implementing all the method calls. It could call the
target classes with a reference to "this" so they can get to the instance variables
corresponding to the session context, or it could keep a reference to all objects of other
classes used, or simply pass variables and store return values etc.
Somebody correct me if I'm full of it?
bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
I agree, a standard feature is by far the best answer.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 2:48 PM
Subject: Re: Soap Provider classes need access to servlet data
>
>
> Cory Isaacson wrote:
>
> > Rich,
> >
> > It would have to be with the servlet version, which I didn't realize was
not
> > yet available. And yes, it makes sense as a standard feature.
> >
> > However, if you built a subclass wrapper, you shouldn't have to change
> > anything with a new SOAP version, as the super class would automatically
> > change on installation, so it might be a good temporary fix.
>
> Well maybe. I say this because I doubt the rpcrouter is written to be very
> extendable. IOW, I would only want to extend the fact that the provider
should
> be passed the session. I would probably have to overwrite the whole post
method.
>
> Besides, as you said above, it belongs a s a standard feature. Really what
needs
> to happen is that the deployment scope specifier needs to be fully
implemented.
> Right now, no matter what you specifiy, the scoping is application --
which really
> means that the provider instance is instantiated once and stored in the
> ServletContext. So, every provider instance is essentially an extension of
the
> servlet, but *without* access to servlet data, ie., session, etc.
>
> >
> >
> > The only other idea I had was to make a 'login/logout' SOAP call from
your
> > client apps, storing some sort of session like key, but that would add
more
> > overhead if you don't need user validation. That's probably what you're
> > doing with the thread ID.
> >
> > Cory
> > ----- Original Message -----
> > From: "Rich Johns" <rj...@vignette.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, August 08, 2000 1:09 PM
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> > > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but
first of
> > > all, I'm still waiting for the servlet implementation of rpcrouter.
> > Secondly,
> > > I don't want to have to make mods to my derivation on every release of
> > > the soap layer.
> > >
> > > Moreover, I'd prefer it be standard behavior in the soap layer. I like
the
> > idea
> > > of a standard layer. Although, I've been tempted serveral times to
> > implement
> > > my own app specific soap layer, such that it would be optimized for
> > exactly
> > > what I need, but the benefits of a standard layer are compelling.
> > >
> > > Cory Isaacson wrote:
> > >
> > > > Just out of curiosity, couldn't you just subclass the SOAP servlet
and
> > > > client classes and do this as a simple wrapper? I would think it
would
> > be
> > > > very easy, but I'm not sure about the instance problem you
mentioned. It
> > > > seems like the session object could just be retrieved for each SOAP
call
> > and
> > > > made available to the provider without getting in the way of
anything
> > else.
> > > > I did something similar in another application I made and it worked
> > fine.
> > > >
> > > > Cory
> > > > ----- Original Message -----
> > > > From: "Rich Johns" <rj...@vignette.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > > Subject: Re: Soap Provider classes need access to servlet data
> > > >
> > > > >
> > > > >
> > > > > Wouter Cloetens wrote:
> > > > >
> > > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > > >
> > > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > > >so that it could cache session related data in it and let the
> > servlet
> > > > > > >engine manage the session.
> > > > > >
> > > > > > By HTTPSession you mean an HttpSession, identified by a session
id
> > in a
> > > > cookie?
> > > > > > SOAP clients could then read the new session cookie returned by
the
> > > > initial request and
> > > > > > set that on subsequent requests.
> > > > >
> > > > > yes, I do mean HttpSession. A soap client would have to support
> > cookies or
> > > > url
> > > > > rewriting to take advantage of the session id. But most of this is
> > > > automatic from the
> > > > > perspective of the servlet, which can do a getSession(). If the
client
> > has
> > > > managed the
> > > > > sessionId properly, the servlet engine will pull it from the
request,
> > look
> > > > up the session
> > > > > context and make it avaliable to the servlet. I may not have the
exact
> > > > details, but the main idea
> > > > > is that a servlet can usually get a session context, into which
it
> > can
> > > > store and retrieve
> > > > > data relevant to a given sessionId or client.
> > > > >
> > > > > So, the rpcrouter is a servlet (essentially), and it has access to
the
> > > > session, servlet context,
> > > > > request, response, etc. It's main job is to decode the soap call,
map
> > it
> > > > to a provider
> > > > > object, and invoke the appropriate method (with parms) on the
provider
> > > > object.
> > > > >
> > > > > The provider object is not a servlet, or at least it doesn't act
like
> > one.
> > > > Even though
> > > > > it executes in the same thread as the rpcrouter servlet, it does
not
> > have
> > > > access to the
> > > > > servlet data, mentioned above.
> > > > >
> > > > > My question is why couldn't the provider object be handed the
> > servlet's
> > > > session
> > > > > because it too might need to manage things relative to a
particular
> > > > sessionId.
> > > > >
> > > > > > [snip]
> > > > > >
> > > > > > >What if there was an interface, ie., iSoapService, that all
> > provider
> > > > classes implemented.
> > > > > > >The interface would allow the rpcrouter to set some
> > > > > > >useful servlet related data, ie., the session, on the provider
> > before
> > > > > > >invoking the method call.
> > > > > >
> > > > > > >public interface iSoapService
> > > > > > >{
> > > > > > > public void setSession( Session s );
> > > > > > > // maybe others... ??
> > > > > > >}
> > > > > >
> > > > > > The drawback of that approach is that you're forcing the target
> > provider
> > > > class to
> > > > > > implement your provider interface, making deployment of SOAP
> > services
> > > > less seamless
> > > > > > than it is today.
> > > > >
> > > > > I'll buy that. So we could have the rpcrouter relfect the provider
> > class
> > > > and if the
> > > > > iSoapService interface is present, the setSession(...) method will
be
> > > > called on it
> > > > > sometime prior to the invoke. I might be thinking about this the
wrong
> > way
> > > > but
> > > > > it seems to me that there is a better than equal chance that the
> > provider
> > > > class is
> > > > > a new piece of code, probably functioning as a proxy that delgates
to
> > the
> > > > real
> > > > > app service, ie., a remote ejb, or whatever. In such a case,
having to
> > > > implement
> > > > > an interface is not a bother.
> > > > >
> > > > > >
> > > > > >
> > > > > > >The only other approach I've found to accomplish this is to
insert
> > > > MyServlet
> > > > > > >in front of rpcrouter. MyServlet uses the currentThread as a
key
> > > > > > >and stores the session so that downstream my provider class can
get
> > the
> > > > > > >session. MyServlet then calls RequestDispatcher method
include() on
> > > > rpcrouter
> > > > > > >to let the soap call
> > > > > > >complete. Then, when rpcrouter returns from the include(),
> > MyServlet
> > > > > > >removes the session from the cache.
> > > > > >
> > > > > > That current thread kludge sounds familiar (I implemented
multipart
> > mime
> > > > that way). :-)
> > > > > > Once again, the drawback is that the service provider class has
to
> > be
> > > > familiar with the
> > > > > > session context concept.
> > > > >
> > > > > Yep, if it needs the session, it would be willing to pay for it.
> > > > >
> > > > > >
> > > > > > [snip]
> > > > >
> > > > > >
> > > > > > One danger is that they may be unrelated and
> > > > > > interfere with eachother if the session context is simple, e.g.
key
> > > > string/value object pairs
> > > > > > in the HttpSession, where the keys are not necessarily unique
across
> > > > independently
> > > > > > developed providers. The client should also be able to specify
the
> > > > session to handle
> > > > > > multiple simultaneous sessions.
> > > > >
> > > > > I'm not sure I'm following here. I'm naivley thinking that I can
use
> > the
> > > > current thread to
> > > > > derive some sort of unique key to store the session object. The
> > provider
> > > > objecet, which
> > > > > is essentially an extension of the executing servlet group, is
> > exectuing
> > > > in the same
> > > > > thread, thus it will use the same key to fetch the session object
> > that
> > > > was used to
> > > > > store it and given that, there should be no conflict with session
> > content.
> > > > So it looks like this:
> > > > >
> > > > > store/remove +--------------+ get session
> > > > > +--------------> | session cache |<-------------+
> > > > > | +--------------+
> > > > |
> > > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > > <----------------------------------------------------+
> > > > >
> > > > > >
> > > > > >
> > > > > > Now, this is how I understand the current lifecycle management.
A
> > > > session can only be
> > > > > > maintained for a single provider class. The deployment
descriptor
> > > > indicates a session
> > > > > > scope. When first called, the servlet/JSP creates a new
HttpSession,
> > > > instantiates an
> > > > > > object of the provider class and stores the object in the
> > HttpSession
> > > > with the service's ID
> > > > > > (urn) as a key. The target method is invoked, the response is
> > returned
> > > > along with a
> > > > > > session cookie in the header. If the client calls again with the
> > session
> > > > cookie set, the
> > > > > > same object, with the same instance variables, is pulled from
the
> > > > HttpSession and a
> > > > > > method invoked on it. The provider object's life ends when the
> > session
> > > > times out (maybe
> > > > > > the timeout value can be set by the client in some way).
> > > > >
> > > > > I was under the impression that there was only one instance of a
> > provider
> > > > and that it
> > > > > should be thread safe. If there is a new instance of the provider
for
> > > > every HttpSession,
> > > > > then the provider itself could be used to store provider-specific
> > session
> > > > data.
> > > > >
> > > > > How does this map to the scope specifier in the deployment
descriptor?
> > If
> > > > 'application'
> > > > > is specified, does the provider class instance get stored in the
> > 'servlet
> > > > context' and if
> > > > > the scope is specified as 'session' is the provider class instance
> > stored
> > > > in the
> > > > > 'servlet session'?
> > > > >
> > > > > Could someone clarify this please?
> > > > >
> > > > > >
> > > > > > If you need multiple services to share a single session context,
> > then
> > > > make the one
> > > > > > provider class a facade for them, implementing all the method
calls.
> > It
> > > > could call the
> > > > > > target classes with a reference to "this" so they can get to the
> > > > instance variables
> > > > > > corresponding to the session context, or it could keep a
reference
> > to
> > > > all objects of other
> > > > > > classes used, or simply pass variables and store return values
etc.
> > > > > >
> > > > > > Somebody correct me if I'm full of it?
> > > > >
> > > > > whether you got all the details right or not, I appreciate the
time
> > you've
> > > > taken to further
> > > > > this discussion.
> > > > >
> > > > > >
> > > > > >
> > > > > > bfn, Wouter
> > > > > > --
> > > > > > http://www.workspot.net/~zombie/soap/
> > > > > > My opinions are irrelevant. They will be assimilated by my
employer.
> > > > >
> > >
>
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
I agree, a standard feature is by far the best answer.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 2:48 PM
Subject: Re: Soap Provider classes need access to servlet data
>
>
> Cory Isaacson wrote:
>
> > Rich,
> >
> > It would have to be with the servlet version, which I didn't realize was
not
> > yet available. And yes, it makes sense as a standard feature.
> >
> > However, if you built a subclass wrapper, you shouldn't have to change
> > anything with a new SOAP version, as the super class would automatically
> > change on installation, so it might be a good temporary fix.
>
> Well maybe. I say this because I doubt the rpcrouter is written to be very
> extendable. IOW, I would only want to extend the fact that the provider
should
> be passed the session. I would probably have to overwrite the whole post
method.
>
> Besides, as you said above, it belongs a s a standard feature. Really what
needs
> to happen is that the deployment scope specifier needs to be fully
implemented.
> Right now, no matter what you specifiy, the scoping is application --
which really
> means that the provider instance is instantiated once and stored in the
> ServletContext. So, every provider instance is essentially an extension of
the
> servlet, but *without* access to servlet data, ie., session, etc.
>
> >
> >
> > The only other idea I had was to make a 'login/logout' SOAP call from
your
> > client apps, storing some sort of session like key, but that would add
more
> > overhead if you don't need user validation. That's probably what you're
> > doing with the thread ID.
> >
> > Cory
> > ----- Original Message -----
> > From: "Rich Johns" <rj...@vignette.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, August 08, 2000 1:09 PM
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> > > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but
first of
> > > all, I'm still waiting for the servlet implementation of rpcrouter.
> > Secondly,
> > > I don't want to have to make mods to my derivation on every release of
> > > the soap layer.
> > >
> > > Moreover, I'd prefer it be standard behavior in the soap layer. I like
the
> > idea
> > > of a standard layer. Although, I've been tempted serveral times to
> > implement
> > > my own app specific soap layer, such that it would be optimized for
> > exactly
> > > what I need, but the benefits of a standard layer are compelling.
> > >
> > > Cory Isaacson wrote:
> > >
> > > > Just out of curiosity, couldn't you just subclass the SOAP servlet
and
> > > > client classes and do this as a simple wrapper? I would think it
would
> > be
> > > > very easy, but I'm not sure about the instance problem you
mentioned. It
> > > > seems like the session object could just be retrieved for each SOAP
call
> > and
> > > > made available to the provider without getting in the way of
anything
> > else.
> > > > I did something similar in another application I made and it worked
> > fine.
> > > >
> > > > Cory
> > > > ----- Original Message -----
> > > > From: "Rich Johns" <rj...@vignette.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > > Subject: Re: Soap Provider classes need access to servlet data
> > > >
> > > > >
> > > > >
> > > > > Wouter Cloetens wrote:
> > > > >
> > > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > > >
> > > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > > >so that it could cache session related data in it and let the
> > servlet
> > > > > > >engine manage the session.
> > > > > >
> > > > > > By HTTPSession you mean an HttpSession, identified by a session
id
> > in a
> > > > cookie?
> > > > > > SOAP clients could then read the new session cookie returned by
the
> > > > initial request and
> > > > > > set that on subsequent requests.
> > > > >
> > > > > yes, I do mean HttpSession. A soap client would have to support
> > cookies or
> > > > url
> > > > > rewriting to take advantage of the session id. But most of this is
> > > > automatic from the
> > > > > perspective of the servlet, which can do a getSession(). If the
client
> > has
> > > > managed the
> > > > > sessionId properly, the servlet engine will pull it from the
request,
> > look
> > > > up the session
> > > > > context and make it avaliable to the servlet. I may not have the
exact
> > > > details, but the main idea
> > > > > is that a servlet can usually get a session context, into which
it
> > can
> > > > store and retrieve
> > > > > data relevant to a given sessionId or client.
> > > > >
> > > > > So, the rpcrouter is a servlet (essentially), and it has access to
the
> > > > session, servlet context,
> > > > > request, response, etc. It's main job is to decode the soap call,
map
> > it
> > > > to a provider
> > > > > object, and invoke the appropriate method (with parms) on the
provider
> > > > object.
> > > > >
> > > > > The provider object is not a servlet, or at least it doesn't act
like
> > one.
> > > > Even though
> > > > > it executes in the same thread as the rpcrouter servlet, it does
not
> > have
> > > > access to the
> > > > > servlet data, mentioned above.
> > > > >
> > > > > My question is why couldn't the provider object be handed the
> > servlet's
> > > > session
> > > > > because it too might need to manage things relative to a
particular
> > > > sessionId.
> > > > >
> > > > > > [snip]
> > > > > >
> > > > > > >What if there was an interface, ie., iSoapService, that all
> > provider
> > > > classes implemented.
> > > > > > >The interface would allow the rpcrouter to set some
> > > > > > >useful servlet related data, ie., the session, on the provider
> > before
> > > > > > >invoking the method call.
> > > > > >
> > > > > > >public interface iSoapService
> > > > > > >{
> > > > > > > public void setSession( Session s );
> > > > > > > // maybe others... ??
> > > > > > >}
> > > > > >
> > > > > > The drawback of that approach is that you're forcing the target
> > provider
> > > > class to
> > > > > > implement your provider interface, making deployment of SOAP
> > services
> > > > less seamless
> > > > > > than it is today.
> > > > >
> > > > > I'll buy that. So we could have the rpcrouter relfect the provider
> > class
> > > > and if the
> > > > > iSoapService interface is present, the setSession(...) method will
be
> > > > called on it
> > > > > sometime prior to the invoke. I might be thinking about this the
wrong
> > way
> > > > but
> > > > > it seems to me that there is a better than equal chance that the
> > provider
> > > > class is
> > > > > a new piece of code, probably functioning as a proxy that delgates
to
> > the
> > > > real
> > > > > app service, ie., a remote ejb, or whatever. In such a case,
having to
> > > > implement
> > > > > an interface is not a bother.
> > > > >
> > > > > >
> > > > > >
> > > > > > >The only other approach I've found to accomplish this is to
insert
> > > > MyServlet
> > > > > > >in front of rpcrouter. MyServlet uses the currentThread as a
key
> > > > > > >and stores the session so that downstream my provider class can
get
> > the
> > > > > > >session. MyServlet then calls RequestDispatcher method
include() on
> > > > rpcrouter
> > > > > > >to let the soap call
> > > > > > >complete. Then, when rpcrouter returns from the include(),
> > MyServlet
> > > > > > >removes the session from the cache.
> > > > > >
> > > > > > That current thread kludge sounds familiar (I implemented
multipart
> > mime
> > > > that way). :-)
> > > > > > Once again, the drawback is that the service provider class has
to
> > be
> > > > familiar with the
> > > > > > session context concept.
> > > > >
> > > > > Yep, if it needs the session, it would be willing to pay for it.
> > > > >
> > > > > >
> > > > > > [snip]
> > > > >
> > > > > >
> > > > > > One danger is that they may be unrelated and
> > > > > > interfere with eachother if the session context is simple, e.g.
key
> > > > string/value object pairs
> > > > > > in the HttpSession, where the keys are not necessarily unique
across
> > > > independently
> > > > > > developed providers. The client should also be able to specify
the
> > > > session to handle
> > > > > > multiple simultaneous sessions.
> > > > >
> > > > > I'm not sure I'm following here. I'm naivley thinking that I can
use
> > the
> > > > current thread to
> > > > > derive some sort of unique key to store the session object. The
> > provider
> > > > objecet, which
> > > > > is essentially an extension of the executing servlet group, is
> > exectuing
> > > > in the same
> > > > > thread, thus it will use the same key to fetch the session object
> > that
> > > > was used to
> > > > > store it and given that, there should be no conflict with session
> > content.
> > > > So it looks like this:
> > > > >
> > > > > store/remove +--------------+ get session
> > > > > +--------------> | session cache |<-------------+
> > > > > | +--------------+
> > > > |
> > > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > > <----------------------------------------------------+
> > > > >
> > > > > >
> > > > > >
> > > > > > Now, this is how I understand the current lifecycle management.
A
> > > > session can only be
> > > > > > maintained for a single provider class. The deployment
descriptor
> > > > indicates a session
> > > > > > scope. When first called, the servlet/JSP creates a new
HttpSession,
> > > > instantiates an
> > > > > > object of the provider class and stores the object in the
> > HttpSession
> > > > with the service's ID
> > > > > > (urn) as a key. The target method is invoked, the response is
> > returned
> > > > along with a
> > > > > > session cookie in the header. If the client calls again with the
> > session
> > > > cookie set, the
> > > > > > same object, with the same instance variables, is pulled from
the
> > > > HttpSession and a
> > > > > > method invoked on it. The provider object's life ends when the
> > session
> > > > times out (maybe
> > > > > > the timeout value can be set by the client in some way).
> > > > >
> > > > > I was under the impression that there was only one instance of a
> > provider
> > > > and that it
> > > > > should be thread safe. If there is a new instance of the provider
for
> > > > every HttpSession,
> > > > > then the provider itself could be used to store provider-specific
> > session
> > > > data.
> > > > >
> > > > > How does this map to the scope specifier in the deployment
descriptor?
> > If
> > > > 'application'
> > > > > is specified, does the provider class instance get stored in the
> > 'servlet
> > > > context' and if
> > > > > the scope is specified as 'session' is the provider class instance
> > stored
> > > > in the
> > > > > 'servlet session'?
> > > > >
> > > > > Could someone clarify this please?
> > > > >
> > > > > >
> > > > > > If you need multiple services to share a single session context,
> > then
> > > > make the one
> > > > > > provider class a facade for them, implementing all the method
calls.
> > It
> > > > could call the
> > > > > > target classes with a reference to "this" so they can get to the
> > > > instance variables
> > > > > > corresponding to the session context, or it could keep a
reference
> > to
> > > > all objects of other
> > > > > > classes used, or simply pass variables and store return values
etc.
> > > > > >
> > > > > > Somebody correct me if I'm full of it?
> > > > >
> > > > > whether you got all the details right or not, I appreciate the
time
> > you've
> > > > taken to further
> > > > > this discussion.
> > > > >
> > > > > >
> > > > > >
> > > > > > bfn, Wouter
> > > > > > --
> > > > > > http://www.workspot.net/~zombie/soap/
> > > > > > My opinions are irrelevant. They will be assimilated by my
employer.
> > > > >
> > >
>
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
One of the first things I plan to "fix" in the Servlet version of the router
is the appropriate "caching" of object instances per the scope defined in
the
definition description..
However, I am not POSITIVE it is broken now even in the JSP, since it uses
setAttribute and passes either a Page/Session/Context/APplication scope
to the setAttribute method.. However, if it does work it is sort of magic
and I don't like it..
I plan (and had started) to implement a better "instaniation" and caching
mechanism that explictly dealt with these scopes, including a "time-out"
and delete mechanism to remove cached objects that haven't been used "in a
while"..
(Otherwise, memory usage would of course be boundless..not a good thing)..
One of the prerequsistes of that was to get a good description of what the
lifecycle
of each scope meant, and this has been forthcoming and good..
The current debate is on what/whether a "Page" scope makes sense and what it
really means..
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 1:49 PM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
Cory Isaacson wrote:
> Rich,
>
> It would have to be with the servlet version, which I didn't realize was
not
> yet available. And yes, it makes sense as a standard feature.
>
> However, if you built a subclass wrapper, you shouldn't have to change
> anything with a new SOAP version, as the super class would automatically
> change on installation, so it might be a good temporary fix.
Well maybe. I say this because I doubt the rpcrouter is written to be very
extendable. IOW, I would only want to extend the fact that the provider
should
be passed the session. I would probably have to overwrite the whole post
method.
Besides, as you said above, it belongs a s a standard feature. Really what
needs
to happen is that the deployment scope specifier needs to be fully
implemented.
Right now, no matter what you specifiy, the scoping is application -- which
really
means that the provider instance is instantiated once and stored in the
ServletContext. So, every provider instance is essentially an extension of
the
servlet, but *without* access to servlet data, ie., session, etc.
>
>
> The only other idea I had was to make a 'login/logout' SOAP call from your
> client apps, storing some sort of session like key, but that would add
more
> overhead if you don't need user validation. That's probably what you're
> doing with the thread ID.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 1:09 PM
> Subject: Re: Soap Provider classes need access to servlet data
>
> > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first
of
> > all, I'm still waiting for the servlet implementation of rpcrouter.
> Secondly,
> > I don't want to have to make mods to my derivation on every release of
> > the soap layer.
> >
> > Moreover, I'd prefer it be standard behavior in the soap layer. I like
the
> idea
> > of a standard layer. Although, I've been tempted serveral times to
> implement
> > my own app specific soap layer, such that it would be optimized for
> exactly
> > what I need, but the benefits of a standard layer are compelling.
> >
> > Cory Isaacson wrote:
> >
> > > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > > client classes and do this as a simple wrapper? I would think it would
> be
> > > very easy, but I'm not sure about the instance problem you mentioned.
It
> > > seems like the session object could just be retrieved for each SOAP
call
> and
> > > made available to the provider without getting in the way of anything
> else.
> > > I did something similar in another application I made and it worked
> fine.
> > >
> > > Cory
> > > ----- Original Message -----
> > > From: "Rich Johns" <rj...@vignette.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > Subject: Re: Soap Provider classes need access to servlet data
> > >
> > > >
> > > >
> > > > Wouter Cloetens wrote:
> > > >
> > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > >
> > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > >so that it could cache session related data in it and let the
> servlet
> > > > > >engine manage the session.
> > > > >
> > > > > By HTTPSession you mean an HttpSession, identified by a session id
> in a
> > > cookie?
> > > > > SOAP clients could then read the new session cookie returned by
the
> > > initial request and
> > > > > set that on subsequent requests.
> > > >
> > > > yes, I do mean HttpSession. A soap client would have to support
> cookies or
> > > url
> > > > rewriting to take advantage of the session id. But most of this is
> > > automatic from the
> > > > perspective of the servlet, which can do a getSession(). If the
client
> has
> > > managed the
> > > > sessionId properly, the servlet engine will pull it from the
request,
> look
> > > up the session
> > > > context and make it avaliable to the servlet. I may not have the
exact
> > > details, but the main idea
> > > > is that a servlet can usually get a session context, into which it
> can
> > > store and retrieve
> > > > data relevant to a given sessionId or client.
> > > >
> > > > So, the rpcrouter is a servlet (essentially), and it has access to
the
> > > session, servlet context,
> > > > request, response, etc. It's main job is to decode the soap call,
map
> it
> > > to a provider
> > > > object, and invoke the appropriate method (with parms) on the
provider
> > > object.
> > > >
> > > > The provider object is not a servlet, or at least it doesn't act
like
> one.
> > > Even though
> > > > it executes in the same thread as the rpcrouter servlet, it does not
> have
> > > access to the
> > > > servlet data, mentioned above.
> > > >
> > > > My question is why couldn't the provider object be handed the
> servlet's
> > > session
> > > > because it too might need to manage things relative to a particular
> > > sessionId.
> > > >
> > > > > [snip]
> > > > >
> > > > > >What if there was an interface, ie., iSoapService, that all
> provider
> > > classes implemented.
> > > > > >The interface would allow the rpcrouter to set some
> > > > > >useful servlet related data, ie., the session, on the provider
> before
> > > > > >invoking the method call.
> > > > >
> > > > > >public interface iSoapService
> > > > > >{
> > > > > > public void setSession( Session s );
> > > > > > // maybe others... ??
> > > > > >}
> > > > >
> > > > > The drawback of that approach is that you're forcing the target
> provider
> > > class to
> > > > > implement your provider interface, making deployment of SOAP
> services
> > > less seamless
> > > > > than it is today.
> > > >
> > > > I'll buy that. So we could have the rpcrouter relfect the provider
> class
> > > and if the
> > > > iSoapService interface is present, the setSession(...) method will
be
> > > called on it
> > > > sometime prior to the invoke. I might be thinking about this the
wrong
> way
> > > but
> > > > it seems to me that there is a better than equal chance that the
> provider
> > > class is
> > > > a new piece of code, probably functioning as a proxy that delgates
to
> the
> > > real
> > > > app service, ie., a remote ejb, or whatever. In such a case, having
to
> > > implement
> > > > an interface is not a bother.
> > > >
> > > > >
> > > > >
> > > > > >The only other approach I've found to accomplish this is to
insert
> > > MyServlet
> > > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > > >and stores the session so that downstream my provider class can
get
> the
> > > > > >session. MyServlet then calls RequestDispatcher method include()
on
> > > rpcrouter
> > > > > >to let the soap call
> > > > > >complete. Then, when rpcrouter returns from the include(),
> MyServlet
> > > > > >removes the session from the cache.
> > > > >
> > > > > That current thread kludge sounds familiar (I implemented
multipart
> mime
> > > that way). :-)
> > > > > Once again, the drawback is that the service provider class has to
> be
> > > familiar with the
> > > > > session context concept.
> > > >
> > > > Yep, if it needs the session, it would be willing to pay for it.
> > > >
> > > > >
> > > > > [snip]
> > > >
> > > > >
> > > > > One danger is that they may be unrelated and
> > > > > interfere with eachother if the session context is simple, e.g.
key
> > > string/value object pairs
> > > > > in the HttpSession, where the keys are not necessarily unique
across
> > > independently
> > > > > developed providers. The client should also be able to specify the
> > > session to handle
> > > > > multiple simultaneous sessions.
> > > >
> > > > I'm not sure I'm following here. I'm naivley thinking that I can use
> the
> > > current thread to
> > > > derive some sort of unique key to store the session object. The
> provider
> > > objecet, which
> > > > is essentially an extension of the executing servlet group, is
> exectuing
> > > in the same
> > > > thread, thus it will use the same key to fetch the session object
> that
> > > was used to
> > > > store it and given that, there should be no conflict with session
> content.
> > > So it looks like this:
> > > >
> > > > store/remove +--------------+ get session
> > > > +--------------> | session cache |<-------------+
> > > > | +--------------+
> > > |
> > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > <----------------------------------------------------+
> > > >
> > > > >
> > > > >
> > > > > Now, this is how I understand the current lifecycle management. A
> > > session can only be
> > > > > maintained for a single provider class. The deployment descriptor
> > > indicates a session
> > > > > scope. When first called, the servlet/JSP creates a new
HttpSession,
> > > instantiates an
> > > > > object of the provider class and stores the object in the
> HttpSession
> > > with the service's ID
> > > > > (urn) as a key. The target method is invoked, the response is
> returned
> > > along with a
> > > > > session cookie in the header. If the client calls again with the
> session
> > > cookie set, the
> > > > > same object, with the same instance variables, is pulled from the
> > > HttpSession and a
> > > > > method invoked on it. The provider object's life ends when the
> session
> > > times out (maybe
> > > > > the timeout value can be set by the client in some way).
> > > >
> > > > I was under the impression that there was only one instance of a
> provider
> > > and that it
> > > > should be thread safe. If there is a new instance of the provider
for
> > > every HttpSession,
> > > > then the provider itself could be used to store provider-specific
> session
> > > data.
> > > >
> > > > How does this map to the scope specifier in the deployment
descriptor?
> If
> > > 'application'
> > > > is specified, does the provider class instance get stored in the
> 'servlet
> > > context' and if
> > > > the scope is specified as 'session' is the provider class instance
> stored
> > > in the
> > > > 'servlet session'?
> > > >
> > > > Could someone clarify this please?
> > > >
> > > > >
> > > > > If you need multiple services to share a single session context,
> then
> > > make the one
> > > > > provider class a facade for them, implementing all the method
calls.
> It
> > > could call the
> > > > > target classes with a reference to "this" so they can get to the
> > > instance variables
> > > > > corresponding to the session context, or it could keep a reference
> to
> > > all objects of other
> > > > > classes used, or simply pass variables and store return values
etc.
> > > > >
> > > > > Somebody correct me if I'm full of it?
> > > >
> > > > whether you got all the details right or not, I appreciate the time
> you've
> > > taken to further
> > > > this discussion.
> > > >
> > > > >
> > > > >
> > > > > bfn, Wouter
> > > > > --
> > > > > http://www.workspot.net/~zombie/soap/
> > > > > My opinions are irrelevant. They will be assimilated by my
employer.
> > > >
> >
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
One of the first things I plan to "fix" in the Servlet version of the router
is the appropriate "caching" of object instances per the scope defined in
the
definition description..
However, I am not POSITIVE it is broken now even in the JSP, since it uses
setAttribute and passes either a Page/Session/Context/APplication scope
to the setAttribute method.. However, if it does work it is sort of magic
and I don't like it..
I plan (and had started) to implement a better "instaniation" and caching
mechanism that explictly dealt with these scopes, including a "time-out"
and delete mechanism to remove cached objects that haven't been used "in a
while"..
(Otherwise, memory usage would of course be boundless..not a good thing)..
One of the prerequsistes of that was to get a good description of what the
lifecycle
of each scope meant, and this has been forthcoming and good..
The current debate is on what/whether a "Page" scope makes sense and what it
really means..
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 1:49 PM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
Cory Isaacson wrote:
> Rich,
>
> It would have to be with the servlet version, which I didn't realize was
not
> yet available. And yes, it makes sense as a standard feature.
>
> However, if you built a subclass wrapper, you shouldn't have to change
> anything with a new SOAP version, as the super class would automatically
> change on installation, so it might be a good temporary fix.
Well maybe. I say this because I doubt the rpcrouter is written to be very
extendable. IOW, I would only want to extend the fact that the provider
should
be passed the session. I would probably have to overwrite the whole post
method.
Besides, as you said above, it belongs a s a standard feature. Really what
needs
to happen is that the deployment scope specifier needs to be fully
implemented.
Right now, no matter what you specifiy, the scoping is application -- which
really
means that the provider instance is instantiated once and stored in the
ServletContext. So, every provider instance is essentially an extension of
the
servlet, but *without* access to servlet data, ie., session, etc.
>
>
> The only other idea I had was to make a 'login/logout' SOAP call from your
> client apps, storing some sort of session like key, but that would add
more
> overhead if you don't need user validation. That's probably what you're
> doing with the thread ID.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 1:09 PM
> Subject: Re: Soap Provider classes need access to servlet data
>
> > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first
of
> > all, I'm still waiting for the servlet implementation of rpcrouter.
> Secondly,
> > I don't want to have to make mods to my derivation on every release of
> > the soap layer.
> >
> > Moreover, I'd prefer it be standard behavior in the soap layer. I like
the
> idea
> > of a standard layer. Although, I've been tempted serveral times to
> implement
> > my own app specific soap layer, such that it would be optimized for
> exactly
> > what I need, but the benefits of a standard layer are compelling.
> >
> > Cory Isaacson wrote:
> >
> > > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > > client classes and do this as a simple wrapper? I would think it would
> be
> > > very easy, but I'm not sure about the instance problem you mentioned.
It
> > > seems like the session object could just be retrieved for each SOAP
call
> and
> > > made available to the provider without getting in the way of anything
> else.
> > > I did something similar in another application I made and it worked
> fine.
> > >
> > > Cory
> > > ----- Original Message -----
> > > From: "Rich Johns" <rj...@vignette.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > Subject: Re: Soap Provider classes need access to servlet data
> > >
> > > >
> > > >
> > > > Wouter Cloetens wrote:
> > > >
> > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > >
> > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > >so that it could cache session related data in it and let the
> servlet
> > > > > >engine manage the session.
> > > > >
> > > > > By HTTPSession you mean an HttpSession, identified by a session id
> in a
> > > cookie?
> > > > > SOAP clients could then read the new session cookie returned by
the
> > > initial request and
> > > > > set that on subsequent requests.
> > > >
> > > > yes, I do mean HttpSession. A soap client would have to support
> cookies or
> > > url
> > > > rewriting to take advantage of the session id. But most of this is
> > > automatic from the
> > > > perspective of the servlet, which can do a getSession(). If the
client
> has
> > > managed the
> > > > sessionId properly, the servlet engine will pull it from the
request,
> look
> > > up the session
> > > > context and make it avaliable to the servlet. I may not have the
exact
> > > details, but the main idea
> > > > is that a servlet can usually get a session context, into which it
> can
> > > store and retrieve
> > > > data relevant to a given sessionId or client.
> > > >
> > > > So, the rpcrouter is a servlet (essentially), and it has access to
the
> > > session, servlet context,
> > > > request, response, etc. It's main job is to decode the soap call,
map
> it
> > > to a provider
> > > > object, and invoke the appropriate method (with parms) on the
provider
> > > object.
> > > >
> > > > The provider object is not a servlet, or at least it doesn't act
like
> one.
> > > Even though
> > > > it executes in the same thread as the rpcrouter servlet, it does not
> have
> > > access to the
> > > > servlet data, mentioned above.
> > > >
> > > > My question is why couldn't the provider object be handed the
> servlet's
> > > session
> > > > because it too might need to manage things relative to a particular
> > > sessionId.
> > > >
> > > > > [snip]
> > > > >
> > > > > >What if there was an interface, ie., iSoapService, that all
> provider
> > > classes implemented.
> > > > > >The interface would allow the rpcrouter to set some
> > > > > >useful servlet related data, ie., the session, on the provider
> before
> > > > > >invoking the method call.
> > > > >
> > > > > >public interface iSoapService
> > > > > >{
> > > > > > public void setSession( Session s );
> > > > > > // maybe others... ??
> > > > > >}
> > > > >
> > > > > The drawback of that approach is that you're forcing the target
> provider
> > > class to
> > > > > implement your provider interface, making deployment of SOAP
> services
> > > less seamless
> > > > > than it is today.
> > > >
> > > > I'll buy that. So we could have the rpcrouter relfect the provider
> class
> > > and if the
> > > > iSoapService interface is present, the setSession(...) method will
be
> > > called on it
> > > > sometime prior to the invoke. I might be thinking about this the
wrong
> way
> > > but
> > > > it seems to me that there is a better than equal chance that the
> provider
> > > class is
> > > > a new piece of code, probably functioning as a proxy that delgates
to
> the
> > > real
> > > > app service, ie., a remote ejb, or whatever. In such a case, having
to
> > > implement
> > > > an interface is not a bother.
> > > >
> > > > >
> > > > >
> > > > > >The only other approach I've found to accomplish this is to
insert
> > > MyServlet
> > > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > > >and stores the session so that downstream my provider class can
get
> the
> > > > > >session. MyServlet then calls RequestDispatcher method include()
on
> > > rpcrouter
> > > > > >to let the soap call
> > > > > >complete. Then, when rpcrouter returns from the include(),
> MyServlet
> > > > > >removes the session from the cache.
> > > > >
> > > > > That current thread kludge sounds familiar (I implemented
multipart
> mime
> > > that way). :-)
> > > > > Once again, the drawback is that the service provider class has to
> be
> > > familiar with the
> > > > > session context concept.
> > > >
> > > > Yep, if it needs the session, it would be willing to pay for it.
> > > >
> > > > >
> > > > > [snip]
> > > >
> > > > >
> > > > > One danger is that they may be unrelated and
> > > > > interfere with eachother if the session context is simple, e.g.
key
> > > string/value object pairs
> > > > > in the HttpSession, where the keys are not necessarily unique
across
> > > independently
> > > > > developed providers. The client should also be able to specify the
> > > session to handle
> > > > > multiple simultaneous sessions.
> > > >
> > > > I'm not sure I'm following here. I'm naivley thinking that I can use
> the
> > > current thread to
> > > > derive some sort of unique key to store the session object. The
> provider
> > > objecet, which
> > > > is essentially an extension of the executing servlet group, is
> exectuing
> > > in the same
> > > > thread, thus it will use the same key to fetch the session object
> that
> > > was used to
> > > > store it and given that, there should be no conflict with session
> content.
> > > So it looks like this:
> > > >
> > > > store/remove +--------------+ get session
> > > > +--------------> | session cache |<-------------+
> > > > | +--------------+
> > > |
> > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > <----------------------------------------------------+
> > > >
> > > > >
> > > > >
> > > > > Now, this is how I understand the current lifecycle management. A
> > > session can only be
> > > > > maintained for a single provider class. The deployment descriptor
> > > indicates a session
> > > > > scope. When first called, the servlet/JSP creates a new
HttpSession,
> > > instantiates an
> > > > > object of the provider class and stores the object in the
> HttpSession
> > > with the service's ID
> > > > > (urn) as a key. The target method is invoked, the response is
> returned
> > > along with a
> > > > > session cookie in the header. If the client calls again with the
> session
> > > cookie set, the
> > > > > same object, with the same instance variables, is pulled from the
> > > HttpSession and a
> > > > > method invoked on it. The provider object's life ends when the
> session
> > > times out (maybe
> > > > > the timeout value can be set by the client in some way).
> > > >
> > > > I was under the impression that there was only one instance of a
> provider
> > > and that it
> > > > should be thread safe. If there is a new instance of the provider
for
> > > every HttpSession,
> > > > then the provider itself could be used to store provider-specific
> session
> > > data.
> > > >
> > > > How does this map to the scope specifier in the deployment
descriptor?
> If
> > > 'application'
> > > > is specified, does the provider class instance get stored in the
> 'servlet
> > > context' and if
> > > > the scope is specified as 'session' is the provider class instance
> stored
> > > in the
> > > > 'servlet session'?
> > > >
> > > > Could someone clarify this please?
> > > >
> > > > >
> > > > > If you need multiple services to share a single session context,
> then
> > > make the one
> > > > > provider class a facade for them, implementing all the method
calls.
> It
> > > could call the
> > > > > target classes with a reference to "this" so they can get to the
> > > instance variables
> > > > > corresponding to the session context, or it could keep a reference
> to
> > > all objects of other
> > > > > classes used, or simply pass variables and store return values
etc.
> > > > >
> > > > > Somebody correct me if I'm full of it?
> > > >
> > > > whether you got all the details right or not, I appreciate the time
> you've
> > > taken to further
> > > > this discussion.
> > > >
> > > > >
> > > > >
> > > > > bfn, Wouter
> > > > > --
> > > > > http://www.workspot.net/~zombie/soap/
> > > > > My opinions are irrelevant. They will be assimilated by my
employer.
> > > >
> >
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Cory Isaacson wrote:
> Rich,
>
> It would have to be with the servlet version, which I didn't realize was not
> yet available. And yes, it makes sense as a standard feature.
>
> However, if you built a subclass wrapper, you shouldn't have to change
> anything with a new SOAP version, as the super class would automatically
> change on installation, so it might be a good temporary fix.
Well maybe. I say this because I doubt the rpcrouter is written to be very
extendable. IOW, I would only want to extend the fact that the provider should
be passed the session. I would probably have to overwrite the whole post method.
Besides, as you said above, it belongs a s a standard feature. Really what needs
to happen is that the deployment scope specifier needs to be fully implemented.
Right now, no matter what you specifiy, the scoping is application -- which really
means that the provider instance is instantiated once and stored in the
ServletContext. So, every provider instance is essentially an extension of the
servlet, but *without* access to servlet data, ie., session, etc.
>
>
> The only other idea I had was to make a 'login/logout' SOAP call from your
> client apps, storing some sort of session like key, but that would add more
> overhead if you don't need user validation. That's probably what you're
> doing with the thread ID.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 1:09 PM
> Subject: Re: Soap Provider classes need access to servlet data
>
> > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
> > all, I'm still waiting for the servlet implementation of rpcrouter.
> Secondly,
> > I don't want to have to make mods to my derivation on every release of
> > the soap layer.
> >
> > Moreover, I'd prefer it be standard behavior in the soap layer. I like the
> idea
> > of a standard layer. Although, I've been tempted serveral times to
> implement
> > my own app specific soap layer, such that it would be optimized for
> exactly
> > what I need, but the benefits of a standard layer are compelling.
> >
> > Cory Isaacson wrote:
> >
> > > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > > client classes and do this as a simple wrapper? I would think it would
> be
> > > very easy, but I'm not sure about the instance problem you mentioned. It
> > > seems like the session object could just be retrieved for each SOAP call
> and
> > > made available to the provider without getting in the way of anything
> else.
> > > I did something similar in another application I made and it worked
> fine.
> > >
> > > Cory
> > > ----- Original Message -----
> > > From: "Rich Johns" <rj...@vignette.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > Subject: Re: Soap Provider classes need access to servlet data
> > >
> > > >
> > > >
> > > > Wouter Cloetens wrote:
> > > >
> > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > >
> > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > >so that it could cache session related data in it and let the
> servlet
> > > > > >engine manage the session.
> > > > >
> > > > > By HTTPSession you mean an HttpSession, identified by a session id
> in a
> > > cookie?
> > > > > SOAP clients could then read the new session cookie returned by the
> > > initial request and
> > > > > set that on subsequent requests.
> > > >
> > > > yes, I do mean HttpSession. A soap client would have to support
> cookies or
> > > url
> > > > rewriting to take advantage of the session id. But most of this is
> > > automatic from the
> > > > perspective of the servlet, which can do a getSession(). If the client
> has
> > > managed the
> > > > sessionId properly, the servlet engine will pull it from the request,
> look
> > > up the session
> > > > context and make it avaliable to the servlet. I may not have the exact
> > > details, but the main idea
> > > > is that a servlet can usually get a session context, into which it
> can
> > > store and retrieve
> > > > data relevant to a given sessionId or client.
> > > >
> > > > So, the rpcrouter is a servlet (essentially), and it has access to the
> > > session, servlet context,
> > > > request, response, etc. It's main job is to decode the soap call, map
> it
> > > to a provider
> > > > object, and invoke the appropriate method (with parms) on the provider
> > > object.
> > > >
> > > > The provider object is not a servlet, or at least it doesn't act like
> one.
> > > Even though
> > > > it executes in the same thread as the rpcrouter servlet, it does not
> have
> > > access to the
> > > > servlet data, mentioned above.
> > > >
> > > > My question is why couldn't the provider object be handed the
> servlet's
> > > session
> > > > because it too might need to manage things relative to a particular
> > > sessionId.
> > > >
> > > > > [snip]
> > > > >
> > > > > >What if there was an interface, ie., iSoapService, that all
> provider
> > > classes implemented.
> > > > > >The interface would allow the rpcrouter to set some
> > > > > >useful servlet related data, ie., the session, on the provider
> before
> > > > > >invoking the method call.
> > > > >
> > > > > >public interface iSoapService
> > > > > >{
> > > > > > public void setSession( Session s );
> > > > > > // maybe others... ??
> > > > > >}
> > > > >
> > > > > The drawback of that approach is that you're forcing the target
> provider
> > > class to
> > > > > implement your provider interface, making deployment of SOAP
> services
> > > less seamless
> > > > > than it is today.
> > > >
> > > > I'll buy that. So we could have the rpcrouter relfect the provider
> class
> > > and if the
> > > > iSoapService interface is present, the setSession(...) method will be
> > > called on it
> > > > sometime prior to the invoke. I might be thinking about this the wrong
> way
> > > but
> > > > it seems to me that there is a better than equal chance that the
> provider
> > > class is
> > > > a new piece of code, probably functioning as a proxy that delgates to
> the
> > > real
> > > > app service, ie., a remote ejb, or whatever. In such a case, having to
> > > implement
> > > > an interface is not a bother.
> > > >
> > > > >
> > > > >
> > > > > >The only other approach I've found to accomplish this is to insert
> > > MyServlet
> > > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > > >and stores the session so that downstream my provider class can get
> the
> > > > > >session. MyServlet then calls RequestDispatcher method include() on
> > > rpcrouter
> > > > > >to let the soap call
> > > > > >complete. Then, when rpcrouter returns from the include(),
> MyServlet
> > > > > >removes the session from the cache.
> > > > >
> > > > > That current thread kludge sounds familiar (I implemented multipart
> mime
> > > that way). :-)
> > > > > Once again, the drawback is that the service provider class has to
> be
> > > familiar with the
> > > > > session context concept.
> > > >
> > > > Yep, if it needs the session, it would be willing to pay for it.
> > > >
> > > > >
> > > > > [snip]
> > > >
> > > > >
> > > > > One danger is that they may be unrelated and
> > > > > interfere with eachother if the session context is simple, e.g. key
> > > string/value object pairs
> > > > > in the HttpSession, where the keys are not necessarily unique across
> > > independently
> > > > > developed providers. The client should also be able to specify the
> > > session to handle
> > > > > multiple simultaneous sessions.
> > > >
> > > > I'm not sure I'm following here. I'm naivley thinking that I can use
> the
> > > current thread to
> > > > derive some sort of unique key to store the session object. The
> provider
> > > objecet, which
> > > > is essentially an extension of the executing servlet group, is
> exectuing
> > > in the same
> > > > thread, thus it will use the same key to fetch the session object
> that
> > > was used to
> > > > store it and given that, there should be no conflict with session
> content.
> > > So it looks like this:
> > > >
> > > > store/remove +--------------+ get session
> > > > +--------------> | session cache |<-------------+
> > > > | +--------------+
> > > |
> > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > <----------------------------------------------------+
> > > >
> > > > >
> > > > >
> > > > > Now, this is how I understand the current lifecycle management. A
> > > session can only be
> > > > > maintained for a single provider class. The deployment descriptor
> > > indicates a session
> > > > > scope. When first called, the servlet/JSP creates a new HttpSession,
> > > instantiates an
> > > > > object of the provider class and stores the object in the
> HttpSession
> > > with the service's ID
> > > > > (urn) as a key. The target method is invoked, the response is
> returned
> > > along with a
> > > > > session cookie in the header. If the client calls again with the
> session
> > > cookie set, the
> > > > > same object, with the same instance variables, is pulled from the
> > > HttpSession and a
> > > > > method invoked on it. The provider object's life ends when the
> session
> > > times out (maybe
> > > > > the timeout value can be set by the client in some way).
> > > >
> > > > I was under the impression that there was only one instance of a
> provider
> > > and that it
> > > > should be thread safe. If there is a new instance of the provider for
> > > every HttpSession,
> > > > then the provider itself could be used to store provider-specific
> session
> > > data.
> > > >
> > > > How does this map to the scope specifier in the deployment descriptor?
> If
> > > 'application'
> > > > is specified, does the provider class instance get stored in the
> 'servlet
> > > context' and if
> > > > the scope is specified as 'session' is the provider class instance
> stored
> > > in the
> > > > 'servlet session'?
> > > >
> > > > Could someone clarify this please?
> > > >
> > > > >
> > > > > If you need multiple services to share a single session context,
> then
> > > make the one
> > > > > provider class a facade for them, implementing all the method calls.
> It
> > > could call the
> > > > > target classes with a reference to "this" so they can get to the
> > > instance variables
> > > > > corresponding to the session context, or it could keep a reference
> to
> > > all objects of other
> > > > > classes used, or simply pass variables and store return values etc.
> > > > >
> > > > > Somebody correct me if I'm full of it?
> > > >
> > > > whether you got all the details right or not, I appreciate the time
> you've
> > > taken to further
> > > > this discussion.
> > > >
> > > > >
> > > > >
> > > > > bfn, Wouter
> > > > > --
> > > > > http://www.workspot.net/~zombie/soap/
> > > > > My opinions are irrelevant. They will be assimilated by my employer.
> > > >
> >
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Cory Isaacson wrote:
> Rich,
>
> It would have to be with the servlet version, which I didn't realize was not
> yet available. And yes, it makes sense as a standard feature.
>
> However, if you built a subclass wrapper, you shouldn't have to change
> anything with a new SOAP version, as the super class would automatically
> change on installation, so it might be a good temporary fix.
Well maybe. I say this because I doubt the rpcrouter is written to be very
extendable. IOW, I would only want to extend the fact that the provider should
be passed the session. I would probably have to overwrite the whole post method.
Besides, as you said above, it belongs a s a standard feature. Really what needs
to happen is that the deployment scope specifier needs to be fully implemented.
Right now, no matter what you specifiy, the scoping is application -- which really
means that the provider instance is instantiated once and stored in the
ServletContext. So, every provider instance is essentially an extension of the
servlet, but *without* access to servlet data, ie., session, etc.
>
>
> The only other idea I had was to make a 'login/logout' SOAP call from your
> client apps, storing some sort of session like key, but that would add more
> overhead if you don't need user validation. That's probably what you're
> doing with the thread ID.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 1:09 PM
> Subject: Re: Soap Provider classes need access to servlet data
>
> > Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
> > all, I'm still waiting for the servlet implementation of rpcrouter.
> Secondly,
> > I don't want to have to make mods to my derivation on every release of
> > the soap layer.
> >
> > Moreover, I'd prefer it be standard behavior in the soap layer. I like the
> idea
> > of a standard layer. Although, I've been tempted serveral times to
> implement
> > my own app specific soap layer, such that it would be optimized for
> exactly
> > what I need, but the benefits of a standard layer are compelling.
> >
> > Cory Isaacson wrote:
> >
> > > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > > client classes and do this as a simple wrapper? I would think it would
> be
> > > very easy, but I'm not sure about the instance problem you mentioned. It
> > > seems like the session object could just be retrieved for each SOAP call
> and
> > > made available to the provider without getting in the way of anything
> else.
> > > I did something similar in another application I made and it worked
> fine.
> > >
> > > Cory
> > > ----- Original Message -----
> > > From: "Rich Johns" <rj...@vignette.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, August 08, 2000 10:31 AM
> > > Subject: Re: Soap Provider classes need access to servlet data
> > >
> > > >
> > > >
> > > > Wouter Cloetens wrote:
> > > >
> > > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > > >
> > > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > > >so that it could cache session related data in it and let the
> servlet
> > > > > >engine manage the session.
> > > > >
> > > > > By HTTPSession you mean an HttpSession, identified by a session id
> in a
> > > cookie?
> > > > > SOAP clients could then read the new session cookie returned by the
> > > initial request and
> > > > > set that on subsequent requests.
> > > >
> > > > yes, I do mean HttpSession. A soap client would have to support
> cookies or
> > > url
> > > > rewriting to take advantage of the session id. But most of this is
> > > automatic from the
> > > > perspective of the servlet, which can do a getSession(). If the client
> has
> > > managed the
> > > > sessionId properly, the servlet engine will pull it from the request,
> look
> > > up the session
> > > > context and make it avaliable to the servlet. I may not have the exact
> > > details, but the main idea
> > > > is that a servlet can usually get a session context, into which it
> can
> > > store and retrieve
> > > > data relevant to a given sessionId or client.
> > > >
> > > > So, the rpcrouter is a servlet (essentially), and it has access to the
> > > session, servlet context,
> > > > request, response, etc. It's main job is to decode the soap call, map
> it
> > > to a provider
> > > > object, and invoke the appropriate method (with parms) on the provider
> > > object.
> > > >
> > > > The provider object is not a servlet, or at least it doesn't act like
> one.
> > > Even though
> > > > it executes in the same thread as the rpcrouter servlet, it does not
> have
> > > access to the
> > > > servlet data, mentioned above.
> > > >
> > > > My question is why couldn't the provider object be handed the
> servlet's
> > > session
> > > > because it too might need to manage things relative to a particular
> > > sessionId.
> > > >
> > > > > [snip]
> > > > >
> > > > > >What if there was an interface, ie., iSoapService, that all
> provider
> > > classes implemented.
> > > > > >The interface would allow the rpcrouter to set some
> > > > > >useful servlet related data, ie., the session, on the provider
> before
> > > > > >invoking the method call.
> > > > >
> > > > > >public interface iSoapService
> > > > > >{
> > > > > > public void setSession( Session s );
> > > > > > // maybe others... ??
> > > > > >}
> > > > >
> > > > > The drawback of that approach is that you're forcing the target
> provider
> > > class to
> > > > > implement your provider interface, making deployment of SOAP
> services
> > > less seamless
> > > > > than it is today.
> > > >
> > > > I'll buy that. So we could have the rpcrouter relfect the provider
> class
> > > and if the
> > > > iSoapService interface is present, the setSession(...) method will be
> > > called on it
> > > > sometime prior to the invoke. I might be thinking about this the wrong
> way
> > > but
> > > > it seems to me that there is a better than equal chance that the
> provider
> > > class is
> > > > a new piece of code, probably functioning as a proxy that delgates to
> the
> > > real
> > > > app service, ie., a remote ejb, or whatever. In such a case, having to
> > > implement
> > > > an interface is not a bother.
> > > >
> > > > >
> > > > >
> > > > > >The only other approach I've found to accomplish this is to insert
> > > MyServlet
> > > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > > >and stores the session so that downstream my provider class can get
> the
> > > > > >session. MyServlet then calls RequestDispatcher method include() on
> > > rpcrouter
> > > > > >to let the soap call
> > > > > >complete. Then, when rpcrouter returns from the include(),
> MyServlet
> > > > > >removes the session from the cache.
> > > > >
> > > > > That current thread kludge sounds familiar (I implemented multipart
> mime
> > > that way). :-)
> > > > > Once again, the drawback is that the service provider class has to
> be
> > > familiar with the
> > > > > session context concept.
> > > >
> > > > Yep, if it needs the session, it would be willing to pay for it.
> > > >
> > > > >
> > > > > [snip]
> > > >
> > > > >
> > > > > One danger is that they may be unrelated and
> > > > > interfere with eachother if the session context is simple, e.g. key
> > > string/value object pairs
> > > > > in the HttpSession, where the keys are not necessarily unique across
> > > independently
> > > > > developed providers. The client should also be able to specify the
> > > session to handle
> > > > > multiple simultaneous sessions.
> > > >
> > > > I'm not sure I'm following here. I'm naivley thinking that I can use
> the
> > > current thread to
> > > > derive some sort of unique key to store the session object. The
> provider
> > > objecet, which
> > > > is essentially an extension of the executing servlet group, is
> exectuing
> > > in the same
> > > > thread, thus it will use the same key to fetch the session object
> that
> > > was used to
> > > > store it and given that, there should be no conflict with session
> content.
> > > So it looks like this:
> > > >
> > > > store/remove +--------------+ get session
> > > > +--------------> | session cache |<-------------+
> > > > | +--------------+
> > > |
> > > > ---> myServlet ---->rpcrouter------------------->provider
> > > > <----------------------------------------------------+
> > > >
> > > > >
> > > > >
> > > > > Now, this is how I understand the current lifecycle management. A
> > > session can only be
> > > > > maintained for a single provider class. The deployment descriptor
> > > indicates a session
> > > > > scope. When first called, the servlet/JSP creates a new HttpSession,
> > > instantiates an
> > > > > object of the provider class and stores the object in the
> HttpSession
> > > with the service's ID
> > > > > (urn) as a key. The target method is invoked, the response is
> returned
> > > along with a
> > > > > session cookie in the header. If the client calls again with the
> session
> > > cookie set, the
> > > > > same object, with the same instance variables, is pulled from the
> > > HttpSession and a
> > > > > method invoked on it. The provider object's life ends when the
> session
> > > times out (maybe
> > > > > the timeout value can be set by the client in some way).
> > > >
> > > > I was under the impression that there was only one instance of a
> provider
> > > and that it
> > > > should be thread safe. If there is a new instance of the provider for
> > > every HttpSession,
> > > > then the provider itself could be used to store provider-specific
> session
> > > data.
> > > >
> > > > How does this map to the scope specifier in the deployment descriptor?
> If
> > > 'application'
> > > > is specified, does the provider class instance get stored in the
> 'servlet
> > > context' and if
> > > > the scope is specified as 'session' is the provider class instance
> stored
> > > in the
> > > > 'servlet session'?
> > > >
> > > > Could someone clarify this please?
> > > >
> > > > >
> > > > > If you need multiple services to share a single session context,
> then
> > > make the one
> > > > > provider class a facade for them, implementing all the method calls.
> It
> > > could call the
> > > > > target classes with a reference to "this" so they can get to the
> > > instance variables
> > > > > corresponding to the session context, or it could keep a reference
> to
> > > all objects of other
> > > > > classes used, or simply pass variables and store return values etc.
> > > > >
> > > > > Somebody correct me if I'm full of it?
> > > >
> > > > whether you got all the details right or not, I appreciate the time
> you've
> > > taken to further
> > > > this discussion.
> > > >
> > > > >
> > > > >
> > > > > bfn, Wouter
> > > > > --
> > > > > http://www.workspot.net/~zombie/soap/
> > > > > My opinions are irrelevant. They will be assimilated by my employer.
> > > >
> >
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
Rich,
It would have to be with the servlet version, which I didn't realize was not
yet available. And yes, it makes sense as a standard feature.
However, if you built a subclass wrapper, you shouldn't have to change
anything with a new SOAP version, as the super class would automatically
change on installation, so it might be a good temporary fix.
The only other idea I had was to make a 'login/logout' SOAP call from your
client apps, storing some sort of session like key, but that would add more
overhead if you don't need user validation. That's probably what you're
doing with the thread ID.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 1:09 PM
Subject: Re: Soap Provider classes need access to servlet data
> Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
> all, I'm still waiting for the servlet implementation of rpcrouter.
Secondly,
> I don't want to have to make mods to my derivation on every release of
> the soap layer.
>
> Moreover, I'd prefer it be standard behavior in the soap layer. I like the
idea
> of a standard layer. Although, I've been tempted serveral times to
implement
> my own app specific soap layer, such that it would be optimized for
exactly
> what I need, but the benefits of a standard layer are compelling.
>
> Cory Isaacson wrote:
>
> > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > client classes and do this as a simple wrapper? I would think it would
be
> > very easy, but I'm not sure about the instance problem you mentioned. It
> > seems like the session object could just be retrieved for each SOAP call
and
> > made available to the provider without getting in the way of anything
else.
> > I did something similar in another application I made and it worked
fine.
> >
> > Cory
> > ----- Original Message -----
> > From: "Rich Johns" <rj...@vignette.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, August 08, 2000 10:31 AM
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> > >
> > >
> > > Wouter Cloetens wrote:
> > >
> > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > >
> > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > >so that it could cache session related data in it and let the
servlet
> > > > >engine manage the session.
> > > >
> > > > By HTTPSession you mean an HttpSession, identified by a session id
in a
> > cookie?
> > > > SOAP clients could then read the new session cookie returned by the
> > initial request and
> > > > set that on subsequent requests.
> > >
> > > yes, I do mean HttpSession. A soap client would have to support
cookies or
> > url
> > > rewriting to take advantage of the session id. But most of this is
> > automatic from the
> > > perspective of the servlet, which can do a getSession(). If the client
has
> > managed the
> > > sessionId properly, the servlet engine will pull it from the request,
look
> > up the session
> > > context and make it avaliable to the servlet. I may not have the exact
> > details, but the main idea
> > > is that a servlet can usually get a session context, into which it
can
> > store and retrieve
> > > data relevant to a given sessionId or client.
> > >
> > > So, the rpcrouter is a servlet (essentially), and it has access to the
> > session, servlet context,
> > > request, response, etc. It's main job is to decode the soap call, map
it
> > to a provider
> > > object, and invoke the appropriate method (with parms) on the provider
> > object.
> > >
> > > The provider object is not a servlet, or at least it doesn't act like
one.
> > Even though
> > > it executes in the same thread as the rpcrouter servlet, it does not
have
> > access to the
> > > servlet data, mentioned above.
> > >
> > > My question is why couldn't the provider object be handed the
servlet's
> > session
> > > because it too might need to manage things relative to a particular
> > sessionId.
> > >
> > > > [snip]
> > > >
> > > > >What if there was an interface, ie., iSoapService, that all
provider
> > classes implemented.
> > > > >The interface would allow the rpcrouter to set some
> > > > >useful servlet related data, ie., the session, on the provider
before
> > > > >invoking the method call.
> > > >
> > > > >public interface iSoapService
> > > > >{
> > > > > public void setSession( Session s );
> > > > > // maybe others... ??
> > > > >}
> > > >
> > > > The drawback of that approach is that you're forcing the target
provider
> > class to
> > > > implement your provider interface, making deployment of SOAP
services
> > less seamless
> > > > than it is today.
> > >
> > > I'll buy that. So we could have the rpcrouter relfect the provider
class
> > and if the
> > > iSoapService interface is present, the setSession(...) method will be
> > called on it
> > > sometime prior to the invoke. I might be thinking about this the wrong
way
> > but
> > > it seems to me that there is a better than equal chance that the
provider
> > class is
> > > a new piece of code, probably functioning as a proxy that delgates to
the
> > real
> > > app service, ie., a remote ejb, or whatever. In such a case, having to
> > implement
> > > an interface is not a bother.
> > >
> > > >
> > > >
> > > > >The only other approach I've found to accomplish this is to insert
> > MyServlet
> > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > >and stores the session so that downstream my provider class can get
the
> > > > >session. MyServlet then calls RequestDispatcher method include() on
> > rpcrouter
> > > > >to let the soap call
> > > > >complete. Then, when rpcrouter returns from the include(),
MyServlet
> > > > >removes the session from the cache.
> > > >
> > > > That current thread kludge sounds familiar (I implemented multipart
mime
> > that way). :-)
> > > > Once again, the drawback is that the service provider class has to
be
> > familiar with the
> > > > session context concept.
> > >
> > > Yep, if it needs the session, it would be willing to pay for it.
> > >
> > > >
> > > > [snip]
> > >
> > > >
> > > > One danger is that they may be unrelated and
> > > > interfere with eachother if the session context is simple, e.g. key
> > string/value object pairs
> > > > in the HttpSession, where the keys are not necessarily unique across
> > independently
> > > > developed providers. The client should also be able to specify the
> > session to handle
> > > > multiple simultaneous sessions.
> > >
> > > I'm not sure I'm following here. I'm naivley thinking that I can use
the
> > current thread to
> > > derive some sort of unique key to store the session object. The
provider
> > objecet, which
> > > is essentially an extension of the executing servlet group, is
exectuing
> > in the same
> > > thread, thus it will use the same key to fetch the session object
that
> > was used to
> > > store it and given that, there should be no conflict with session
content.
> > So it looks like this:
> > >
> > > store/remove +--------------+ get session
> > > +--------------> | session cache |<-------------+
> > > | +--------------+
> > |
> > > ---> myServlet ---->rpcrouter------------------->provider
> > > <----------------------------------------------------+
> > >
> > > >
> > > >
> > > > Now, this is how I understand the current lifecycle management. A
> > session can only be
> > > > maintained for a single provider class. The deployment descriptor
> > indicates a session
> > > > scope. When first called, the servlet/JSP creates a new HttpSession,
> > instantiates an
> > > > object of the provider class and stores the object in the
HttpSession
> > with the service's ID
> > > > (urn) as a key. The target method is invoked, the response is
returned
> > along with a
> > > > session cookie in the header. If the client calls again with the
session
> > cookie set, the
> > > > same object, with the same instance variables, is pulled from the
> > HttpSession and a
> > > > method invoked on it. The provider object's life ends when the
session
> > times out (maybe
> > > > the timeout value can be set by the client in some way).
> > >
> > > I was under the impression that there was only one instance of a
provider
> > and that it
> > > should be thread safe. If there is a new instance of the provider for
> > every HttpSession,
> > > then the provider itself could be used to store provider-specific
session
> > data.
> > >
> > > How does this map to the scope specifier in the deployment descriptor?
If
> > 'application'
> > > is specified, does the provider class instance get stored in the
'servlet
> > context' and if
> > > the scope is specified as 'session' is the provider class instance
stored
> > in the
> > > 'servlet session'?
> > >
> > > Could someone clarify this please?
> > >
> > > >
> > > > If you need multiple services to share a single session context,
then
> > make the one
> > > > provider class a facade for them, implementing all the method calls.
It
> > could call the
> > > > target classes with a reference to "this" so they can get to the
> > instance variables
> > > > corresponding to the session context, or it could keep a reference
to
> > all objects of other
> > > > classes used, or simply pass variables and store return values etc.
> > > >
> > > > Somebody correct me if I'm full of it?
> > >
> > > whether you got all the details right or not, I appreciate the time
you've
> > taken to further
> > > this discussion.
> > >
> > > >
> > > >
> > > > bfn, Wouter
> > > > --
> > > > http://www.workspot.net/~zombie/soap/
> > > > My opinions are irrelevant. They will be assimilated by my employer.
> > >
>
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
Rich,
It would have to be with the servlet version, which I didn't realize was not
yet available. And yes, it makes sense as a standard feature.
However, if you built a subclass wrapper, you shouldn't have to change
anything with a new SOAP version, as the super class would automatically
change on installation, so it might be a good temporary fix.
The only other idea I had was to make a 'login/logout' SOAP call from your
client apps, storing some sort of session like key, but that would add more
overhead if you don't need user validation. That's probably what you're
doing with the thread ID.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 1:09 PM
Subject: Re: Soap Provider classes need access to servlet data
> Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
> all, I'm still waiting for the servlet implementation of rpcrouter.
Secondly,
> I don't want to have to make mods to my derivation on every release of
> the soap layer.
>
> Moreover, I'd prefer it be standard behavior in the soap layer. I like the
idea
> of a standard layer. Although, I've been tempted serveral times to
implement
> my own app specific soap layer, such that it would be optimized for
exactly
> what I need, but the benefits of a standard layer are compelling.
>
> Cory Isaacson wrote:
>
> > Just out of curiosity, couldn't you just subclass the SOAP servlet and
> > client classes and do this as a simple wrapper? I would think it would
be
> > very easy, but I'm not sure about the instance problem you mentioned. It
> > seems like the session object could just be retrieved for each SOAP call
and
> > made available to the provider without getting in the way of anything
else.
> > I did something similar in another application I made and it worked
fine.
> >
> > Cory
> > ----- Original Message -----
> > From: "Rich Johns" <rj...@vignette.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, August 08, 2000 10:31 AM
> > Subject: Re: Soap Provider classes need access to servlet data
> >
> > >
> > >
> > > Wouter Cloetens wrote:
> > >
> > > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > > >
> > > > >It would be nice if a provider could have, say the HTTPSession,
> > > > >so that it could cache session related data in it and let the
servlet
> > > > >engine manage the session.
> > > >
> > > > By HTTPSession you mean an HttpSession, identified by a session id
in a
> > cookie?
> > > > SOAP clients could then read the new session cookie returned by the
> > initial request and
> > > > set that on subsequent requests.
> > >
> > > yes, I do mean HttpSession. A soap client would have to support
cookies or
> > url
> > > rewriting to take advantage of the session id. But most of this is
> > automatic from the
> > > perspective of the servlet, which can do a getSession(). If the client
has
> > managed the
> > > sessionId properly, the servlet engine will pull it from the request,
look
> > up the session
> > > context and make it avaliable to the servlet. I may not have the exact
> > details, but the main idea
> > > is that a servlet can usually get a session context, into which it
can
> > store and retrieve
> > > data relevant to a given sessionId or client.
> > >
> > > So, the rpcrouter is a servlet (essentially), and it has access to the
> > session, servlet context,
> > > request, response, etc. It's main job is to decode the soap call, map
it
> > to a provider
> > > object, and invoke the appropriate method (with parms) on the provider
> > object.
> > >
> > > The provider object is not a servlet, or at least it doesn't act like
one.
> > Even though
> > > it executes in the same thread as the rpcrouter servlet, it does not
have
> > access to the
> > > servlet data, mentioned above.
> > >
> > > My question is why couldn't the provider object be handed the
servlet's
> > session
> > > because it too might need to manage things relative to a particular
> > sessionId.
> > >
> > > > [snip]
> > > >
> > > > >What if there was an interface, ie., iSoapService, that all
provider
> > classes implemented.
> > > > >The interface would allow the rpcrouter to set some
> > > > >useful servlet related data, ie., the session, on the provider
before
> > > > >invoking the method call.
> > > >
> > > > >public interface iSoapService
> > > > >{
> > > > > public void setSession( Session s );
> > > > > // maybe others... ??
> > > > >}
> > > >
> > > > The drawback of that approach is that you're forcing the target
provider
> > class to
> > > > implement your provider interface, making deployment of SOAP
services
> > less seamless
> > > > than it is today.
> > >
> > > I'll buy that. So we could have the rpcrouter relfect the provider
class
> > and if the
> > > iSoapService interface is present, the setSession(...) method will be
> > called on it
> > > sometime prior to the invoke. I might be thinking about this the wrong
way
> > but
> > > it seems to me that there is a better than equal chance that the
provider
> > class is
> > > a new piece of code, probably functioning as a proxy that delgates to
the
> > real
> > > app service, ie., a remote ejb, or whatever. In such a case, having to
> > implement
> > > an interface is not a bother.
> > >
> > > >
> > > >
> > > > >The only other approach I've found to accomplish this is to insert
> > MyServlet
> > > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > > >and stores the session so that downstream my provider class can get
the
> > > > >session. MyServlet then calls RequestDispatcher method include() on
> > rpcrouter
> > > > >to let the soap call
> > > > >complete. Then, when rpcrouter returns from the include(),
MyServlet
> > > > >removes the session from the cache.
> > > >
> > > > That current thread kludge sounds familiar (I implemented multipart
mime
> > that way). :-)
> > > > Once again, the drawback is that the service provider class has to
be
> > familiar with the
> > > > session context concept.
> > >
> > > Yep, if it needs the session, it would be willing to pay for it.
> > >
> > > >
> > > > [snip]
> > >
> > > >
> > > > One danger is that they may be unrelated and
> > > > interfere with eachother if the session context is simple, e.g. key
> > string/value object pairs
> > > > in the HttpSession, where the keys are not necessarily unique across
> > independently
> > > > developed providers. The client should also be able to specify the
> > session to handle
> > > > multiple simultaneous sessions.
> > >
> > > I'm not sure I'm following here. I'm naivley thinking that I can use
the
> > current thread to
> > > derive some sort of unique key to store the session object. The
provider
> > objecet, which
> > > is essentially an extension of the executing servlet group, is
exectuing
> > in the same
> > > thread, thus it will use the same key to fetch the session object
that
> > was used to
> > > store it and given that, there should be no conflict with session
content.
> > So it looks like this:
> > >
> > > store/remove +--------------+ get session
> > > +--------------> | session cache |<-------------+
> > > | +--------------+
> > |
> > > ---> myServlet ---->rpcrouter------------------->provider
> > > <----------------------------------------------------+
> > >
> > > >
> > > >
> > > > Now, this is how I understand the current lifecycle management. A
> > session can only be
> > > > maintained for a single provider class. The deployment descriptor
> > indicates a session
> > > > scope. When first called, the servlet/JSP creates a new HttpSession,
> > instantiates an
> > > > object of the provider class and stores the object in the
HttpSession
> > with the service's ID
> > > > (urn) as a key. The target method is invoked, the response is
returned
> > along with a
> > > > session cookie in the header. If the client calls again with the
session
> > cookie set, the
> > > > same object, with the same instance variables, is pulled from the
> > HttpSession and a
> > > > method invoked on it. The provider object's life ends when the
session
> > times out (maybe
> > > > the timeout value can be set by the client in some way).
> > >
> > > I was under the impression that there was only one instance of a
provider
> > and that it
> > > should be thread safe. If there is a new instance of the provider for
> > every HttpSession,
> > > then the provider itself could be used to store provider-specific
session
> > data.
> > >
> > > How does this map to the scope specifier in the deployment descriptor?
If
> > 'application'
> > > is specified, does the provider class instance get stored in the
'servlet
> > context' and if
> > > the scope is specified as 'session' is the provider class instance
stored
> > in the
> > > 'servlet session'?
> > >
> > > Could someone clarify this please?
> > >
> > > >
> > > > If you need multiple services to share a single session context,
then
> > make the one
> > > > provider class a facade for them, implementing all the method calls.
It
> > could call the
> > > > target classes with a reference to "this" so they can get to the
> > instance variables
> > > > corresponding to the session context, or it could keep a reference
to
> > all objects of other
> > > > classes used, or simply pass variables and store return values etc.
> > > >
> > > > Somebody correct me if I'm full of it?
> > >
> > > whether you got all the details right or not, I appreciate the time
you've
> > taken to further
> > > this discussion.
> > >
> > > >
> > > >
> > > > bfn, Wouter
> > > > --
> > > > http://www.workspot.net/~zombie/soap/
> > > > My opinions are irrelevant. They will be assimilated by my employer.
> > >
>
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
If you want to go that route Glenn, you may want to take a look
the Servlet code I submitted last week to soap-dev or the new stuff Sanjiva
posted to CVS..
The Servlet code is a pretty good base to see how to grab the SOAP Payload
and
parse it out (it does assume HTTP).. If you don't even want HTTP, then all
you
need to do is to somehow grab the SOAP Payload into an "array" and feed it
to
the XML Processor (again, just later on in the Servlet code)..
Then you could do whatever you want with it using the DOM routines, etc.
-Steve
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 1:34 PM
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
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
If you want to go that route Glenn, you may want to take a look
the Servlet code I submitted last week to soap-dev or the new stuff Sanjiva
posted to CVS..
The Servlet code is a pretty good base to see how to grab the SOAP Payload
and
parse it out (it does assume HTTP).. If you don't even want HTTP, then all
you
need to do is to somehow grab the SOAP Payload into an "array" and feed it
to
the XML Processor (again, just later on in the Servlet code)..
Then you could do whatever you want with it using the DOM routines, etc.
-Steve
-----Original Message-----
From: Glenn Judd [mailto:glennj@cs.cmu.edu]
Sent: Tuesday, August 08, 2000 1:34 PM
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
Re: Soap Provider classes need access to servlet data
Posted by Glenn Judd <gl...@cs.cmu.edu>.
(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
Re: Soap Provider classes need access to servlet data
Posted by Glenn Judd <gl...@cs.cmu.edu>.
(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
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
Well, the first "official" version of the RPC Servlet was just checked
in this morning.. Although a little different from what I submitted to the
soap-dev group a week ago, it will be the foundation for on-going work ..
I think a couple of more revisions (quick ones I hope) will be made before
it is ready for "prime-time" but its a start and it does work. ;-)
Rich, perhaps you should subscribe to the soap-dev list as well?
I like the idea of abstracting the behavior in a standard layer and not
sub-classing
either the jsp (egawds) or even the RPC Servlet..
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 12:10 PM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
all, I'm still waiting for the servlet implementation of rpcrouter.
Secondly,
I don't want to have to make mods to my derivation on every release of
the soap layer.
Moreover, I'd prefer it be standard behavior in the soap layer. I like the
idea
of a standard layer. Although, I've been tempted serveral times to implement
my own app specific soap layer, such that it would be optimized for exactly
what I need, but the benefits of a standard layer are compelling.
Cory Isaacson wrote:
> Just out of curiosity, couldn't you just subclass the SOAP servlet and
> client classes and do this as a simple wrapper? I would think it would be
> very easy, but I'm not sure about the instance problem you mentioned. It
> seems like the session object could just be retrieved for each SOAP call
and
> made available to the provider without getting in the way of anything
else.
> I did something similar in another application I made and it worked fine.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 10:31 AM
> Subject: Re: Soap Provider classes need access to servlet data
>
> >
> >
> > Wouter Cloetens wrote:
> >
> > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > >
> > > >It would be nice if a provider could have, say the HTTPSession,
> > > >so that it could cache session related data in it and let the servlet
> > > >engine manage the session.
> > >
> > > By HTTPSession you mean an HttpSession, identified by a session id in
a
> cookie?
> > > SOAP clients could then read the new session cookie returned by the
> initial request and
> > > set that on subsequent requests.
> >
> > yes, I do mean HttpSession. A soap client would have to support cookies
or
> url
> > rewriting to take advantage of the session id. But most of this is
> automatic from the
> > perspective of the servlet, which can do a getSession(). If the client
has
> managed the
> > sessionId properly, the servlet engine will pull it from the request,
look
> up the session
> > context and make it avaliable to the servlet. I may not have the exact
> details, but the main idea
> > is that a servlet can usually get a session context, into which it can
> store and retrieve
> > data relevant to a given sessionId or client.
> >
> > So, the rpcrouter is a servlet (essentially), and it has access to the
> session, servlet context,
> > request, response, etc. It's main job is to decode the soap call, map it
> to a provider
> > object, and invoke the appropriate method (with parms) on the provider
> object.
> >
> > The provider object is not a servlet, or at least it doesn't act like
one.
> Even though
> > it executes in the same thread as the rpcrouter servlet, it does not
have
> access to the
> > servlet data, mentioned above.
> >
> > My question is why couldn't the provider object be handed the servlet's
> session
> > because it too might need to manage things relative to a particular
> sessionId.
> >
> > > [snip]
> > >
> > > >What if there was an interface, ie., iSoapService, that all provider
> classes implemented.
> > > >The interface would allow the rpcrouter to set some
> > > >useful servlet related data, ie., the session, on the provider before
> > > >invoking the method call.
> > >
> > > >public interface iSoapService
> > > >{
> > > > public void setSession( Session s );
> > > > // maybe others... ??
> > > >}
> > >
> > > The drawback of that approach is that you're forcing the target
provider
> class to
> > > implement your provider interface, making deployment of SOAP services
> less seamless
> > > than it is today.
> >
> > I'll buy that. So we could have the rpcrouter relfect the provider class
> and if the
> > iSoapService interface is present, the setSession(...) method will be
> called on it
> > sometime prior to the invoke. I might be thinking about this the wrong
way
> but
> > it seems to me that there is a better than equal chance that the
provider
> class is
> > a new piece of code, probably functioning as a proxy that delgates to
the
> real
> > app service, ie., a remote ejb, or whatever. In such a case, having to
> implement
> > an interface is not a bother.
> >
> > >
> > >
> > > >The only other approach I've found to accomplish this is to insert
> MyServlet
> > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > >and stores the session so that downstream my provider class can get
the
> > > >session. MyServlet then calls RequestDispatcher method include() on
> rpcrouter
> > > >to let the soap call
> > > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > > >removes the session from the cache.
> > >
> > > That current thread kludge sounds familiar (I implemented multipart
mime
> that way). :-)
> > > Once again, the drawback is that the service provider class has to be
> familiar with the
> > > session context concept.
> >
> > Yep, if it needs the session, it would be willing to pay for it.
> >
> > >
> > > [snip]
> >
> > >
> > > One danger is that they may be unrelated and
> > > interfere with eachother if the session context is simple, e.g. key
> string/value object pairs
> > > in the HttpSession, where the keys are not necessarily unique across
> independently
> > > developed providers. The client should also be able to specify the
> session to handle
> > > multiple simultaneous sessions.
> >
> > I'm not sure I'm following here. I'm naivley thinking that I can use the
> current thread to
> > derive some sort of unique key to store the session object. The provider
> objecet, which
> > is essentially an extension of the executing servlet group, is exectuing
> in the same
> > thread, thus it will use the same key to fetch the session object that
> was used to
> > store it and given that, there should be no conflict with session
content.
> So it looks like this:
> >
> > store/remove +--------------+ get session
> > +--------------> | session cache |<-------------+
> > | +--------------+
> |
> > ---> myServlet ---->rpcrouter------------------->provider
> > <----------------------------------------------------+
> >
> > >
> > >
> > > Now, this is how I understand the current lifecycle management. A
> session can only be
> > > maintained for a single provider class. The deployment descriptor
> indicates a session
> > > scope. When first called, the servlet/JSP creates a new HttpSession,
> instantiates an
> > > object of the provider class and stores the object in the HttpSession
> with the service's ID
> > > (urn) as a key. The target method is invoked, the response is returned
> along with a
> > > session cookie in the header. If the client calls again with the
session
> cookie set, the
> > > same object, with the same instance variables, is pulled from the
> HttpSession and a
> > > method invoked on it. The provider object's life ends when the session
> times out (maybe
> > > the timeout value can be set by the client in some way).
> >
> > I was under the impression that there was only one instance of a
provider
> and that it
> > should be thread safe. If there is a new instance of the provider for
> every HttpSession,
> > then the provider itself could be used to store provider-specific
session
> data.
> >
> > How does this map to the scope specifier in the deployment descriptor?
If
> 'application'
> > is specified, does the provider class instance get stored in the
'servlet
> context' and if
> > the scope is specified as 'session' is the provider class instance
stored
> in the
> > 'servlet session'?
> >
> > Could someone clarify this please?
> >
> > >
> > > If you need multiple services to share a single session context, then
> make the one
> > > provider class a facade for them, implementing all the method calls.
It
> could call the
> > > target classes with a reference to "this" so they can get to the
> instance variables
> > > corresponding to the session context, or it could keep a reference to
> all objects of other
> > > classes used, or simply pass variables and store return values etc.
> > >
> > > Somebody correct me if I'm full of it?
> >
> > whether you got all the details right or not, I appreciate the time
you've
> taken to further
> > this discussion.
> >
> > >
> > >
> > > bfn, Wouter
> > > --
> > > http://www.workspot.net/~zombie/soap/
> > > My opinions are irrelevant. They will be assimilated by my employer.
> >
RE: Soap Provider classes need access to servlet data
Posted by Steven McDowall <sj...@aptest.com>.
Well, the first "official" version of the RPC Servlet was just checked
in this morning.. Although a little different from what I submitted to the
soap-dev group a week ago, it will be the foundation for on-going work ..
I think a couple of more revisions (quick ones I hope) will be made before
it is ready for "prime-time" but its a start and it does work. ;-)
Rich, perhaps you should subscribe to the soap-dev list as well?
I like the idea of abstracting the behavior in a standard layer and not
sub-classing
either the jsp (egawds) or even the RPC Servlet..
-Steve
-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Tuesday, August 08, 2000 12:10 PM
To: soap-user@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data
Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
all, I'm still waiting for the servlet implementation of rpcrouter.
Secondly,
I don't want to have to make mods to my derivation on every release of
the soap layer.
Moreover, I'd prefer it be standard behavior in the soap layer. I like the
idea
of a standard layer. Although, I've been tempted serveral times to implement
my own app specific soap layer, such that it would be optimized for exactly
what I need, but the benefits of a standard layer are compelling.
Cory Isaacson wrote:
> Just out of curiosity, couldn't you just subclass the SOAP servlet and
> client classes and do this as a simple wrapper? I would think it would be
> very easy, but I'm not sure about the instance problem you mentioned. It
> seems like the session object could just be retrieved for each SOAP call
and
> made available to the provider without getting in the way of anything
else.
> I did something similar in another application I made and it worked fine.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 10:31 AM
> Subject: Re: Soap Provider classes need access to servlet data
>
> >
> >
> > Wouter Cloetens wrote:
> >
> > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > >
> > > >It would be nice if a provider could have, say the HTTPSession,
> > > >so that it could cache session related data in it and let the servlet
> > > >engine manage the session.
> > >
> > > By HTTPSession you mean an HttpSession, identified by a session id in
a
> cookie?
> > > SOAP clients could then read the new session cookie returned by the
> initial request and
> > > set that on subsequent requests.
> >
> > yes, I do mean HttpSession. A soap client would have to support cookies
or
> url
> > rewriting to take advantage of the session id. But most of this is
> automatic from the
> > perspective of the servlet, which can do a getSession(). If the client
has
> managed the
> > sessionId properly, the servlet engine will pull it from the request,
look
> up the session
> > context and make it avaliable to the servlet. I may not have the exact
> details, but the main idea
> > is that a servlet can usually get a session context, into which it can
> store and retrieve
> > data relevant to a given sessionId or client.
> >
> > So, the rpcrouter is a servlet (essentially), and it has access to the
> session, servlet context,
> > request, response, etc. It's main job is to decode the soap call, map it
> to a provider
> > object, and invoke the appropriate method (with parms) on the provider
> object.
> >
> > The provider object is not a servlet, or at least it doesn't act like
one.
> Even though
> > it executes in the same thread as the rpcrouter servlet, it does not
have
> access to the
> > servlet data, mentioned above.
> >
> > My question is why couldn't the provider object be handed the servlet's
> session
> > because it too might need to manage things relative to a particular
> sessionId.
> >
> > > [snip]
> > >
> > > >What if there was an interface, ie., iSoapService, that all provider
> classes implemented.
> > > >The interface would allow the rpcrouter to set some
> > > >useful servlet related data, ie., the session, on the provider before
> > > >invoking the method call.
> > >
> > > >public interface iSoapService
> > > >{
> > > > public void setSession( Session s );
> > > > // maybe others... ??
> > > >}
> > >
> > > The drawback of that approach is that you're forcing the target
provider
> class to
> > > implement your provider interface, making deployment of SOAP services
> less seamless
> > > than it is today.
> >
> > I'll buy that. So we could have the rpcrouter relfect the provider class
> and if the
> > iSoapService interface is present, the setSession(...) method will be
> called on it
> > sometime prior to the invoke. I might be thinking about this the wrong
way
> but
> > it seems to me that there is a better than equal chance that the
provider
> class is
> > a new piece of code, probably functioning as a proxy that delgates to
the
> real
> > app service, ie., a remote ejb, or whatever. In such a case, having to
> implement
> > an interface is not a bother.
> >
> > >
> > >
> > > >The only other approach I've found to accomplish this is to insert
> MyServlet
> > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > >and stores the session so that downstream my provider class can get
the
> > > >session. MyServlet then calls RequestDispatcher method include() on
> rpcrouter
> > > >to let the soap call
> > > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > > >removes the session from the cache.
> > >
> > > That current thread kludge sounds familiar (I implemented multipart
mime
> that way). :-)
> > > Once again, the drawback is that the service provider class has to be
> familiar with the
> > > session context concept.
> >
> > Yep, if it needs the session, it would be willing to pay for it.
> >
> > >
> > > [snip]
> >
> > >
> > > One danger is that they may be unrelated and
> > > interfere with eachother if the session context is simple, e.g. key
> string/value object pairs
> > > in the HttpSession, where the keys are not necessarily unique across
> independently
> > > developed providers. The client should also be able to specify the
> session to handle
> > > multiple simultaneous sessions.
> >
> > I'm not sure I'm following here. I'm naivley thinking that I can use the
> current thread to
> > derive some sort of unique key to store the session object. The provider
> objecet, which
> > is essentially an extension of the executing servlet group, is exectuing
> in the same
> > thread, thus it will use the same key to fetch the session object that
> was used to
> > store it and given that, there should be no conflict with session
content.
> So it looks like this:
> >
> > store/remove +--------------+ get session
> > +--------------> | session cache |<-------------+
> > | +--------------+
> |
> > ---> myServlet ---->rpcrouter------------------->provider
> > <----------------------------------------------------+
> >
> > >
> > >
> > > Now, this is how I understand the current lifecycle management. A
> session can only be
> > > maintained for a single provider class. The deployment descriptor
> indicates a session
> > > scope. When first called, the servlet/JSP creates a new HttpSession,
> instantiates an
> > > object of the provider class and stores the object in the HttpSession
> with the service's ID
> > > (urn) as a key. The target method is invoked, the response is returned
> along with a
> > > session cookie in the header. If the client calls again with the
session
> cookie set, the
> > > same object, with the same instance variables, is pulled from the
> HttpSession and a
> > > method invoked on it. The provider object's life ends when the session
> times out (maybe
> > > the timeout value can be set by the client in some way).
> >
> > I was under the impression that there was only one instance of a
provider
> and that it
> > should be thread safe. If there is a new instance of the provider for
> every HttpSession,
> > then the provider itself could be used to store provider-specific
session
> data.
> >
> > How does this map to the scope specifier in the deployment descriptor?
If
> 'application'
> > is specified, does the provider class instance get stored in the
'servlet
> context' and if
> > the scope is specified as 'session' is the provider class instance
stored
> in the
> > 'servlet session'?
> >
> > Could someone clarify this please?
> >
> > >
> > > If you need multiple services to share a single session context, then
> make the one
> > > provider class a facade for them, implementing all the method calls.
It
> could call the
> > > target classes with a reference to "this" so they can get to the
> instance variables
> > > corresponding to the session context, or it could keep a reference to
> all objects of other
> > > classes used, or simply pass variables and store return values etc.
> > >
> > > Somebody correct me if I'm full of it?
> >
> > whether you got all the details right or not, I appreciate the time
you've
> taken to further
> > this discussion.
> >
> > >
> > >
> > > bfn, Wouter
> > > --
> > > http://www.workspot.net/~zombie/soap/
> > > My opinions are irrelevant. They will be assimilated by my employer.
> >
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
all, I'm still waiting for the servlet implementation of rpcrouter. Secondly,
I don't want to have to make mods to my derivation on every release of
the soap layer.
Moreover, I'd prefer it be standard behavior in the soap layer. I like the idea
of a standard layer. Although, I've been tempted serveral times to implement
my own app specific soap layer, such that it would be optimized for exactly
what I need, but the benefits of a standard layer are compelling.
Cory Isaacson wrote:
> Just out of curiosity, couldn't you just subclass the SOAP servlet and
> client classes and do this as a simple wrapper? I would think it would be
> very easy, but I'm not sure about the instance problem you mentioned. It
> seems like the session object could just be retrieved for each SOAP call and
> made available to the provider without getting in the way of anything else.
> I did something similar in another application I made and it worked fine.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 10:31 AM
> Subject: Re: Soap Provider classes need access to servlet data
>
> >
> >
> > Wouter Cloetens wrote:
> >
> > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > >
> > > >It would be nice if a provider could have, say the HTTPSession,
> > > >so that it could cache session related data in it and let the servlet
> > > >engine manage the session.
> > >
> > > By HTTPSession you mean an HttpSession, identified by a session id in a
> cookie?
> > > SOAP clients could then read the new session cookie returned by the
> initial request and
> > > set that on subsequent requests.
> >
> > yes, I do mean HttpSession. A soap client would have to support cookies or
> url
> > rewriting to take advantage of the session id. But most of this is
> automatic from the
> > perspective of the servlet, which can do a getSession(). If the client has
> managed the
> > sessionId properly, the servlet engine will pull it from the request, look
> up the session
> > context and make it avaliable to the servlet. I may not have the exact
> details, but the main idea
> > is that a servlet can usually get a session context, into which it can
> store and retrieve
> > data relevant to a given sessionId or client.
> >
> > So, the rpcrouter is a servlet (essentially), and it has access to the
> session, servlet context,
> > request, response, etc. It's main job is to decode the soap call, map it
> to a provider
> > object, and invoke the appropriate method (with parms) on the provider
> object.
> >
> > The provider object is not a servlet, or at least it doesn't act like one.
> Even though
> > it executes in the same thread as the rpcrouter servlet, it does not have
> access to the
> > servlet data, mentioned above.
> >
> > My question is why couldn't the provider object be handed the servlet's
> session
> > because it too might need to manage things relative to a particular
> sessionId.
> >
> > > [snip]
> > >
> > > >What if there was an interface, ie., iSoapService, that all provider
> classes implemented.
> > > >The interface would allow the rpcrouter to set some
> > > >useful servlet related data, ie., the session, on the provider before
> > > >invoking the method call.
> > >
> > > >public interface iSoapService
> > > >{
> > > > public void setSession( Session s );
> > > > // maybe others... ??
> > > >}
> > >
> > > The drawback of that approach is that you're forcing the target provider
> class to
> > > implement your provider interface, making deployment of SOAP services
> less seamless
> > > than it is today.
> >
> > I'll buy that. So we could have the rpcrouter relfect the provider class
> and if the
> > iSoapService interface is present, the setSession(...) method will be
> called on it
> > sometime prior to the invoke. I might be thinking about this the wrong way
> but
> > it seems to me that there is a better than equal chance that the provider
> class is
> > a new piece of code, probably functioning as a proxy that delgates to the
> real
> > app service, ie., a remote ejb, or whatever. In such a case, having to
> implement
> > an interface is not a bother.
> >
> > >
> > >
> > > >The only other approach I've found to accomplish this is to insert
> MyServlet
> > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > >and stores the session so that downstream my provider class can get the
> > > >session. MyServlet then calls RequestDispatcher method include() on
> rpcrouter
> > > >to let the soap call
> > > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > > >removes the session from the cache.
> > >
> > > That current thread kludge sounds familiar (I implemented multipart mime
> that way). :-)
> > > Once again, the drawback is that the service provider class has to be
> familiar with the
> > > session context concept.
> >
> > Yep, if it needs the session, it would be willing to pay for it.
> >
> > >
> > > [snip]
> >
> > >
> > > One danger is that they may be unrelated and
> > > interfere with eachother if the session context is simple, e.g. key
> string/value object pairs
> > > in the HttpSession, where the keys are not necessarily unique across
> independently
> > > developed providers. The client should also be able to specify the
> session to handle
> > > multiple simultaneous sessions.
> >
> > I'm not sure I'm following here. I'm naivley thinking that I can use the
> current thread to
> > derive some sort of unique key to store the session object. The provider
> objecet, which
> > is essentially an extension of the executing servlet group, is exectuing
> in the same
> > thread, thus it will use the same key to fetch the session object that
> was used to
> > store it and given that, there should be no conflict with session content.
> So it looks like this:
> >
> > store/remove +--------------+ get session
> > +--------------> | session cache |<-------------+
> > | +--------------+
> |
> > ---> myServlet ---->rpcrouter------------------->provider
> > <----------------------------------------------------+
> >
> > >
> > >
> > > Now, this is how I understand the current lifecycle management. A
> session can only be
> > > maintained for a single provider class. The deployment descriptor
> indicates a session
> > > scope. When first called, the servlet/JSP creates a new HttpSession,
> instantiates an
> > > object of the provider class and stores the object in the HttpSession
> with the service's ID
> > > (urn) as a key. The target method is invoked, the response is returned
> along with a
> > > session cookie in the header. If the client calls again with the session
> cookie set, the
> > > same object, with the same instance variables, is pulled from the
> HttpSession and a
> > > method invoked on it. The provider object's life ends when the session
> times out (maybe
> > > the timeout value can be set by the client in some way).
> >
> > I was under the impression that there was only one instance of a provider
> and that it
> > should be thread safe. If there is a new instance of the provider for
> every HttpSession,
> > then the provider itself could be used to store provider-specific session
> data.
> >
> > How does this map to the scope specifier in the deployment descriptor? If
> 'application'
> > is specified, does the provider class instance get stored in the 'servlet
> context' and if
> > the scope is specified as 'session' is the provider class instance stored
> in the
> > 'servlet session'?
> >
> > Could someone clarify this please?
> >
> > >
> > > If you need multiple services to share a single session context, then
> make the one
> > > provider class a facade for them, implementing all the method calls. It
> could call the
> > > target classes with a reference to "this" so they can get to the
> instance variables
> > > corresponding to the session context, or it could keep a reference to
> all objects of other
> > > classes used, or simply pass variables and store return values etc.
> > >
> > > Somebody correct me if I'm full of it?
> >
> > whether you got all the details right or not, I appreciate the time you've
> taken to further
> > this discussion.
> >
> > >
> > >
> > > bfn, Wouter
> > > --
> > > http://www.workspot.net/~zombie/soap/
> > > My opinions are irrelevant. They will be assimilated by my employer.
> >
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Do you mean subclass rpcrouter.jsp? If so, I thought of that, but first of
all, I'm still waiting for the servlet implementation of rpcrouter. Secondly,
I don't want to have to make mods to my derivation on every release of
the soap layer.
Moreover, I'd prefer it be standard behavior in the soap layer. I like the idea
of a standard layer. Although, I've been tempted serveral times to implement
my own app specific soap layer, such that it would be optimized for exactly
what I need, but the benefits of a standard layer are compelling.
Cory Isaacson wrote:
> Just out of curiosity, couldn't you just subclass the SOAP servlet and
> client classes and do this as a simple wrapper? I would think it would be
> very easy, but I'm not sure about the instance problem you mentioned. It
> seems like the session object could just be retrieved for each SOAP call and
> made available to the provider without getting in the way of anything else.
> I did something similar in another application I made and it worked fine.
>
> Cory
> ----- Original Message -----
> From: "Rich Johns" <rj...@vignette.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, August 08, 2000 10:31 AM
> Subject: Re: Soap Provider classes need access to servlet data
>
> >
> >
> > Wouter Cloetens wrote:
> >
> > > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> > >
> > > >It would be nice if a provider could have, say the HTTPSession,
> > > >so that it could cache session related data in it and let the servlet
> > > >engine manage the session.
> > >
> > > By HTTPSession you mean an HttpSession, identified by a session id in a
> cookie?
> > > SOAP clients could then read the new session cookie returned by the
> initial request and
> > > set that on subsequent requests.
> >
> > yes, I do mean HttpSession. A soap client would have to support cookies or
> url
> > rewriting to take advantage of the session id. But most of this is
> automatic from the
> > perspective of the servlet, which can do a getSession(). If the client has
> managed the
> > sessionId properly, the servlet engine will pull it from the request, look
> up the session
> > context and make it avaliable to the servlet. I may not have the exact
> details, but the main idea
> > is that a servlet can usually get a session context, into which it can
> store and retrieve
> > data relevant to a given sessionId or client.
> >
> > So, the rpcrouter is a servlet (essentially), and it has access to the
> session, servlet context,
> > request, response, etc. It's main job is to decode the soap call, map it
> to a provider
> > object, and invoke the appropriate method (with parms) on the provider
> object.
> >
> > The provider object is not a servlet, or at least it doesn't act like one.
> Even though
> > it executes in the same thread as the rpcrouter servlet, it does not have
> access to the
> > servlet data, mentioned above.
> >
> > My question is why couldn't the provider object be handed the servlet's
> session
> > because it too might need to manage things relative to a particular
> sessionId.
> >
> > > [snip]
> > >
> > > >What if there was an interface, ie., iSoapService, that all provider
> classes implemented.
> > > >The interface would allow the rpcrouter to set some
> > > >useful servlet related data, ie., the session, on the provider before
> > > >invoking the method call.
> > >
> > > >public interface iSoapService
> > > >{
> > > > public void setSession( Session s );
> > > > // maybe others... ??
> > > >}
> > >
> > > The drawback of that approach is that you're forcing the target provider
> class to
> > > implement your provider interface, making deployment of SOAP services
> less seamless
> > > than it is today.
> >
> > I'll buy that. So we could have the rpcrouter relfect the provider class
> and if the
> > iSoapService interface is present, the setSession(...) method will be
> called on it
> > sometime prior to the invoke. I might be thinking about this the wrong way
> but
> > it seems to me that there is a better than equal chance that the provider
> class is
> > a new piece of code, probably functioning as a proxy that delgates to the
> real
> > app service, ie., a remote ejb, or whatever. In such a case, having to
> implement
> > an interface is not a bother.
> >
> > >
> > >
> > > >The only other approach I've found to accomplish this is to insert
> MyServlet
> > > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > > >and stores the session so that downstream my provider class can get the
> > > >session. MyServlet then calls RequestDispatcher method include() on
> rpcrouter
> > > >to let the soap call
> > > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > > >removes the session from the cache.
> > >
> > > That current thread kludge sounds familiar (I implemented multipart mime
> that way). :-)
> > > Once again, the drawback is that the service provider class has to be
> familiar with the
> > > session context concept.
> >
> > Yep, if it needs the session, it would be willing to pay for it.
> >
> > >
> > > [snip]
> >
> > >
> > > One danger is that they may be unrelated and
> > > interfere with eachother if the session context is simple, e.g. key
> string/value object pairs
> > > in the HttpSession, where the keys are not necessarily unique across
> independently
> > > developed providers. The client should also be able to specify the
> session to handle
> > > multiple simultaneous sessions.
> >
> > I'm not sure I'm following here. I'm naivley thinking that I can use the
> current thread to
> > derive some sort of unique key to store the session object. The provider
> objecet, which
> > is essentially an extension of the executing servlet group, is exectuing
> in the same
> > thread, thus it will use the same key to fetch the session object that
> was used to
> > store it and given that, there should be no conflict with session content.
> So it looks like this:
> >
> > store/remove +--------------+ get session
> > +--------------> | session cache |<-------------+
> > | +--------------+
> |
> > ---> myServlet ---->rpcrouter------------------->provider
> > <----------------------------------------------------+
> >
> > >
> > >
> > > Now, this is how I understand the current lifecycle management. A
> session can only be
> > > maintained for a single provider class. The deployment descriptor
> indicates a session
> > > scope. When first called, the servlet/JSP creates a new HttpSession,
> instantiates an
> > > object of the provider class and stores the object in the HttpSession
> with the service's ID
> > > (urn) as a key. The target method is invoked, the response is returned
> along with a
> > > session cookie in the header. If the client calls again with the session
> cookie set, the
> > > same object, with the same instance variables, is pulled from the
> HttpSession and a
> > > method invoked on it. The provider object's life ends when the session
> times out (maybe
> > > the timeout value can be set by the client in some way).
> >
> > I was under the impression that there was only one instance of a provider
> and that it
> > should be thread safe. If there is a new instance of the provider for
> every HttpSession,
> > then the provider itself could be used to store provider-specific session
> data.
> >
> > How does this map to the scope specifier in the deployment descriptor? If
> 'application'
> > is specified, does the provider class instance get stored in the 'servlet
> context' and if
> > the scope is specified as 'session' is the provider class instance stored
> in the
> > 'servlet session'?
> >
> > Could someone clarify this please?
> >
> > >
> > > If you need multiple services to share a single session context, then
> make the one
> > > provider class a facade for them, implementing all the method calls. It
> could call the
> > > target classes with a reference to "this" so they can get to the
> instance variables
> > > corresponding to the session context, or it could keep a reference to
> all objects of other
> > > classes used, or simply pass variables and store return values etc.
> > >
> > > Somebody correct me if I'm full of it?
> >
> > whether you got all the details right or not, I appreciate the time you've
> taken to further
> > this discussion.
> >
> > >
> > >
> > > bfn, Wouter
> > > --
> > > http://www.workspot.net/~zombie/soap/
> > > My opinions are irrelevant. They will be assimilated by my employer.
> >
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
Just out of curiosity, couldn't you just subclass the SOAP servlet and
client classes and do this as a simple wrapper? I would think it would be
very easy, but I'm not sure about the instance problem you mentioned. It
seems like the session object could just be retrieved for each SOAP call and
made available to the provider without getting in the way of anything else.
I did something similar in another application I made and it worked fine.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 10:31 AM
Subject: Re: Soap Provider classes need access to servlet data
>
>
> Wouter Cloetens wrote:
>
> > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> >
> > >It would be nice if a provider could have, say the HTTPSession,
> > >so that it could cache session related data in it and let the servlet
> > >engine manage the session.
> >
> > By HTTPSession you mean an HttpSession, identified by a session id in a
cookie?
> > SOAP clients could then read the new session cookie returned by the
initial request and
> > set that on subsequent requests.
>
> yes, I do mean HttpSession. A soap client would have to support cookies or
url
> rewriting to take advantage of the session id. But most of this is
automatic from the
> perspective of the servlet, which can do a getSession(). If the client has
managed the
> sessionId properly, the servlet engine will pull it from the request, look
up the session
> context and make it avaliable to the servlet. I may not have the exact
details, but the main idea
> is that a servlet can usually get a session context, into which it can
store and retrieve
> data relevant to a given sessionId or client.
>
> So, the rpcrouter is a servlet (essentially), and it has access to the
session, servlet context,
> request, response, etc. It's main job is to decode the soap call, map it
to a provider
> object, and invoke the appropriate method (with parms) on the provider
object.
>
> The provider object is not a servlet, or at least it doesn't act like one.
Even though
> it executes in the same thread as the rpcrouter servlet, it does not have
access to the
> servlet data, mentioned above.
>
> My question is why couldn't the provider object be handed the servlet's
session
> because it too might need to manage things relative to a particular
sessionId.
>
> > [snip]
> >
> > >What if there was an interface, ie., iSoapService, that all provider
classes implemented.
> > >The interface would allow the rpcrouter to set some
> > >useful servlet related data, ie., the session, on the provider before
> > >invoking the method call.
> >
> > >public interface iSoapService
> > >{
> > > public void setSession( Session s );
> > > // maybe others... ??
> > >}
> >
> > The drawback of that approach is that you're forcing the target provider
class to
> > implement your provider interface, making deployment of SOAP services
less seamless
> > than it is today.
>
> I'll buy that. So we could have the rpcrouter relfect the provider class
and if the
> iSoapService interface is present, the setSession(...) method will be
called on it
> sometime prior to the invoke. I might be thinking about this the wrong way
but
> it seems to me that there is a better than equal chance that the provider
class is
> a new piece of code, probably functioning as a proxy that delgates to the
real
> app service, ie., a remote ejb, or whatever. In such a case, having to
implement
> an interface is not a bother.
>
> >
> >
> > >The only other approach I've found to accomplish this is to insert
MyServlet
> > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > >and stores the session so that downstream my provider class can get the
> > >session. MyServlet then calls RequestDispatcher method include() on
rpcrouter
> > >to let the soap call
> > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > >removes the session from the cache.
> >
> > That current thread kludge sounds familiar (I implemented multipart mime
that way). :-)
> > Once again, the drawback is that the service provider class has to be
familiar with the
> > session context concept.
>
> Yep, if it needs the session, it would be willing to pay for it.
>
> >
> > [snip]
>
> >
> > One danger is that they may be unrelated and
> > interfere with eachother if the session context is simple, e.g. key
string/value object pairs
> > in the HttpSession, where the keys are not necessarily unique across
independently
> > developed providers. The client should also be able to specify the
session to handle
> > multiple simultaneous sessions.
>
> I'm not sure I'm following here. I'm naivley thinking that I can use the
current thread to
> derive some sort of unique key to store the session object. The provider
objecet, which
> is essentially an extension of the executing servlet group, is exectuing
in the same
> thread, thus it will use the same key to fetch the session object that
was used to
> store it and given that, there should be no conflict with session content.
So it looks like this:
>
> store/remove +--------------+ get session
> +--------------> | session cache |<-------------+
> | +--------------+
|
> ---> myServlet ---->rpcrouter------------------->provider
> <----------------------------------------------------+
>
> >
> >
> > Now, this is how I understand the current lifecycle management. A
session can only be
> > maintained for a single provider class. The deployment descriptor
indicates a session
> > scope. When first called, the servlet/JSP creates a new HttpSession,
instantiates an
> > object of the provider class and stores the object in the HttpSession
with the service's ID
> > (urn) as a key. The target method is invoked, the response is returned
along with a
> > session cookie in the header. If the client calls again with the session
cookie set, the
> > same object, with the same instance variables, is pulled from the
HttpSession and a
> > method invoked on it. The provider object's life ends when the session
times out (maybe
> > the timeout value can be set by the client in some way).
>
> I was under the impression that there was only one instance of a provider
and that it
> should be thread safe. If there is a new instance of the provider for
every HttpSession,
> then the provider itself could be used to store provider-specific session
data.
>
> How does this map to the scope specifier in the deployment descriptor? If
'application'
> is specified, does the provider class instance get stored in the 'servlet
context' and if
> the scope is specified as 'session' is the provider class instance stored
in the
> 'servlet session'?
>
> Could someone clarify this please?
>
> >
> > If you need multiple services to share a single session context, then
make the one
> > provider class a facade for them, implementing all the method calls. It
could call the
> > target classes with a reference to "this" so they can get to the
instance variables
> > corresponding to the session context, or it could keep a reference to
all objects of other
> > classes used, or simply pass variables and store return values etc.
> >
> > Somebody correct me if I'm full of it?
>
> whether you got all the details right or not, I appreciate the time you've
taken to further
> this discussion.
>
> >
> >
> > bfn, Wouter
> > --
> > http://www.workspot.net/~zombie/soap/
> > My opinions are irrelevant. They will be assimilated by my employer.
>
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Rich Johns wrote:
> > Now, this is how I understand the current lifecycle management. A session can only be
> > maintained for a single provider class. The deployment descriptor indicates a session
> > scope. When first called, the servlet/JSP creates a new HttpSession, instantiates an
> > object of the provider class and stores the object in the HttpSession with the service's ID
> > (urn) as a key. The target method is invoked, the response is returned along with a
> > session cookie in the header. If the client calls again with the session cookie set, the
> > same object, with the same instance variables, is pulled from the HttpSession and a
> > method invoked on it. The provider object's life ends when the session times out (maybe
> > the timeout value can be set by the client in some way).
>
> I was under the impression that there was only one instance of a provider and that it
> should be thread safe. If there is a new instance of the provider for every HttpSession,
> then the provider itself could be used to store provider-specific session data.
>
> How does this map to the scope specifier in the deployment descriptor? If 'application'
> is specified, does the provider class instance get stored in the 'servlet context' and if
> the scope is specified as 'session' is the provider class instance stored in the
> 'servlet session'?
>
> Could someone clarify this please?
I'll answer my own question. For the ibm-soap version, (not sure what the latest apache
version does) the provier class instance is stored in the servlet context which means that
there is one instance of a provider for all requests. At least the way I understand it.
So I guess at this point, the scope in the deployment descriptor is ignored -- and always,
no matter what it's set to, behaves like 'application'.
Can someone in the know elaborate on this topic and the future design plan for
provider class instancec scoping?
Thanks
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Rich Johns wrote:
> > Now, this is how I understand the current lifecycle management. A session can only be
> > maintained for a single provider class. The deployment descriptor indicates a session
> > scope. When first called, the servlet/JSP creates a new HttpSession, instantiates an
> > object of the provider class and stores the object in the HttpSession with the service's ID
> > (urn) as a key. The target method is invoked, the response is returned along with a
> > session cookie in the header. If the client calls again with the session cookie set, the
> > same object, with the same instance variables, is pulled from the HttpSession and a
> > method invoked on it. The provider object's life ends when the session times out (maybe
> > the timeout value can be set by the client in some way).
>
> I was under the impression that there was only one instance of a provider and that it
> should be thread safe. If there is a new instance of the provider for every HttpSession,
> then the provider itself could be used to store provider-specific session data.
>
> How does this map to the scope specifier in the deployment descriptor? If 'application'
> is specified, does the provider class instance get stored in the 'servlet context' and if
> the scope is specified as 'session' is the provider class instance stored in the
> 'servlet session'?
>
> Could someone clarify this please?
I'll answer my own question. For the ibm-soap version, (not sure what the latest apache
version does) the provier class instance is stored in the servlet context which means that
there is one instance of a provider for all requests. At least the way I understand it.
So I guess at this point, the scope in the deployment descriptor is ignored -- and always,
no matter what it's set to, behaves like 'application'.
Can someone in the know elaborate on this topic and the future design plan for
provider class instancec scoping?
Thanks
Re: Soap Provider classes need access to servlet data
Posted by Cory Isaacson <ci...@capita2.com>.
Just out of curiosity, couldn't you just subclass the SOAP servlet and
client classes and do this as a simple wrapper? I would think it would be
very easy, but I'm not sure about the instance problem you mentioned. It
seems like the session object could just be retrieved for each SOAP call and
made available to the provider without getting in the way of anything else.
I did something similar in another application I made and it worked fine.
Cory
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
To: <so...@xml.apache.org>
Sent: Tuesday, August 08, 2000 10:31 AM
Subject: Re: Soap Provider classes need access to servlet data
>
>
> Wouter Cloetens wrote:
>
> > On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
> >
> > >It would be nice if a provider could have, say the HTTPSession,
> > >so that it could cache session related data in it and let the servlet
> > >engine manage the session.
> >
> > By HTTPSession you mean an HttpSession, identified by a session id in a
cookie?
> > SOAP clients could then read the new session cookie returned by the
initial request and
> > set that on subsequent requests.
>
> yes, I do mean HttpSession. A soap client would have to support cookies or
url
> rewriting to take advantage of the session id. But most of this is
automatic from the
> perspective of the servlet, which can do a getSession(). If the client has
managed the
> sessionId properly, the servlet engine will pull it from the request, look
up the session
> context and make it avaliable to the servlet. I may not have the exact
details, but the main idea
> is that a servlet can usually get a session context, into which it can
store and retrieve
> data relevant to a given sessionId or client.
>
> So, the rpcrouter is a servlet (essentially), and it has access to the
session, servlet context,
> request, response, etc. It's main job is to decode the soap call, map it
to a provider
> object, and invoke the appropriate method (with parms) on the provider
object.
>
> The provider object is not a servlet, or at least it doesn't act like one.
Even though
> it executes in the same thread as the rpcrouter servlet, it does not have
access to the
> servlet data, mentioned above.
>
> My question is why couldn't the provider object be handed the servlet's
session
> because it too might need to manage things relative to a particular
sessionId.
>
> > [snip]
> >
> > >What if there was an interface, ie., iSoapService, that all provider
classes implemented.
> > >The interface would allow the rpcrouter to set some
> > >useful servlet related data, ie., the session, on the provider before
> > >invoking the method call.
> >
> > >public interface iSoapService
> > >{
> > > public void setSession( Session s );
> > > // maybe others... ??
> > >}
> >
> > The drawback of that approach is that you're forcing the target provider
class to
> > implement your provider interface, making deployment of SOAP services
less seamless
> > than it is today.
>
> I'll buy that. So we could have the rpcrouter relfect the provider class
and if the
> iSoapService interface is present, the setSession(...) method will be
called on it
> sometime prior to the invoke. I might be thinking about this the wrong way
but
> it seems to me that there is a better than equal chance that the provider
class is
> a new piece of code, probably functioning as a proxy that delgates to the
real
> app service, ie., a remote ejb, or whatever. In such a case, having to
implement
> an interface is not a bother.
>
> >
> >
> > >The only other approach I've found to accomplish this is to insert
MyServlet
> > >in front of rpcrouter. MyServlet uses the currentThread as a key
> > >and stores the session so that downstream my provider class can get the
> > >session. MyServlet then calls RequestDispatcher method include() on
rpcrouter
> > >to let the soap call
> > >complete. Then, when rpcrouter returns from the include(), MyServlet
> > >removes the session from the cache.
> >
> > That current thread kludge sounds familiar (I implemented multipart mime
that way). :-)
> > Once again, the drawback is that the service provider class has to be
familiar with the
> > session context concept.
>
> Yep, if it needs the session, it would be willing to pay for it.
>
> >
> > [snip]
>
> >
> > One danger is that they may be unrelated and
> > interfere with eachother if the session context is simple, e.g. key
string/value object pairs
> > in the HttpSession, where the keys are not necessarily unique across
independently
> > developed providers. The client should also be able to specify the
session to handle
> > multiple simultaneous sessions.
>
> I'm not sure I'm following here. I'm naivley thinking that I can use the
current thread to
> derive some sort of unique key to store the session object. The provider
objecet, which
> is essentially an extension of the executing servlet group, is exectuing
in the same
> thread, thus it will use the same key to fetch the session object that
was used to
> store it and given that, there should be no conflict with session content.
So it looks like this:
>
> store/remove +--------------+ get session
> +--------------> | session cache |<-------------+
> | +--------------+
|
> ---> myServlet ---->rpcrouter------------------->provider
> <----------------------------------------------------+
>
> >
> >
> > Now, this is how I understand the current lifecycle management. A
session can only be
> > maintained for a single provider class. The deployment descriptor
indicates a session
> > scope. When first called, the servlet/JSP creates a new HttpSession,
instantiates an
> > object of the provider class and stores the object in the HttpSession
with the service's ID
> > (urn) as a key. The target method is invoked, the response is returned
along with a
> > session cookie in the header. If the client calls again with the session
cookie set, the
> > same object, with the same instance variables, is pulled from the
HttpSession and a
> > method invoked on it. The provider object's life ends when the session
times out (maybe
> > the timeout value can be set by the client in some way).
>
> I was under the impression that there was only one instance of a provider
and that it
> should be thread safe. If there is a new instance of the provider for
every HttpSession,
> then the provider itself could be used to store provider-specific session
data.
>
> How does this map to the scope specifier in the deployment descriptor? If
'application'
> is specified, does the provider class instance get stored in the 'servlet
context' and if
> the scope is specified as 'session' is the provider class instance stored
in the
> 'servlet session'?
>
> Could someone clarify this please?
>
> >
> > If you need multiple services to share a single session context, then
make the one
> > provider class a facade for them, implementing all the method calls. It
could call the
> > target classes with a reference to "this" so they can get to the
instance variables
> > corresponding to the session context, or it could keep a reference to
all objects of other
> > classes used, or simply pass variables and store return values etc.
> >
> > Somebody correct me if I'm full of it?
>
> whether you got all the details right or not, I appreciate the time you've
taken to further
> this discussion.
>
> >
> >
> > bfn, Wouter
> > --
> > http://www.workspot.net/~zombie/soap/
> > My opinions are irrelevant. They will be assimilated by my employer.
>
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Wouter Cloetens wrote:
> On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
>
> >It would be nice if a provider could have, say the HTTPSession,
> >so that it could cache session related data in it and let the servlet
> >engine manage the session.
>
> By HTTPSession you mean an HttpSession, identified by a session id in a cookie?
> SOAP clients could then read the new session cookie returned by the initial request and
> set that on subsequent requests.
yes, I do mean HttpSession. A soap client would have to support cookies or url
rewriting to take advantage of the session id. But most of this is automatic from the
perspective of the servlet, which can do a getSession(). If the client has managed the
sessionId properly, the servlet engine will pull it from the request, look up the session
context and make it avaliable to the servlet. I may not have the exact details, but the main idea
is that a servlet can usually get a session context, into which it can store and retrieve
data relevant to a given sessionId or client.
So, the rpcrouter is a servlet (essentially), and it has access to the session, servlet context,
request, response, etc. It's main job is to decode the soap call, map it to a provider
object, and invoke the appropriate method (with parms) on the provider object.
The provider object is not a servlet, or at least it doesn't act like one. Even though
it executes in the same thread as the rpcrouter servlet, it does not have access to the
servlet data, mentioned above.
My question is why couldn't the provider object be handed the servlet's session
because it too might need to manage things relative to a particular sessionId.
> [snip]
>
> >What if there was an interface, ie., iSoapService, that all provider classes implemented.
> >The interface would allow the rpcrouter to set some
> >useful servlet related data, ie., the session, on the provider before
> >invoking the method call.
>
> >public interface iSoapService
> >{
> > public void setSession( Session s );
> > // maybe others... ??
> >}
>
> The drawback of that approach is that you're forcing the target provider class to
> implement your provider interface, making deployment of SOAP services less seamless
> than it is today.
I'll buy that. So we could have the rpcrouter relfect the provider class and if the
iSoapService interface is present, the setSession(...) method will be called on it
sometime prior to the invoke. I might be thinking about this the wrong way but
it seems to me that there is a better than equal chance that the provider class is
a new piece of code, probably functioning as a proxy that delgates to the real
app service, ie., a remote ejb, or whatever. In such a case, having to implement
an interface is not a bother.
>
>
> >The only other approach I've found to accomplish this is to insert MyServlet
> >in front of rpcrouter. MyServlet uses the currentThread as a key
> >and stores the session so that downstream my provider class can get the
> >session. MyServlet then calls RequestDispatcher method include() on rpcrouter
> >to let the soap call
> >complete. Then, when rpcrouter returns from the include(), MyServlet
> >removes the session from the cache.
>
> That current thread kludge sounds familiar (I implemented multipart mime that way). :-)
> Once again, the drawback is that the service provider class has to be familiar with the
> session context concept.
Yep, if it needs the session, it would be willing to pay for it.
>
> [snip]
>
> One danger is that they may be unrelated and
> interfere with eachother if the session context is simple, e.g. key string/value object pairs
> in the HttpSession, where the keys are not necessarily unique across independently
> developed providers. The client should also be able to specify the session to handle
> multiple simultaneous sessions.
I'm not sure I'm following here. I'm naivley thinking that I can use the current thread to
derive some sort of unique key to store the session object. The provider objecet, which
is essentially an extension of the executing servlet group, is exectuing in the same
thread, thus it will use the same key to fetch the session object that was used to
store it and given that, there should be no conflict with session content. So it looks like this:
store/remove +--------------+ get session
+--------------> | session cache |<-------------+
| +--------------+ |
---> myServlet ---->rpcrouter------------------->provider
<----------------------------------------------------+
>
>
> Now, this is how I understand the current lifecycle management. A session can only be
> maintained for a single provider class. The deployment descriptor indicates a session
> scope. When first called, the servlet/JSP creates a new HttpSession, instantiates an
> object of the provider class and stores the object in the HttpSession with the service's ID
> (urn) as a key. The target method is invoked, the response is returned along with a
> session cookie in the header. If the client calls again with the session cookie set, the
> same object, with the same instance variables, is pulled from the HttpSession and a
> method invoked on it. The provider object's life ends when the session times out (maybe
> the timeout value can be set by the client in some way).
I was under the impression that there was only one instance of a provider and that it
should be thread safe. If there is a new instance of the provider for every HttpSession,
then the provider itself could be used to store provider-specific session data.
How does this map to the scope specifier in the deployment descriptor? If 'application'
is specified, does the provider class instance get stored in the 'servlet context' and if
the scope is specified as 'session' is the provider class instance stored in the
'servlet session'?
Could someone clarify this please?
>
> If you need multiple services to share a single session context, then make the one
> provider class a facade for them, implementing all the method calls. It could call the
> target classes with a reference to "this" so they can get to the instance variables
> corresponding to the session context, or it could keep a reference to all objects of other
> classes used, or simply pass variables and store return values etc.
>
> Somebody correct me if I'm full of it?
whether you got all the details right or not, I appreciate the time you've taken to further
this discussion.
>
>
> bfn, Wouter
> --
> http://www.workspot.net/~zombie/soap/
> My opinions are irrelevant. They will be assimilated by my employer.
Re: Soap Provider classes need access to servlet data
Posted by Rich Johns <rj...@vignette.com>.
Wouter Cloetens wrote:
> On Mon, 07 Aug 2000 19:00:56 -0500, Rich Johns wrote:
>
> >It would be nice if a provider could have, say the HTTPSession,
> >so that it could cache session related data in it and let the servlet
> >engine manage the session.
>
> By HTTPSession you mean an HttpSession, identified by a session id in a cookie?
> SOAP clients could then read the new session cookie returned by the initial request and
> set that on subsequent requests.
yes, I do mean HttpSession. A soap client would have to support cookies or url
rewriting to take advantage of the session id. But most of this is automatic from the
perspective of the servlet, which can do a getSession(). If the client has managed the
sessionId properly, the servlet engine will pull it from the request, look up the session
context and make it avaliable to the servlet. I may not have the exact details, but the main idea
is that a servlet can usually get a session context, into which it can store and retrieve
data relevant to a given sessionId or client.
So, the rpcrouter is a servlet (essentially), and it has access to the session, servlet context,
request, response, etc. It's main job is to decode the soap call, map it to a provider
object, and invoke the appropriate method (with parms) on the provider object.
The provider object is not a servlet, or at least it doesn't act like one. Even though
it executes in the same thread as the rpcrouter servlet, it does not have access to the
servlet data, mentioned above.
My question is why couldn't the provider object be handed the servlet's session
because it too might need to manage things relative to a particular sessionId.
> [snip]
>
> >What if there was an interface, ie., iSoapService, that all provider classes implemented.
> >The interface would allow the rpcrouter to set some
> >useful servlet related data, ie., the session, on the provider before
> >invoking the method call.
>
> >public interface iSoapService
> >{
> > public void setSession( Session s );
> > // maybe others... ??
> >}
>
> The drawback of that approach is that you're forcing the target provider class to
> implement your provider interface, making deployment of SOAP services less seamless
> than it is today.
I'll buy that. So we could have the rpcrouter relfect the provider class and if the
iSoapService interface is present, the setSession(...) method will be called on it
sometime prior to the invoke. I might be thinking about this the wrong way but
it seems to me that there is a better than equal chance that the provider class is
a new piece of code, probably functioning as a proxy that delgates to the real
app service, ie., a remote ejb, or whatever. In such a case, having to implement
an interface is not a bother.
>
>
> >The only other approach I've found to accomplish this is to insert MyServlet
> >in front of rpcrouter. MyServlet uses the currentThread as a key
> >and stores the session so that downstream my provider class can get the
> >session. MyServlet then calls RequestDispatcher method include() on rpcrouter
> >to let the soap call
> >complete. Then, when rpcrouter returns from the include(), MyServlet
> >removes the session from the cache.
>
> That current thread kludge sounds familiar (I implemented multipart mime that way). :-)
> Once again, the drawback is that the service provider class has to be familiar with the
> session context concept.
Yep, if it needs the session, it would be willing to pay for it.
>
> [snip]
>
> One danger is that they may be unrelated and
> interfere with eachother if the session context is simple, e.g. key string/value object pairs
> in the HttpSession, where the keys are not necessarily unique across independently
> developed providers. The client should also be able to specify the session to handle
> multiple simultaneous sessions.
I'm not sure I'm following here. I'm naivley thinking that I can use the current thread to
derive some sort of unique key to store the session object. The provider objecet, which
is essentially an extension of the executing servlet group, is exectuing in the same
thread, thus it will use the same key to fetch the session object that was used to
store it and given that, there should be no conflict with session content. So it looks like this:
store/remove +--------------+ get session
+--------------> | session cache |<-------------+
| +--------------+ |
---> myServlet ---->rpcrouter------------------->provider
<----------------------------------------------------+
>
>
> Now, this is how I understand the current lifecycle management. A session can only be
> maintained for a single provider class. The deployment descriptor indicates a session
> scope. When first called, the servlet/JSP creates a new HttpSession, instantiates an
> object of the provider class and stores the object in the HttpSession with the service's ID
> (urn) as a key. The target method is invoked, the response is returned along with a
> session cookie in the header. If the client calls again with the session cookie set, the
> same object, with the same instance variables, is pulled from the HttpSession and a
> method invoked on it. The provider object's life ends when the session times out (maybe
> the timeout value can be set by the client in some way).
I was under the impression that there was only one instance of a provider and that it
should be thread safe. If there is a new instance of the provider for every HttpSession,
then the provider itself could be used to store provider-specific session data.
How does this map to the scope specifier in the deployment descriptor? If 'application'
is specified, does the provider class instance get stored in the 'servlet context' and if
the scope is specified as 'session' is the provider class instance stored in the
'servlet session'?
Could someone clarify this please?
>
> If you need multiple services to share a single session context, then make the one
> provider class a facade for them, implementing all the method calls. It could call the
> target classes with a reference to "this" so they can get to the instance variables
> corresponding to the session context, or it could keep a reference to all objects of other
> classes used, or simply pass variables and store return values etc.
>
> Somebody correct me if I'm full of it?
whether you got all the details right or not, I appreciate the time you've taken to further
this discussion.
>
>
> bfn, Wouter
> --
> http://www.workspot.net/~zombie/soap/
> My opinions are irrelevant. They will be assimilated by my employer.