6
Managing Web Service Persistence 6-1
6
Managing Web Service Persistence
The following sections describe how to manage Web service persistence.
■
Section 6.1, Overview of Web Service Persistence
■
Section 6.2, Roadmap for Configuring Web Service Persistence
■
Section 6.3, Configuring Web Service Persistence
■
Section 6.4, Using Web Service Persistence in a Cluster
■
Section 6.5, Cleaning Up Web Service Persistence
6.1 Overview of Web Service Persistence
WebLogic Server provides a default Web service persistence configuration that provides a built-in, high-performance storage solution for Web services. Web service
persistence is used by the following advanced features to support long running requests and to survive server restarts:
■
Asynchronous Web service invocation using asynchronous client transport or MakeConnection
■
Web services reliable messaging
■
Message buffering
■
Security using WS-SecureConversation Specifically, Web service persistence is used to save the following types of information:
■
Client identity and properties
■
SOAP message, including its headers and body
■
Context properties required for processing the message at the Web service or client for both asynchronous and synchronous messages
The following figure illustrates an example Web service persistence configuration.
6-2 Programming Advanced Features of JAX-WS Web Services for Oracle WebLogic Server
Figure 6–1 Example Web Service Persistence Configuration
The following table describes the components of Web service persistence, shown in the previous figure.
When configuring Web service persistence, you associate:
■
A logical store with a buffering queue.
■
A buffering queue that is associated with a physical store via JMS configuration. The association between the logical store and buffering queue is used to infer the
association between the logical store and physical store. The default logical store is named WseeStore and is created automatically when a domain is created using the
WebLogic Advanced Web Services for JAX-WS Extension template wls_ webservices_jaxws.jar. By default, the physical store that is configured for the
server is associated with the buffering queue. This strategy ensures that the same physical store is used for all Web service persistence and buffering. Using a single
physical store ensures a more efficient, single-phase XA transaction and facilitates migration.
You can configure one or more logical stores for use within your application environment. In
Table 6–1 , the servers Server1 and Server2 use the same logical
store. This configuration allows applications that are running in a cluster to be configured globally to access a single store name. As described later in
Section 6.3, Configuring Web Service Persistence
, you can configure Web service persistence at
Table 6–1 Components of the Web Service Persistence
Component Description
Logical Store Provides the configuration requirements and connects the Web service to the physical
store and buffering queue. Physical store
Handles the IO operations to save and retrieve data from the physical storage such as file, DBMS, and so on. The physical store can be a WebLogic Server persistent
store, as configured using the WebLogic Server Administration Console or WLST, or in-memory store.
Note : When using a WebLogic Server persistent store as the physical store for a
logical store, the names of the request and response buffering queues are taken from the logical store configuration and not the buffering configuration.
Buffering queue Stores buffered requests and responses for the Web service.
Managing Web Service Persistence 6-3
various levels for fine-grained management. Best practices are provided in Section 6.2,
Roadmap for Configuring Web Service Persistence.
