Implementing Conversations

This topic provides information about building web services that support conversations. Conversations are part of a technology through which you can ensure that WebLogic Server maintains your service's state-related data and correlates communications between your service, clients, and resources such as other services.

You should consider supporting conversations in any service design that is asynchronous or involves multiple communications with a client in connection with a single request. Services that support conversations are treated differently by WebLogic Server. When a client calls a service operation that is annotated to start a conversation, WebLogic Server creates a conversation context through which to correlate calls to and from the service and to persist its state-related data.

Understanding Conversation Context

Context is the key to the benefit provided by conversations. Conceptually speaking, multiple related calls to or from a single web service are part of the same context by virtue of being related to the same initial request. With WebLogic Workshop, you can easily build services that support this conceptual reality by using conversations.

When a conversation starts, WebLogic Server does the following:

Each piece of information — the conversation ID, persistent data, idle time and age — are part of the conversation's context. In particular, the conversation ID is passed back to the client in the XML message through which web services communicate. A conversation ID is also passed in calls to resources. With each subsequent conversational call to the web service, the conversation ID is used to associate the call with the correct conversation context — in other words, the correct instance of the service, along with whatever state it may currently hold.

Notes About Conversation Context

As you build services that support conversations, there are a few characteristics of conversations you should keep in mind:

Note that this excludes internal methods of your service (which are not operations and so can not be conversational) and methods exposed by other web services.

Implementing Conversational Methods and Callbacks

In practice, adding support for conversations is typically a matter of annotating methods and callbacks with the conversation phase attribute (discussed in the following section). Even so, as you write code for methods and callback handlers that will be annotated for use in conversations, you may want to keep the following suggestions in mind.

Applying the Conversation Phase Attribute

Applying a conversation phase attribute to a method or callback identifies it as having a role in conversations. In Design View, you can apply the attribute using the Properties pane. When you set the conversation phase property, a corresponding tag like the one below is added to your service's source code immediately preceding the method or callback declaration:

@jws:conversation phase="start"

Possible values for the conversation phase attribute are as follows:

For more information adding support for conversations with the conversation phase attribute, see How Do I: Add Support for Conversations?

Note: It is possible to create a conversational web service that supports a deadlock condition. If the web service has at least one non-buffered incoming method with conversational phase set to "continue" or "finish" and has at least one non-buffered outgoing callback, it is possible that the callback will be initiated at the same time as a client calls one of the incoming methods. This situation will result in deadlock, causing one or both of the transactions to time out and be rolled back. If you experience this problem, make either all incoming methods or all outgoing callbacks message-buffered. For more about message buffering, see Asynchronous Methods.

Notes About Setting Conversation Phase

Unless you know how a given control is implemented, it is not a good practice to apply the conversation phase attribute to methods and callbacks exposed by controls.

In other words, you should ordinarily not change the conversation phase attribute for items that appear on the right side of the design view. When you import the control (CTRL) file corresponding to a resource such as another service, its image in Design View will indicate how and whether it supports conversations. Because the control is merely a proxy for the resource itself, "changing" its conversation support may result in unpredictable behavior.

Related Topics

JwsContext Interface

@jws:conversation Tag