Controls: Service Enablement

WebLogic Server Process Edition provides a set of out-of-the box controls that enable you to start integration projects with a portfolio of resources. WebLogic Server Process Edition integration controls provide easy access to enterprise resources like databases, file systems, etc., from within your application. WebLogic Integration applications also have access to external resources through the WebLogic Workshop high-level controls. BEA Workshop for WebLogic Platform provides a consistent mechanism for interacting with resources across all BEA Workshop for WebLogic Platform, WebLogic Integration, and WebLogic Portal components. The control handles the work of connecting to the enterprise resource for you, so that you can focus on the logic of your business process.

WebLogic Integration controls are now based on the Apache Beehive open source framework ( http://beehive.apache.org/). Beehive is a lightweight component framework that helps programmers encapsulate application logic and leverage metadata annotations into their programming model. Developers can create custom controls or use the pre-built system controls.

The following sections describe the WebLogic Server Process Edition integration controls and the other available WebLogic controls in more detail, before introducing asynchronous interfaces and conversations:

Integration Controls

File Control

A File control is used to perform operations on a file. It allows business processes to read, write, or append to a file in a file system. In addition, the File control supports file manipulation operations such as copy, rename, and delete. You can also retrieve a list of the files stored in a specific directory. The files can be one of the following types: XmlObject, RawData (binary), or String.

The methods available to a File control depend on the type of data contained in the file. For a file of type String or XmlObject, you can specify the character set encoding. When processing a file, you can specify the delimiter for a file as the record size. If no delimiter is specified, the file is processed one line at a time. In the case of files of type String, you can also specify number of bytes or any character as a delimiter.

Normally, you configure a separate File control for every individual file you want to manipulate. You can specify File control settings in several different ways. You can set the File control's properties in Design view or you can call the setProperties method of the FileControl interface. You can change File control configuration properties dynamically. To get the current property settings, use the getProperties() method.

You can also use the ControlContext interface to access a control's properties at run time and to handle control events. Property values set by a developer who is using the control are stored as annotations on the control's declaration in a JWS, JSP, or JPD file, or as annotations on its interface, callback, or method declarations in a Control Definition file.

Email Control

The Email control enables WebLogic Server Process Edition business processes to send e-mail to a specific destination. The body of the e-mail message can be text (plain, HTML, or XML) or an XML object. The Email control is customizable, which allows you to specify e-mail transmission properties in an annotation, or use dynamic properties passed as an XML variable. You can use the Email control to send a variety of content types and various combinations of body and attachments.

When you add an Email control to your business process, you can use an existing Email control definition file or create a new one.

WLI JMS Control

JMS (Java Message Service) is a Java API for communicating with messaging systems, which are often packaged as products known as Message-Oriented Middleware (MOMs). WebLogic Server includes built in messaging capabilities via WebLogic JMS, but can also work with third-party MOMs. Messaging systems are often used in enterprise applications to communicate with legacy systems, or for communication between business components running in different environments or on different hosts.

The WLI JMS control enables WebLogic Workshop business processes to easily interact with messaging systems that provide a JMS implementation. A specific WLI JMS control is associated with particular facilities of the messaging system. Once a WLI JMS control is defined, business processes may use it like any other WebLogic Workshop control.

The WLI JMS control is an extension of the JMS control, providing additional features such as RawData message type support, dynamic property configuration, and the ability to control whether to start a new transaction or remain within the calling transaction.

For more information, see WLI JMS Control in Using Integration Controls in the WebLogic Workshop Help.

Service Broker Control

The Service Broker control allows a business process to send requests to, and receive callbacks from, another business process, a Web service, or a Web service or business process defined in a Web Service Description Language (WSDL) file. The Service Broker control lets you dynamically set control attributes. This allows you to reconfigure control attributes without having to redeploy the application.

A remote Web service or business process is accessed using Web services and is described in a WSDL file. A WSDL file describes the methods and callbacks that a Web service implements, including method names, parameters, and return types. You can generate a WSDL file for any business process by right clicking on a JPD file in the Application pane and choosing Generate WSDL File.

HTTP Control

The Hyper Text Transfer Protocol (HTTP) control is built using the features of the WebLogic Platform control architecture. This control's purpose is to provide outgoing HTTP access to BEA Workshop for WebLogic Platform clients. The Http control complements the other controls provided in WebLogic Integration and can be used with BEA Workshop for WebLogic Platform and business processes to work with HTTP requests and process responses. The HTTP control source file is a wrapper around the Jakarta Commons HTTP Client package. The HTTP control conforms to HTTP/1.1 specific features.

The Http control enables WebLogic Workshop and business processes to work with HTTP requests and send responses to a specific URL. The Http control supports two HTTP modes for data transfer, namely HTTP GET and HTTP POST. By using the GET mode, you can send your business data along with the URL. By using the POST mode, you can also send Binary, XML, and string documents. You can specify HTTP properties in an annotation, or pass dynamic properties via an XML variable.

Using the Http control, you can send an HTTP or HTTPS (Secure HTTP) request to a URL and receive specific HTTP response header and body data, as follows:

Send Business data using HTTP Get and receive the HTTP response code and the message corresponding to the response code in an XML document.
Set HTTP header values for the HTTP Post mode.
Send Binary, XML, and String type data using HTTP Post and receive the HTTP response code and the message corresponding to the response code in an XML document.
Configure cookies for both the HTTP Get and HTTP Post modes.
Communicate via a secure HTTP (HTTPS) connection with both client-side and server-side authentication enabled.
Use a proxy server for sending an HTTP or HTTPS request.
Receive response headers in an XML document conforming to a pre-defined schema.
Receive response body data of type Binary, XML or String.
Receive cookies in an XML document conforming to a pre-defined schema.

MQSeries Control

MQSeries is a middleware product from IBM that runs on multiple platforms. It enables message transfer between applications; the sending application PUTs a message on a Queue, and the receiving application GETs the message from the Queue. The sending and receiving applications do not have to be on the same platform, and can execute at different times. MQSeries manages all the storage, logging and communications details required to guarantee delivery of the message to the destination queue.

MQ Series is a messaging service queue provided by IBM that enables message transfer between applications. The sending application puts a message on a Queue, and the receiving application gets the message from the Queue.

The MQ Series control enables business processes to send and receive messages using MQ Series queues. Using the MQ Series control, you can send and receive Binary, XML, and String messages. You can specify MQ Series control properties while configuring the MQ Series control or dynamically at run-time. By default, the MQ Series control handles transactions implicitly for each PUT and GET method individually, without having to set an explicit transaction boundary. However, transaction boundaries can also be set explicitly.

Using SSL, you can enable both one way authentication (server-side) and two-way authentication (client-side).

Disclaimer

Use of the MQSeries control and event generator with BEA WebLogic Integration in no manner confers or grants the right to use MQSeries control including "dynamic libraries". In order to use such IBM products, the user of the MQSeries control and event generator must obtain a valid license from IBM.

Tibco RV Control

TIBCO^® Rendezvous^™ (a product from TIBCO: www.tibco.com) enables exchange of data across applications running on distributed platforms. TIBCO Rendezvous (TIBCO RV) Control in WebLogic Server Process Edition enables seamless connection to, and transfer of data using the Rendezvous daemon. It enables communication via many of the features provided by the TIBCO Rendezvous product, including Certified Message Delivery, Distributed Queue and so on. The sending and receiving applications can be on multiple platforms, as long as the Rendezvous daemon is running on the host machine, or is remotely accessible to the host.

Disclaimer

Use of the TIBCO RV control with BEA WebLogic Server Process Edition in no manner confers or grants the right to use TIBCO Rendezvous including "dynamic libraries". In order to use such TIBCO products, the user of the TIBCO RV control must obtain a valid license from TIBCO. See


http://www.tibco.com

for information on how to obtain a licensed copy of Rendezvous.

XML MetaData Cache Control

The XML MetaData Cache control is used in business processes to access and retrieve XML metadata maintained in XML MetaData Cache. This cache is managed by WebLogic Integration Administration Console or the MBean API, which allows users to create their own NetUI-based consoles. The XML MetaData Cache is a global, domain-wide cache. So, data maintained in the cache can be accessed by any business process that is deployed in that domain. The cache can also be used for sharing data within a cluster. The cache is primarily used to maintain configuration metadata. Data is stored as key-value pairs where key is of type String and the value contains XML data. Data from the cache is made available permanently through file-based storage. For each XML document that is added to the cache, a new XML MetaData Cache file is created. The XML MetaData Cache control in a business process uses the key to retrieve XML metadata associated with the key value, from the cache. For more information, see XML MetaData Cache Control in Using Integration Controls.

Other Available Application Controls

Beehive Controls

Beehive controls are reusable components you can use anywhere within an enterprise application. You can use built-in controls provided with Workshop for WebLogic Platform, or you can create your own. When you are building WebLogic Server Process Edition applications, Beehive controls provide a convenient way to incorporate access to resources and encapsulate business logic. Controls can:

Provide access to resources such as databases or other resources.
Encapsulate logic for reuse in other applications.
Modularize logic you want to keep separate from other application code.

Controls take advantage of Java 5 annotations for setting control properties. The system controls have a rich set of properties that are parameterized through annotation settings. As for custom controls, the control author can define annotation parameterization for any set of control properties.

Controls are built on the Apache Beehive Control framework. For more information, see Controls: Getting Started in the Apache Beehive documentation.

System controls and custom controls are two main types of controls. System controls provide you a way to connect to common application resources, such as databases, EJBs, JMS queues, web services, and so on. These controls require little or no modification to use in your application.

Workshop for WebLogic Platform provides several system controls, mainly designed to provide access to enterprise resources. For example, you can use the EJB control for access to Enterprise JavaBeans, the JMS control for access to the Java Message Service, and so on. For more information about the system controls, see Using System Controls.

Custom controls provide a way to fully customize access to a resource or encapsulate some application functionality. You can design a custom control to do any task in an application.

You can build your own custom controls that are based on the same framework on which system controls are based. You design a custom control from the ground up, designing its interface and implementation, adding other controls as needed. You can design a custom control for use in one project, or you can design a custom control for easy reuse in multiple projects. For more information about the custom controls, see Building Custom Controls.

JDBC Control

A JDBC control makes it easy to access a relational database from your application. Using the JDBC control, you can issue SQL commands to the database. The JDBC control automatically performs the translation from database queries to Java objects, so that you can easily access query results.

A JDBC control can operate on any database for which an appropriate Java Database Connectivity (JDBC) driver is available and for which a data source is configured in WebLogic Server. When you add a JDBC control to your application, you specify a data source for that control. The data source indicates which database the control is bound to.

Timer Control

Some transactions and events require a certain amount of time to complete. Others can run indefinitely if not aborted, and eat up resources. Still others must occur at a specific time. The Timer control provides the developer with a way to respond from code when a specified interval of time has elapsed or when a specified absolute time has been reached.

A specific (absolute) timeout has passed (e.g., January 23, 2012 midnight)
A relative timeout has passed (e.g., an hour and seventeen minutes)
A recurring time interval has elapsed (e.g., every 3 minutes)
Both an initial timeout and a recurring interval (e.g., after one hour, every 5 minutes OR after January 1, 2010, every hour thereafter)

All Timer controls are instances of the com.bea.control.TimerControl base class or the com.bea.control.TimerControlBean base class. A Timer control is declared directly in a .java file. Timer controls are based on the EJB 2.1 timer service. Timer controls make a best-effort to do a callback to the client when a timer elapses, suitable for application timers. However timer controls are not a true real-time time service. Timer controls are allowed only in conversational (stateful) web services.

Service Control

A service control is a proxy for a web service. The web service client uses this proxy to access the web service. Using a service control allows the web service client to access the operations of a web service through simple method calls to the service control. The service control manages the SOAP message exchange with the web service and returns the results of the web service operation.

All service controls are interfaces that extend the com.bea.control.ServiceControl base class.

A service control provides an interface between your application and a web service, which allows your application to invoke the methods and handle the callbacks of that web service. Using a service control, you can connect to any web service for which a WSDL file is available.

EJB Control

Enterprise JavaBeans (EJBs) are Java software components of enterprise applications. The Java 2 Enterprise Edition (J2EE) specification defines the types and capabilities of EJBs as well as the environment (or container) in which EJBs are deployed and executed. From a software developer's point of view, there are two aspects to EJBs: first, the development and deployment of EJBs; and second, the use of existing EJBs from client software. The EJB control makes it easy to use an existing, deployed EJB from your application.

JMS Control

Java Message Service (JMS) is a Java API for communicating with messaging systems. Messaging systems are often used in enterprise applications to communicate with legacy systems or to provide communication lanes between business components running in different environments or on different hosts. The JMS control enables applications built in WebLogic Workshop to easily interact with messaging systems that provide a JMS implementation, such as WebLogic Server or Message-Oriented Middleware systems (MOMs).

The following changes have been made in the JMS control that was provided in WebLogic Workshop 8.1:

In WebLogic Workshop 8.1, there was {parm} support in method level annotations. This is no longer supported. You have to annotate parms to specify header or property values.
New transacted annotation needs to be false when used in a container-managed transaction.

Using Asynchronous Interfaces

Web applications, including Web services, typically use the Hypertext Transport Protocol (HTTP) to provide communication between a client and a server (the application). HTTP is a request-response protocol. In a request-response protocol, each operation consists of a request message sent from the client to a server followed by a response message returned from the server to the client. The server must always send a response for the operation to complete successfully. Such requests are called synchronous because during the request the client is synchronized with the server; the client cannot continue processing until the server responds or the request times out (the client may time out if a response is not received within a specific period of time).

In a Web application, some of the operations the application performs may be long-running such as a Local Number Portability check when one changes phone companies. These processes could span days. It would be a poor design if individual request-response cycles were allowed to span days; such requests would unnecessarily engage resources on both the client and server hosts.

With WebLogic Server Process Edition, you can design your application to be asynchronous, which means that the application notifies the client when the response is ready. This allows the client to continue performing other work while the application completes the requested operation. It also keeps each request-response interaction between the client and application as short as possible.

The following sections provide an overview of asynchrony and asynchronous interfaces:

Overview of Asynchrony

Interactions between software components can be synchronous or asynchronous. An interaction is synchronous if the caller of a method must wait for the method's work to complete before the caller can continue its processing. An interaction is asynchronous if the called method returns immediately, allowing the caller to continue its processing without delay. An asynchronous interaction typically initiates a computation but does not wait for the result to be available, which means it must provide some way for the caller to obtain the results of the computation at a later time.

The distributed nature of Web applications introduces unpredictable and sometimes very long latencies, which means it may take an operation a long time to complete. If a business process executing over the network involves human interaction at the back end, an operation can take on the order of days. If all interactions over the Web were synchronous, clients with pending operations could consume resources on their host systems for unacceptably long periods of time.

WebLogic Server Process Edition provides tools that make it easy for you to build asynchronous Web services and Java controls that don't require clients to block execution while waiting for results. WebLogic Server Process Edition provides multiple approaches for returning results to your Web services' and Java controls' clients; you can choose the one that best suits each situation.

Using Asynchrony

To create an asynchronous Web service, you provide one or more methods that accept requests from clients that begin an operation but do not wait for the operation to complete. Such methods typically return immediately, supplying the response portion of the initial request-response interaction but not supplying the actual result of the requested operation. In an asynchronous interface, you also provide a mechanism for the client to obtain the results of the long-running operation when the results are ready. There are two ways to accomplish this:

Implement methods that initiate requests and define callbacks to send results.
Implement methods that initiate requests, methods that return request status (for example, "pending" or "complete"), and methods the return results. This approach is referred to as a polling interface.

Using Callbacks

When you define a callback for a Web service, you are defining a message for the Web service to send to the client that notifies the client of an event that has occurred in your Web service. In this design, the client first calls the Web service with a request. This request call typically returns immediately (completing the first request-response interaction), meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks. When the Web service or Java control has finished processing the client's request, it sends a callback, that is, it sends a message back to the client notifying it that the request has been processed and/or providing the results. Note that a callback constitutes a second request-response interaction in which the request (not the response) is sent to the client. To learn more about the callback mechanism, see "Using Callbacks to Notify Clients of Events" in Advanced JWS Programming: Implementing Asynchronous Features in Programming Web Services for WebLogic Server.

To use a callback, two requirements must be met. First, if a Web service defines a callback the Web service must be conversational. Conversational Web services keep track of the originator of a request and can therefore send the callback to the appropriate caller. Secondly, the client must be capable of receiving and interpreting the callback. If the callback is defined by a Web service, then in essence the client must itself be a Web service since it must be capable of receiving messages. It must also be capable of correlating an incoming message with a previous request that it initiated. For more information about conversations, see Designing Conversational Web Services.

Using Polling

When the client of a Web service or Java control is not conversational, as is the case for Web pages and non-conversational Web services, callbacks cannot be used to notify the client of request completion. In addition, if the client of your Web service resides on a host that rejects unsolicited incoming traffic or is protected by firewalls, the host will reject callbacks because callbacks are, by nature, unsolicited, and the client will not receive the callback. To handle these scenarios, Web services and Java controls must provide a polling interface. In a polling interface, the client first calls the Web service or Java control so that an operation can be initiated. This request call is synchronous but typically returns immediately, meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks, but must periodically call the Web service or Java control to check the status of its pending request. When a periodic check shows that the request has been completed, the client then calls the Web service or Java control to obtain the result. To learn more about implementing a polling interface, see Using Polling as an Alternative to Callbacks.

Polling and callbacks are two different mechanisms to achieve asynchrony. Unless you are absolutely certain that the clients of your Web service or Java control will always require only one of these mechanisms, you may want to implement both approaches in order to handle all situations. Doing so provides the convenience of callbacks to those clients who can handle them, and a polling interface for clients who cannot accept callbacks.

Designing Asynchronous Interfaces

This section discusses the best practices for creating and using Web services and Java controls with asynchronous interfaces. The first topic describes how to use polling as an alternative to callbacks. Then, various design questions for designing Web services and Java controls that can be called by both Web services and JSP (web) pages are answered.

Using Polling as an Alternative to Callbacks

Because callbacks are, by definition, separated from the original request to which the callback is a response, they appear as unsolicited messages to the client's host. Many hosts refuse unsolicited network traffic, either because they directly reject such traffic or because they are protected by firewalls or other network security apparatus. Clients that run in such environments are therefore not capable of receiving callbacks.

Another requirement for handling callbacks is that the client is persistent by being conversational. If the client is a Web application, that is, a JSP page, or a non-conversational Web service, it cannot handle callbacks.

In order to allow clients that can't accept callbacks to use your Web services, you can supply a polling interface as an alternative. In a polling interface, you provide one or more methods that a client can call periodically to determine whether the result of a previous request is ready. Although the Web service or Java control will still be asynchronous in design, the interactions with a client are handled with synchronous (unbuffered) methods.

A start_request method that the client will call to initiate a request. If the client calls a Web service, the start_request method will start a conversation.
A check_status method that the client will periodically call to check the status of the request. The method returns a boolean value indicating whether or not the request has been handled. If the client calls a Web service, the check_status method will continue the conversation.
A get_results method that the client will call to get the results of the request. The results may for instance be returned as a String or an object of some kind, or null if the request could not be processed successfully. If the client calls a Web service, the get_results method will finish the conversation.

Notice that a client using a polling interface needs to periodically check the status of the request, because the Web service or Java control cannot notify the client when its request has been processed. Also notice that the three methods will not be buffered. The check_status and get_results methods do not return void and cannot be buffered, while the start_request method cannot be buffered because you need to ensure that this method has been handled before the check_status is handled. (Remember that the relative handling order of buffered and unbuffered methods is uncertain. For more information, see Using Buffering with Web Service Callbacks and Control Events.

There are several other ways to implement a polling interface. The following example shows one such variation:

A client uses the startRequest method to initiate a request from a conversational Web service. The client then calls getRequestStatus periodically to check on the result. As before, the client is free to perform other processing between calls to getRequestStatus. The getRequestStatus method returns an indication that the request is pending until the request is complete. The next time the client calls getRequestStatus after the request is complete, the result is returned to the client. The client then calls terminateRequest to finish the conversation.

Designing Robust Asynchronous Interfaces

This section explores several typical design solutions that constitute a good design and create a successful and robust Web service or Java control.

Do I Need an Asynchronous Interface?

The first question you might need to answer for a Web service or Java control is whether the service or control needs to be asynchronous. There are certainly cases where a non-conversational, synchronous service or control will suffice, especially when the functionality it implements is relatively small, the request handling is relatively short, and the underlying infrastructure supporting this Web service is solid; for instance if you are working on a fail-proof intranet or if your control is called by a (synchronous) Web service on the same server. However, if any of these factors are not true or uncertain at the time of design, you will want to make your service or control asynchronous.

Do I Need to Use Callbacks?

Callbacks are a powerful approach to designing asynchronous Web services or Java controls, relieving the client from periodically checking a request's status, as is required with polling. Especially when it is unclear how long a request will take to process, or if processing times vary wildly, using a callback is likely the most elegant implementation of asynchrony and loose coupling. Using callbacks in combination with buffering of both methods and callbacks is particularly effective in dealing with high-volume traffic. However, callbacks require that the client is designed to accept incoming messages and is hosted in an environment that supports message delivery.

Do I Need to Use Polling?

All asynchronous Web services and Java controls should provide a polling interface. If the Web service or Java control is asynchronous, a polling interface is required by any client that cannot accept callbacks; a polling interface is the only way such a client can obtain the results of operations initiated by asynchronous method invocations. You should think of a polling interface as the foundation interface of a Web service or Java control, and callbacks as "extra" functionality that is convenient for clients who can handle callbacks.

The exception to this guideline is a Java control for which the only clients will be conversational Web services or Java controls invoked by conversational Web services. Conversational WebLogic Workshop Web services can always accept callbacks. However, Java controls should be designed to be reusable. Assuming that the only clients a Java control will ever have are WebLogic Workshop Web services limits the reusability of the Java control.

A Robust Web Service or Java Control

To create an asynchronous Web service or Java control that is robust and handles all situations, it is recommended that you implement both a callback and a polling interface. Your design might (among others) include the following methods:

A start_request_asynch buffered method that the client will call to initiate a request. The method starts a conversation and notes that the callback mechanism will be used when the results are ready.
A callback_results buffered callback that sends the results to the client when the request is completed and finishes the conversation.
A start_request_synch buffered method that the client will call to initiate a request. The method starts a conversation and notes that the polling mechanism will be used when the results are ready.
A check_status unbuffered method that the client will periodically call to check the status of the request. The method continues a conversation and returns a Boolean value indicating whether or not the request has been completely handled.
A get_results unbuffered method that the client will call to get the results of the request. The method finishes the conversation.

Conversations

A single Web service may communicate with multiple clients at the same time, and it may communicate with each client multiple times. In order for the Web service to track data for the client during asynchronous communication, it must have a way to remember which data belongs to which client and to keep track of where each client is in the process of operations. In WebLogic Server Process Edition, you use conversations to uniquely identify a given communication between a client and your Web service and to maintain state between operations.

Conversations are essential for any Web service involved in asynchronous communication. This includes Web services that communicate with clients using callbacks or polling interfaces, and Web services that use controls with callbacks.

Overview of Conversations

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:

Conversations uniquely identify a communication between a client and a Web service, so that messages are always returned to the correct client. For example, in a shopping cart application, a conversational Web service keeps track of which shopping cart belongs to which customer.
Conversations maintain state between calls to the Web service; that is, they keep track of the data associated with a particular client between calls. Conversations ensure that the data associated with a particular client is saved until it is no longer needed or the operation is complete. For example, in a shopping cart application, a conversational Web service remembers which items are in the shopping cart while the customer continues shopping.

Correlating Messages with a Unique Identifier

When a client begins a conversation with a service, WebLogic Server Process Edition 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.

Implementing Conversations

Conversations maintain a Web service's state-related data and correlate communications between the Web service, its clients, and other resources. You should implement conversations in any Web service design that is asynchronous or involves multiple communications with a client or Java control in connection with a single request.

Understanding Conversation Context

When a client calls a service operation that is annotated to start a conversation, WebLogic Server Process Edition creates a conversation context through which to correlate calls to and from the service and to persist its state-related data.

Creates a context through which to maintain the scope of the conversation and associates it with a conversation ID.
Starts an internal timer to measure idle time.
Starts an internal timer to measure the conversation's age.

When WebLogic Server Process Edition performs all of these tasks, it creates a context for the conversation. Each piece of information—including the conversation ID, persistent data, idle time and age—is part of the conversation's context.

The conversation ID is a particularly useful item in the conversation's context. It attaches to each communication, which helps each of the resources, Web services, and clients involved in the conversation identify which communications belong to which conversation. To learn more about conversation IDs, see Overview of Conversations.

Designing a Web Service to Use Conversations

As you build services that support conversations, you should keep in mind a few characteristics of conversations. First, WebLogic Server Process Edition automatically handles correlation between two Web services that support conversations. In other words, if your Web service supports conversations and calls the conversational methods of another Web service that supports conversations, WebLogic Server Process Edition manages the conversation, including the conversation ID, automatically.

However, the scope of conversation context is limited to the service itself. You cannot assume that the state of another Web service is being persisted simply because your service calls one of its methods during the course of a conversation. The other Web service is responsible for its own state maintenance.

Also keep in mind that a Web service's state is only updated on the successful completion of methods or callback handlers that are marked with the conversation phase attributes start, continue, or finish. This excludes internal methods of your service, which are not operations and so can not be conversational.