You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by ph...@omniresources.com on 2001/05/12 15:32:25 UTC
Accessing the soap context in RPC request
My question could just as easily be, how do I mix document oriented requests
with rpc requests AND take advantage of some state preservation in the HTTP
session.
It seems to me that the rpc mechanism would always have to be stateless,
unless I have missed something. Even if I used basic auththentication, it
seems that with rpc I have no way to do anything based on the users
credentials, user role etc.. Being able to maintain a user object instance
with user attributes available seems equally impossible. I'm hoping
somebody can shed some light.
I have also been able to work with the message or document oriented
requests. In this scenario, it would still be much better to have a way to
identify a user once, in a secure way and then use that information for
subsequent calls.
FYI, what I am doing is taking a web based application which has lots of
fairly large requests (form data with 20-100 fields per request) and trying
to turn it into a web service. There seems to be some paradigm subtleties
that I am missing.
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Accessing the soap context in RPC request
Posted by Michael Hudson <mh...@blueprinttech.com>.
Hi Philip,
Seems that Nirmal answered some of my questions as well on how the back-end
session stuff works.
In my own experience (as a user, I'm not an Apache developer), I was able to
successfully deploy Apache SOAP 2.1 (nightly build 5/9) against a stateful
session EJB and perserve the EJB's state between multiple calls. It seems the
server-side of things keeps an the instance of the EJB around throughout the
session, and it tags the end of the target object URI with a '@' sign followed
by a unique key. The first response comes back with that new target object URI,
which you can then use to continually target that same instance of that EJB...
within the context that you are using the same HTTPSession object between calls
as well.
Essentially, what I did was this... I already had my stateful session bean... I
wrote a deployment descriptor with "session" scope, user-defined provider with
it pointing to the Apache SOAP's StatefulEJB Provider class, and all the
necessary home/create interface information for invoking the EJB. I used the
'ejb' sample in the sample directory as the model for my deployment descriptor.
When I wrote the client code, I used the same Call object between calls, and
walla... it worked pretty seamlessly. I used the Envelope's marshall method to
actually see the actual SOAP XML, and that's where I saw the extra key being
added to the target object URI (well that and perusing through the code as
well).
If you'd like to see my deployment descriptor or more details about this
experience, don't hesitate to ask.
-Michael
---------------------------------
Michael J. Hudson
Software/Framework Engineer
mhudson@blueprinttech.com
cell-phone: 703.362.8039
fax: 703.734.0987
Blueprint Technologies
"The E-Solution Architect"
http://www.blueprinttech.com
philip.nelson@omniresources.com wrote:
> My question could just as easily be, how do I mix document oriented requests
> with rpc requests AND take advantage of some state preservation in the HTTP
> session.
>
> It seems to me that the rpc mechanism would always have to be stateless,
> unless I have missed something. Even if I used basic auththentication, it
> seems that with rpc I have no way to do anything based on the users
> credentials, user role etc.. Being able to maintain a user object instance
> with user attributes available seems equally impossible. I'm hoping
> somebody can shed some light.
>
> I have also been able to work with the message or document oriented
> requests. In this scenario, it would still be much better to have a way to
> identify a user once, in a secure way and then use that information for
> subsequent calls.
>
> FYI, what I am doing is taking a web based application which has lots of
> fairly large requests (form data with 20-100 fields per request) and trying
> to turn it into a web service. There seems to be some paradigm subtleties
> that I am missing.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
--
---------------------------------
Michael J. Hudson
Software/Framework Engineer
mhudson@blueprinttech.com
cell-phone: 703.362.8039
voice mail: 703.827.0638 ext. 4786
fax: 703.734.0987
Blueprint Technologies
"The E-Solution Architect"
http://www.blueprinttech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Accessing the soap context in RPC request
Posted by Michael Hudson <mh...@blueprinttech.com>.
Hi Philip,
Seems that Nirmal answered some of my questions as well on how the back-end
session stuff works.
In my own experience (as a user, I'm not an Apache developer), I was able to
successfully deploy Apache SOAP 2.1 (nightly build 5/9) against a stateful
session EJB and perserve the EJB's state between multiple calls. It seems the
server-side of things keeps an the instance of the EJB around throughout the
session, and it tags the end of the target object URI with a '@' sign followed
by a unique key. The first response comes back with that new target object URI,
which you can then use to continually target that same instance of that EJB...
within the context that you are using the same HTTPSession object between calls
as well.
Essentially, what I did was this... I already had my stateful session bean... I
wrote a deployment descriptor with "session" scope, user-defined provider with
it pointing to the Apache SOAP's StatefulEJB Provider class, and all the
necessary home/create interface information for invoking the EJB. I used the
'ejb' sample in the sample directory as the model for my deployment descriptor.
When I wrote the client code, I used the same Call object between calls, and
walla... it worked pretty seamlessly. I used the Envelope's marshall method to
actually see the actual SOAP XML, and that's where I saw the extra key being
added to the target object URI (well that and perusing through the code as
well).
If you'd like to see my deployment descriptor or more details about this
experience, don't hesitate to ask.
-Michael
---------------------------------
Michael J. Hudson
Software/Framework Engineer
mhudson@blueprinttech.com
cell-phone: 703.362.8039
fax: 703.734.0987
Blueprint Technologies
"The E-Solution Architect"
http://www.blueprinttech.com
philip.nelson@omniresources.com wrote:
> My question could just as easily be, how do I mix document oriented requests
> with rpc requests AND take advantage of some state preservation in the HTTP
> session.
>
> It seems to me that the rpc mechanism would always have to be stateless,
> unless I have missed something. Even if I used basic auththentication, it
> seems that with rpc I have no way to do anything based on the users
> credentials, user role etc.. Being able to maintain a user object instance
> with user attributes available seems equally impossible. I'm hoping
> somebody can shed some light.
>
> I have also been able to work with the message or document oriented
> requests. In this scenario, it would still be much better to have a way to
> identify a user once, in a secure way and then use that information for
> subsequent calls.
>
> FYI, what I am doing is taking a web based application which has lots of
> fairly large requests (form data with 20-100 fields per request) and trying
> to turn it into a web service. There seems to be some paradigm subtleties
> that I am missing.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
--
---------------------------------
Michael J. Hudson
Software/Framework Engineer
mhudson@blueprinttech.com
cell-phone: 703.362.8039
voice mail: 703.827.0638 ext. 4786
fax: 703.734.0987
Blueprint Technologies
"The E-Solution Architect"
http://www.blueprinttech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org