Keeping state with remote EJBs and Web Services

Question

I have a web-based application which makes use of remote EJBs for its business logic. Some of these EJBs are also exposed as Web Services. I need to keep a small state for some of these calls in order to allow subsequent calls to function correctly. Which of the following would you recommend?

• Stateful EJBs (will this work with Web Services?)
• Return the state to the client (what if I want to prevent the client from altering the state?)
• Reload the state from the DB on each method (should I worry about the overhead?)

Answer 1

All three proposed solutions can be made to work, but the best solution will depend on the details of your application.

I don't use Stateful Session Beans (SFSBs) at all. SFSBs are designed to keep session state, but using them via a Web Service raises questions about what exactly is a session? If you have a complicated deployment environment or users use multiple instances of the application then this could be a fragile solution.

Returning state - as the question indicates, there could be security issues unless you are certain that the server can trust its clients. You could use encryption techniques to verify that the state object had not been modified, but it is much safer not to give sensitive data to a potentially hostile client. Another situation where this might be useful is if the client is permitted to alter the state, or if no harm can be done if the client does so. If client access to the system is always through a web-tier, this is a good place to store session state. The web-tier and application-tier can safely exchange state objects.

Reloading the state from the database is probably the most generally applicable approach. If you use an entity bean or an Object Relational Mapping library then the server should be able to reduce the number of database queries.

Answer 2

The only option you have is to store appropriate information associated with a certain UserId in the DB.

You can't expose Statefull bean as Webservice.

In case of exposing your Beans as Webservices you could try to send additional information back and forth by putting in the SOAP header to prevent modifications in the body. But in this case clients will be able to alter it.