Life of a Conversation
A conversation has a beginning, a middle, and an end. When you design a service that uses conversations you need to know the role for each method and callback in communicating with clients and other resources.
Not only do you set the conversation phases (start, continue, and finish) for the methods and callbacks, you can set service-level properties such as conversation lifetime (max-age, max-idle-time).
When you add support for conversations, you annotate your service's interface — the methods and callbacks it exposes to the outside world — with the conversation property's phase attribute. You can do this in Design View using the Properties pane. When you set this property for a method or callback, WebLogic Workshop adds an icon indicating whether the item starts, continues, or finishes a conversation:
The following example describes the life cycle of a service as it uses two conversations — one to respond to a client request and another to communicate with a Service control. The BookLocator service searches a network of other book sellers on behalf of a customer. Each of the numbers in the following illustration corresponds to a stage in the life cycle description that follows. Stages 1, 4, 5, and 6 describe the conversation between the BookLocator service and the client. Stages 2 and 3 describe the conversation between the BookLocator service and the bookSeller control. The code within the BookLocater service acts as the middleman and exchanges information between the two conversations. It’s as if the first conversation begins when the client speaks to the BookLocater, requesting a book. The BookLocater then turns to the bookSeller service to ask about the specific title. When the bookSeller service responds to the BookLocater this completes their conversation. The BookLocator turns back to the client who’s been patiently waiting and resumes that first conversation.
The client submits a search request by calling the requestBook method, passing information about the book and its author.
Because this method is marked as starting a conversation, WebLogic Server creates a new context for the service and associates it with a unique identifier, called a conversation ID. The conversation ID will be used to correlate further interactions between the client and the service, ensuring that calls back to the client and calls from other controls are correctly associated with this particular instance of the service.
The requestBook method returns void immediately, allowing the client to continue on its way. Such exchanges — a void return with the promise to call back when the response is ready — are an essential part of asynchronous communications.
As the method returns, WebLogic Server starts the conversation's idle and age timers, which can later be used to finish the conversation for lack of activity (provoke a timeout); at the same time, the service's state-related data is saved.
Code executing as part of the requestBook method's implementation calls the bookSellerControl's queryForBook method.
Because this method begins a conversation implemented by the bookSeller service, WebLogic Server creates a new context for that service; in other words, the call to this method is managed within its own context. However, even though each service context is separate, with separate conversation IDs and separate state-related data, WebLogic Server ensures that their communications are correctly correlated.
After the book seller has searched its inventory for the requested book, the bookSeller service returns its results using the onQueryComplete callback that is part of its interface. This callback finishes the bookSeller service's conversation with the BookLocator service, and its context is released by WebLogic Server — along with any resources it may have held to perform its service. The conversation context for the BookLocator service remains active.
The response is handled by the BookLocator service through the onQueryComplete callback handler. As an added value to clients, the folks behind the BookLocator service examine the data returned by the book seller they have queried to determine if it is likely to be useful to the client. In this case, the data is a long list of books of varying condition and price, so the book locator decides to request more information from the client in order to narrow the list.
The BookLocator requests more information through the onNeedMoreInfo callback. Because the callback is part of its interface, the client software is prepared to handle it, accepting parameters that indicate the sort of information that would help the BookLocator shorten the list of possible matches.
The onNeedMoreInfo callback is annotated to "continue" the conversation with the client. This ensures that the callback is sent in response to the correct request. Even if multiple requests to the BookLocator service have been made by multiple clients, the state of each is kept safe by its context.
Eventually, the client responds with more information, passing that information back to BookLocator as parameters of the submitMoreInfo method. Of course, the call to submitMoreInfo, like the callback made to the client, is annotated to continue the conversation.
BookLocator uses the additional information to shorten the list, then uses another callback, onSearchComplete, to send the short list to the client. This callback is annotated to "finish" the conversation. Once the callback has executed, the context created with a call to the start method is eligible to be removed by WebLogic Server.