A web service and a client may communicate multiple times to complete a single task. Also, multiple clients may communicate with the same web service at the same time. Conversations provide a straightforward way to keep track of data between calls and to ensure that the web service always responds to the right client.
Conversations meet two challenges inherent in persisting data across multiple communications:
When a client begins a conversation with a service, WebLogic Server creates a context in which to keep track of state-related data during the exchange. This new context is identified by a conversation ID, a string that uniquely identifies the conversation. The web service uses this conversation ID to correlate messages to the client through each operation it performs. The conversation ID ensures that a message sent or received by the web service is always associated with the appropriate client.
You can see the conversation ID in action when you test an asynchronous web service in Test View. For example, if you test the sample service HelloWorldAsynch, you can start multiple conversations and observe how the results are correlated with the conversation ID in test view.
At any given time during a communication between a client and your web service, the web service may need to keep track of data for the client. The web service’s state refers to all of the data that it is tracking at a particular moment. For example, consider the Investigate sample web service (described in Tutorial: Your First Web Service). In that example, the Investigate service receives a taxpayer ID from its client in the first call to the service and uses this ID to gather credit information. The service stores the taxpayer ID in a member variable so it can be retrieved as needed throughout the lifetime of the exchange between client and service. On the next call, the client does not have to pass the taxpayer ID to the service, which reduces complexity for both the client and the service. In this example, the taxpayer ID is state-related data—that is, data that is saved between calls.
Now imagine that the computer on which the service was running suddenly shut down. If the taxpayer ID were held only by the member variable in the service instance, it would be lost when the instance vanished from memory as the computer shut down. Fortunately, conversations make your web service more robust by writing state-related data to disk, so that the data is preserved through a system failure. This additional security is provided for you automatically when you specify that calls to your web service are part of a conversation.
How Do I: Add Support for Conversations?