Network Deployment (Distributed operating systems), v8.0 > End-to-end paths > Web services - Transaction support (WS-Transaction) > Use WS-Transaction policy to coordinate transactions or business activities for web services > WS-Transaction
Web services transactions, high availability, firewalls and intermediary nodes
We can configure the system to enable propagation of Web Services Atomic Transactions (WS-AT) message contexts and Web Service Business Activities (WS-BA) message contexts across firewalls or outside the WAS domain. With these configurations, you can distribute web service applications that use WS-AT or WS-BA across disparate systems. The topology that you use can affect the high availability and affinity behavior of the transactions.
Web services transactions (WS-AT or WS-BA) can use all the transactional high availability functions. This includes peer recovery of a server by another active server in the same cluster, and redirection of protocol messages to the peer server to complete units of work for the failed server.
To enable high availability for web services transactions, see the topic about configuring transaction properties for peer recovery. For general information about high availability and peer recovery in WAS, see the topic about transactional high availability.
When web services transactions are distributed between applications in different servers or clusters or to systems that are not WAS systems, consider the transaction-routing affinity of web service requests, as well as the impact on high availability of the transaction service on WAS. If a remote client sends a series of transactional requests to a target service that is deployed in a cluster, usually you want the first request to establish a transactional affinity from the client application to the target server, such that subsequent requests in the same transaction are delivered to the same target server. When the transaction completes, the transaction protocol messages are also sent to this same target server, unless and until transaction high availability failover occurs.
The topologies that are available to you are as follows:
Direct connection
Use this topology for non-clustered configurations. No intermediary node exists in this topology. The client communicates directly with the specificWAS on which the target service is hosted. This topology supports transaction affinity and high availability, but only when the client runs on a WAS v6.0.2 or later in the same administrative cell as the target service.
Proxy Server for IBM WAS
Use this topology when the client is not part of the same administrative cell as the target service, and you require transaction affinity or transaction high availability. In this topology, the client communicates with a Proxy Server for IBM WAS, which dynamically routes the client requests and web services transaction protocol messages to the appropriate server in a WAS cluster. The proxy server is configured in the same administrative cell as the target service.
The proxy server provides the routing support for transaction high availability and affinity at the edge of the administrative cell. As for any HTTP proxy configuration, provide HTTP endpoint URL information, that is, configure the HTTP server URL prefix for the target web service module.
Also, configure the proxy server for web services transactions, that is, configure it to deliver web services transaction protocol messages to the appropriate WAS. To do this, configure the transaction service HTTP proxy prefix, which is described in the topic about enabling WAS to use an intermediary node for web services transactions.
HTTP server, such as IBM HTTP Server
Use this topology when transaction high availability and affinity routing is not required by the client, for example because the target service is deployed to a non-clustered server.
In this topology, the client communicates with an HTTP server, which always routes the client requests and web services transaction protocol messages to a specific WAS. As for any HTTP proxy configuration, provide HTTP endpoint URL information, that is, configure the HTTP server URL prefix for the target web service module. Also, typically configure the HTTP server for web services transactions, that is, configure it to deliver web services transaction protocol messages to the appropriate WAS.
To do this, configure the transaction service HTTP proxy prefix, which is described in the topic about enabling WAS to use an intermediary node for web services transactions.
The HTTP server cannot provide either affinity or high availability for transactions. However, transactional integrity is assured, because recovery processing occurs after the failed server restarts.
We can still enable high availability on the WAS. Non-WAS clients that access this server through an HTTP server cannot benefit from the high availability of transactions, but other clients that access the same server can. When the client is on WAS, full high availability capability is still available if the server that acts as the client can address transaction protocol messages directly to the application server without the HTTP proxy routing those protocol messages. In this specific scenario, not specify a transaction service HTTP proxy prefix.
You might have an existing HTTP server that is a reverse proxy for all received messages, including transaction protocol messages. If you want this server to have the high availability and workload management capabilities of a Proxy Server for IBM WAS, create a Proxy Server for IBM WAS and configure the HTTP server to route all requests to the proxy server, as in the following scenario.
HTTP server in conjunction with a Proxy Server for IBM WASr
Use this topology when the client is not part of the same administrative cell as the target service and you require transaction affinity or transaction high availability. The topology is similar to the Proxy Server for IBM WAS topology, but supports the use of any HTTP server as the external reverse proxy.
In this topology, the client communicates with an HTTP server, which you configure, by routing requests from a plug-in to a proxy server, to forward the client requests and web services transaction protocol messages to a Proxy Server for IBM WAS. The proxy then dynamically routes the requests to the appropriate server in WAS. The proxy server is configured in the same administrative cell as the target service.
The proxy server provides the routing support for transaction high availability and affinity at the edge of the administrative cell. As for any HTTP proxy configuration, provide HTTP endpoint URL information, that is, configure the HTTP server URL prefix for the target web service module.
Also, configure the HTTP server and proxy server for web services transactions, that is, configure them to deliver web services transaction protocol messages to the appropriate WAS.
To do this, configure the transaction service HTTP proxy prefix, which is described in the topic about enabling WAS to use an intermediary node for web services transactions.
Use WS-Transaction policy to coordinate transactions or business activities for web services Transactional high availability WS-Transaction
Configure an intermediary node for web services transactions Enable WAS to use an intermediary node for web services transactions Configure web server plug-ins Configure transaction properties for peer recovery Create a proxy server Route requests from a plug-in to a proxy server Configure transaction properties for an application server
Related
Provide HTTP endpoint URL information