I'm a little confused about the proper design of production asynchronous web services, especially related to the use of conversations and EJB. Take for example a simple query and retrieval web service which contains an asynchronous submit_query method, a query_status method and a retrieve_results method. Setting up a conversation in BEA WebLogic seems straightforward enough, but I'm wondering what's actually going on with the state between method invocations.
If I have another StatefulSessionBean doing the actual work of submitting the query to the databases, do I keep a member variable within the web service pointing to this EJB? What is stopping other simultaneous invocations to the web service from overwriting this member variable? I thought web service invocation shared the same instance like servlets.
Also related to the conversation, I am understanding that conversations allow the state (the EJB) to be persisted automatically in case of a server error using Java serialization. Will this persist the EJB and all of it's content which I imagine will include a list of results retrieved.
Basically my questions boil down to are web service instances shared among clients, thus disallowing the use of member variables set and accessed by service methods. And also, will member variable EJBs be persisted correctly by conversation support?
Please correct me if I'm way off base with everything, or if there is a more popular design for this simple approach.
you can convert an existing ejb (only stateless session beans) to a web service. all other features like security,scope,threading,transaction management etc. are used from the actual ejb and application server provided and there these are not addressed by web service.
an web service is just an request-reponse service much like http but uses xml hence http+xml=soap based web service.
all soap engines like jwsdp, .net ws, axis, ibm ettk support only stateless session beans to be exposed as web services but not any other type of ejbs all other types involve state to be preserved which http request-response wont support and hence not supported by soap web service.
Pertaining to using EJB as back-end components for web services... it's my understanding that this is very useful since you gain all the container advantages that EJB provides with only a little more code to write. There still must be some state persistence though for an asynchronous web service to work -- maybe the state isn't preserved directly in the bean, but it has to be somewhere. Otherwise how does the retrieve_results method ever get its data?
After looking a little further, it seems that the popular architecture for this is to use JMS and MessageDrivenBeans to handle the thread of submitting the query and then writing the results to a response queue.
I still have the same question about correlating a get_status request to a particular query though. It seems to me that conversations provide this but I can't actually work out the details.
The link provided is only about writing client btw. I need to actually create an asynchronous server. Thanks