Multiple Web Service Proxy services using the same Front Side Handler

Technote (FAQ)

This document applies only to the following language version(s):

Question

How does the DataPower device react or work when one or more front side handlers are shared by multiple Web Service Proxy objects?

Cause

When you change a shared front side handler or Web Service Proxy, you notice a significant jump in memory, load, or cpu use by the device.

Answer

When multiple Web Service Proxy services share the same front side handlers, they become linked. When a Web Service Proxy or front side handler within a linked configuration is reloaded, this will trigger a recompilation of all WSDLs used by the linked configuration.

Any time that you click Apply within the WebGUI, or make a change via the CLI, on either the Web Service Proxy or the front side handler used by the Web Service Proxy services, the appliance can trigger a recompile of all referenced WSDL's.

Notes:

When a front side handler is shared by multiple Web Service Proxy services, all services are then linked.

When a front side handler changes operational state up or down, all Web Service Proxy services sharing that handler will trigger a recompile of all WSDLs used by those services.

The WSDLs may not show up immediately in the style sheet cache on that initial compile. Rather, they will show up or change on the first client request.

If you have a log target subscribed to the proper events you will be able to see the following:

Because a front side handler can be shared by multiple services (Web Service Proxy, MPGW, etc), there is a chance that some services may not be completely up by the time the front side handler port is listening. This can be due to slow or large WSDLs fetched over a network, complex service configurations, etc. Many services such as MPGW can come up immediately and may never see this timing behavior, contrasted to a Web Service Proxy that has to fetch a remote multi-megabyte WSDL from a remote web server.

This front side handler behavior is why many clients will use more complete health checks, such as HTTP HEAD requests to query the WSDL, rather than just checking to see if the TCP port is up. Rather than simply querying the port with a simple TCP layer port check, a content specific request/response can be used. An HTTP Head /path/to?wsdl request to query the wsdl would confirm the WSProxy is up.

Using a gateway service or reducing the number of WSProxy services sharing the same front side handler will also help reduce complexity and the tremendous memory footprint required when making changes to this type of configuration.