Multiple Web Service Proxy using the same Front Side Handler

When changing a shared front side handler or Web Service Proxy, there has been a significant jump in memory, load, or cpu use by the device.

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, all WSDLs used by the linked configuration will trigger a recompilation of the WSDLs.

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 device will 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 is taken up/down or changed, all Web Service Proxy services sharing that handler are going to trigger a recompile of all WSDLs used by those services.
• The WSDLs will 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.
  

Best practices to consider in this configuration:

• 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 compared 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 the TCP port is up.
  Rather than simply querying the port with a simple TCP layer port check a url and specific request/response can be used. Issue something like an HTTP Head /path/to?wsdl to query the wsdl or further urls that would confirm both the port and content are working is great to have.
  
• 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.