Overview: Conversations

For web services that may communicate with a client multiple times in connection with a single task, conversations ensure that the communications are kept straight. In addition, web services that communicate asynchronously use conversations to maintain state across asynchronous messages. Conversations meet two challenges inherent in persisting data across multiple communications with a client or resource (such as another service or a data source):

- Maintaining state, or the data held by a web service for a specific task. This is essential when communications are asynchronous.

- Associating the actions a service performs (including its calls to other resources) and its response to a client with the client's original task.

# How Conversations Work

A web service participating in a conversation works within a specific context created by WebLogic Server. Using the unique identifier that is part of this context, WebLogic Server saves the service's state and correlates — that is, tracks communication between the service, its client, and resources used by the service.

## State Persistence Through Serialization

State refers to the condition of your web service at a given time, and is made up of the data it holds. Consider the Investigate sample web service (described in Tutorial: Your First Web Service). In that example, the Investigate service takes a taxpayer ID from a client and uses this number to gather credit information. The service stores the taxpayer ID in a member variable so it can retrieved as needed. The taxpayer ID in this case is an example of state-related data — data that makes up the condition of the service while it is processing.

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.

To ensure that state-related data remains safe through such events, you can specify that calls to the service are part of a conversation. When a conversation with a service begins, WebLogic Server creates a context in which to keep track of the service's state-related data. Data that is part of a service's context is preserved through serialization, a process through which the data can be written to the hard disk.

## Correlated Messages Through a Unique Identifier

The context created for a service that participates in conversations includes more than data stored in member variables. It also includes the identity of the client with which the service is conversing and information tying that client to the task begun with the client's initial request. A web service may begin thousands of tasks for client requests over a period of time, from the same and different clients. With multiple communications, a service needs a way to remember which of the potentially thousands of requests its response belongs to.

When the various actions for processing a task are associated with the original request, this is an example of correlation. For each new conversation started with a service — in other words, for each new context — WebLogic Server generates a unique identifier called a conversation ID. The conversation ID is used to correlate the original request (and its client) with subsequent communications with other web services, queries to databases, and exchanges with other resources. Each of these actions and its effect on state-related data is correlated with the original request using the conversation ID so that the client receives a response associated with the original request.

## Beginning, Middle and End

As described in Life of a Conversation, conversations for web services have a life of their own. They start when a client calls a web service using a method that is marked to "start" a conversation, they move through methods and callbacks marked to "continue" the conversation, and they end with a call to a method or callback marked to "finish" the conversation. The call to the first method creates a context for the conversation, and subsequent calls continue the conversation, serializing the updated state information so that the context remains current. The last call finishes the conversation, prompting WebLogic Server to release any resources and state data it was holding on behalf of the web service.

# How to Build Services That Support Conversations

In practice the processing of adding support for conversations is often as simple as setting the right property for each of the service's operations (methods and callbacks it exposes to other components). For more detailed information a few design suggestions, see Implementing Conversations.

For a step-by-step procedure on adding support for conversations, see How Do I: Add Support for Conversations. You will also find a hands-on introduction to conversations and other WebLogic Workshop technologies in Tutorial: Your First Web Service.

# Testing with Conversations

When you test a web service that supports conversations, Test View displays the conversation ID in the Message Log. The Message Log also group the actions associated with a conversation. As you test the service multiple times, each test is added to the Message Log until you clear the log. You can also use Test View to clear conversations.

For more information about Test View, see Test View. For step-by-step information on using Test View, see How Do I: Test A Web Service Using Weblogic Workshop's Test View?

Related Topics

How Do I: Add Support for Conversations?

Tutorial: Your First Web Service

Implementing Conversations