8
Managing Web Services in a Cluster 8-1
8
Managing Web Services in a Cluster
The following sections describe how to manage Web services in a cluster.
■
Section 8.1, Overview of Web Services Cluster Routing
■
Section 8.2, Cluster Routing Scenarios
■
Section 8.3, How Web Service Cluster Routing Works
■
Section 8.4, Configuring Web Services in a Cluster
■
Section 8.5, Monitoring Cluster Routing Performance
8.1 Overview of Web Services Cluster Routing
Clustering of stateless Web services—services that do not require knowledge of state information from prior invocations—is straightforward and works with existing
WebLogic HTTP routing features on a third-party HTTP load balancer.
Clustering of Web services that require state information be maintained provides more challenges. Each instance of such a Web service is associated with state information
that must be managed and persisted. The cluster routing decision is based on whether the message is bound to a specific server in the cluster. For example, if a particular
server stores state information that is needed to process the message, and that state information is available only locally on that server.
In addition to ensuring that the Web service requests are routed to the appropriate server, the following general clustering requirements must be satisfied:
■
The internal topology of a cluster must be transparent to clients. Clients interact with the cluster only through the front-end host, and do not need to be aware of
any particular server in the cluster. This enables the cluster to scale over time to meet the demands placed upon it.
Note: For considerations specific to using Web service persistence in
a cluster, see Section 6.4, Using Web Service Persistence in a Cluster.
Note: Services that use session state replication to maintain their
state are a separate class of problem from those that make use of advanced Web service features, such as Reliable Secure Profile. The
latter require a more robust approach to persistence that may include storing state that may be available only from the local server. For more
information, see
Section , A Note About Persistence.
8-2 Programming Advanced Features of JAX-WS Web Services for Oracle WebLogic Server
■
Cluster migration must be transparent to clients. Resources within the cluster including persistent stores and other resources required by a Web service or Web
service client can be migrated from one server to another as the cluster evolves, responds to failures, and so on.
To meet the above requirements, the following methods are available for routing Web services in a cluster:
■
In-place SOAP router —Assumes request messages arrive on the correct server
and, if not, forwards the messages to the correct server at most one additional hop. The routing decision is made by the Web service that receives the message.
This routing strategy is the simplest to implement and requires no additional configuration. Though, it is not as robust as the next option.
■
Front-end SOAP router HTTP cluster servlet only—Message routing is managed
by the front-end host that accepts messages on behalf of the cluster and forwards them onto a selected member server of the cluster. For Web services, the front-end
SOAP router inspects information in the SOAP message to determine the correct server to which it should route messages.
This routing strategy is more complicated to configure, but is the most efficient since messages are routed directly to the appropriate server avoiding any
additional hops.
This chapter describes how to configure your environment to optimize the routing of Web services within a cluster. Use of the HTTP cluster servlet for the front-end SOAP
router is described. The in-place SOAP router is also enabled and is used in the event the HTTP cluster servlet is not available or has not yet been initialized.
A Note About Persistence While it is possible to maintain state for a Web service using the HttpSession as
described in Section 18, Programming Stateful JAX-WS Web Services Using HTTP
Session, in some cases this simple persistence may not be robust enough. Advanced
Web services features like reliable messaging, MakeConnection, secure conversation, and so on, have robust persistence requirements that cannot be met by using the
HttpSession alone. Advanced Web service features use a dedicated persistence implementation based on the concept of a logical store. For more information, see
Section 6, Managing Web Service Persistence. At this time, these two approaches to persistence of Web service state are not
compatible with each other. If you choose to write a clustered stateful Web service using HttpSession persistence and then use the advanced Web service features from
that service either as a client or service, Oracle cannot guarantee correct operation of your service in a cluster. This is because HttpSession replication may make the
HttpSession available on a different set of servers than are hosting the persistence for advanced Web service features.
Note: When using MakeConnection, as described in
Section 3.6, Using Asynchronous Web Service Clients From Behind a Firewall
MakeConnection , only front-end SOAP routing can guarantee
proper routing of all messages related to a given MakeConnection anonymous URI.
Managing Web Services in a Cluster 8-3
8.2 Cluster Routing Scenarios
