Hi ranchers i was reading the specs and it has been very clearly mentioned that Only a stateless session bean or singleton session bean may provide a web service client view So this means that a web service cannot invoke statefull beans , Why not statefull beans ?
Now this is my curiosity to know the reason behind this , may be some of the experienced ranchers can answer this question of mine .
According to me a web service is modular service that can be interacted through the medium of xml . So why cant a webservice be used with statefull beans.
For example lets take i have an emart application which follows a typical MVC model , where all my business logic is handled by EJB beans and , (my emart app is distributed) and client request a web service which in return calls my beans , so as we all know in a typical emart app we do need to maintain session .
So above mentioned scenerio cannot be implemented as web service cannot invoke statefull beans .
Really love to hear your point of view ? Because discussing a topic like this always exposes us to share knowledge , especially for a fresher like me .
Well, I am not too much into that stuff but here is my guess:
WebServices are request based. Basically the Service is requested, the response is rendered and then the conversation is forgotten.
With HTTP one could use HttpSessions in order to keep the knowledge that a request comes from the same client.
The following steps belong to a lifecycle of a Session:
- Starting it
- Doing conversation
- Ending it.
Same with Stateless EJB services, isn't it?
Since a non HTTP WebService is stateless by nature, how could the container (handling the Sessions and Transactions) know how client requests belong to the same client or conversation?
You would have to do that manually. Most likely you would end up doing that by using stateless EJB services.
Answer in short: There is no bridge for the gap of the stateless nature of WebServices to the stateful nature of stateful EJBs.
I hope it helps. My answer is just the conclusion of all the knowledge I have regarding WebServices, Http and EJB.
Sagar Shroff wrote:Thanks for your reply , your answer makes sense.But i dint understood one statement of yours
Dirk Schumacher wrote:You would have to do that manually. Most likely you would end up doing that by using stateless EJB services.
How would your maintain session manually using stateless EJB ?
I just gave it a thought how I would do it in case I would have to implement it with the precondition of not using SFSB.
Goal is to persist the conversation state w/ a client in the backend which it loosely connected to the web request (Http, simple GenericServlet for e.g. XML stream handling, some XML JEE handling mechanism.)
This would be my general Session handling SLSB interface, which:
The pattern to follow is that calling doWhateverInTheSession implies that that register was called. Though the doWhateverInTheSession could register the session itself by checking the active session. It's up to your fantasy or use case.
If I remeber right, depending on the JEE version, it is not even possible to directly use a SLSB in a Servlet. In other words the container will not inject the SLSB into the Servlet. You would have to do that manually by using a remote SLSB.
This case you could also manually inject remotely a SFSB bean. More on the key of the problem at the bottom...
On an Http-Service (Servlet, JSF, Struts-Action,... which are all somehow in some way inherit from a Servlet) I would use the HttpSession Id to identify a client by using a SLSB with the following service methods:
Of course there needs to be done some more code in the servlet handling like creating / recognizing the http servlet session.
On a simple (generic) servlet receiving an XML for example the key is to recognize the client in order to map the client to a session.
Two ways to do that, but the latter I never implemented...
1. the XML must contain the login information to know about the user, for example:
Map the /root/@user/text() to register or get the Session. Each request must have the user set being used as the session id.
Actually there you have your session created anyways by the user and you must not use a session service. Most likely there is the need to track the conversation anyways by inspecting the xml.
I do not know straight away how to access the current user within a servlet there. But this is moving the information of /root/@user/text() to a more basic level at the http request call stack.
From here it is getting fuzzy since your use case is not known. Also it is not known what and where your information of your client (which maps to a session and could make it a stateful conversation) is located.
Inspect what information about your client is available where at each of your requests to the server. If you do not have identifying information of the client then you probably must provide it.
The goal is to map that identifying client information of the request on the server to a stateful conversion wherever this is located. The IP address is most not of use since it cannot safely determine a unique request caller.
For example an HttpServlet (which is a framework based on GenericServlet based which is framework based on java.net.ServerSocket) is somehow using Cookies, URL-rewriting, ... to archive that goal.
The nature of TCP/IP is stateless for each request. Any program having converstion over TCP must deal w/ that stateless nature.
Setup a playground project testing it out with focus on the issue and surpressing any further business logic...