wood burning stoves 2.0*
The moose likes Web Services and the fly likes jax-ws  same httpSession with different wsdls Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "jax-ws  same httpSession with different wsdls" Watch "jax-ws  same httpSession with different wsdls" New topic
Author

jax-ws same httpSession with different wsdls

Roland Maurer
Greenhorn

Joined: Nov 23, 2008
Posts: 17
hello,

I'm using a wsImport generated WsClient , if I use :
((BindingProvider) impl).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);

this service uses the same HttpSession for all further requests, but how can I parse this session information to another service instance ?

eg: I use loginService and later queryService both of them must share the same httpSession .

thank you in advance
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Welcome to JavaRanch Mauro,

Please check your private messages.


The information in the HTTP-Session is considered to be out-of-band of the SOAP protocol - therefore its use is strongly discouraged in interoperable SOAP web services. If you used WS-Security for your SOAP web service authentication needs (which communicates the security information in-band) your problem would probably go away.

SOAP web services should not rely on HTTP Session

Is the service that you are accessing owned by somebody else?
Do both services (the login and query service) use different endpoint addresses?
[ November 23, 2008: Message edited by: Peer Reynders ]
Roland Maurer
Greenhorn

Joined: Nov 23, 2008
Posts: 17
hello peer,

thank you for your reply !

I know that it is a bad idea to have a stateful ws service implementation !
I was porting a big JSF application to GWT, and now I should provide a WS interface for the same stuff.
A lot of the functionality is application and session based, we started to search a way around this dependency, but we are not finished at this time.

It is our own service.
Yes the services use different endpoint addresses, we have a lot of services and I don't like to have one big WSDL with hundreds of methods and dependencies to everywhere.
with one endpoint the SESSION_MAINTAIN_PROPERTY is working for me

The login was only an example, for login we use XUA ( http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Assertion_Profile ) what is based on SAML

have a nice evening
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Roland Maurer:
GWT, and now I should provide a WS interface for the same stuff


Have you considered that SOAP web services are not necessarily an optimal fit to support your particular requirements?

Based on the treatment in Maintaining Session With JAX-WS I would be surprised if client side manipulation of the http session was ever seen as a desirable feature. The service is the only one that needs to manipulate the HTTP session data - the client just needs to send back the same JSESSIONID it received in the last response - this keeps everything nice and transparent on the client side. Sharing the same out-of-band client state over multiple endpoints really isn't a use case that is supported by SOAP web services. SOAP web services may work over the web - but they certainly don't work like the web - that is the domain of RESTful HTTP web services which is probably why Project Zero uses them to support their client side JavaScript.
Roland Maurer
Greenhorn

Joined: Nov 23, 2008
Posts: 17
Originally posted by Peer Reynders:
[QB]

Have you considered that SOAP web services are not necessarily an optimal fit to support your particular requirements?

Yes ! But
I really like to get away from http session.
And the implementation we do is something like an "easy access layer" for a lot of different frontends ( we use GWT, others use JSF or maybe swing,.. ) to a really complex and big "standard community" ( http://www.ihe.net/ ) .
Behind the WS there are a lot of different network access methods used, like DCM or Hl7 uses TCP / IP directly, XDS uses OASIS ebXML over SOAP , ..... but nearly all of them provide at least some WS interfaces.
It seems that the whole community is going more and more to the direction of SOAP WS !
We also must provide our "easy access layer" to external companies.

So after considering a lot of things I hope that SOAP WS will match my requirements the best way.

I will put the services to one endpoint for now that the others can continue their testing , afterwards we will have time to fix the httpSession dependency problem !

thanks a lot

roland
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Roland Maurer:
I will put the services to one endpoint for now that the others can continue their testing , afterwards we will have time to fix the httpSession dependency problem !


Don't get your hopes up but this article was mentioned in another topic:
A little bit about Message Context in JAX-WS

Based on that there may be a chance that you can get at the HTTP headers with.

I say "a chance" because this information is supposed to be only available for HTTP bindings (as opposed to SOAP bindings). However in the beginning of the article there is some mention that the HTTP information may also be available for SOAP bindings.

So now it's a matter of finding the necessary header and placing that into the header map (inside the request context map, MessageContext.HTTP_REQUEST_HEADERS) on the other stub before dispatching the request.

Even if this doesn't work straight out of the box exploring the contents of those "context maps" may uncover what you need.
[ November 24, 2008: Message edited by: Peer Reynders ]
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Roland Maurer:
It seems that the whole community is going more and more to the direction of SOAP WS !
We also must provide our "easy access layer" to external companies.


Some of the popularity of SOAP WS can be blamed on the ease of use of code generation tools like wsimport and wsgen. Then because it is so easy to use that hammer you try to fix every problem with nails. Most solutions are primarily interested in "accessibility over the web" and SOAP can work over the web - but SOAP doesn't work like the web and that can create some problems. Unfortunately using the web in a manner that maximizes the use if it's strengths can require some drastic re-thinking.

IBM seems to have recognized that while it's high-end customers don't seem to mind the cost and complexity of WS-*, SOAP-based solutions may have actually overshot the needs of "the masses" who simply require "easy access over the web" - this is presumably why they launched Project Zero.

RESTful HTTP web services vs. Big Web Services (SOAP/WSDL)
[ November 24, 2008: Message edited by: Peer Reynders ]
Roland Maurer
Greenhorn

Joined: Nov 23, 2008
Posts: 17
Hello Peer,
your links were really helpful !
I tried to study some articles about the topic and discussed a lot with my collegues.
I think I will not take a solution where we must modify the httpHeader out of a SOAP WS.
I also think we will not use a vendor extension like ( https://jax-ws.dev.java.net/2.1.5/docs/statefulWebservice.html )
We are still discussing the possibility to use REST, but I think we are already forced to use SOAP on to much other places.

I think we will use SRP (http://srp.stanford.edu/) to have a strong key and authentication between Web-Frontend and "Web-backend"
For communicating user authentication we will probably use SAML, and we also take a look to WS-SecurityConversation, WS-RF and WS-RM so that we can make a decision, what standard fullfills our requirements the best. I like WS-SecConv !
So we will have a lot to do thanks for your help,

roland
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: jax-ws same httpSession with different wsdls