RM Sender/Receiver as High Available (HA) Components

[ropalka]

This dev forum topic will accumulate investigation results of research on

RM Sender/Receiver as High Available (HA) Components

It relates to bug

http://jira.jboss.org/jira/browse/JBWS-1976

and was initiated by the following discussion

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=126278

[ropalka]

First identified problem is HA itself. Imagine the following usecase:

Client sends WS-RM message to a webservice endpoint that is not available.

The default AS behaviour in such case is 404 (resource N/A).

To overcome this problem here are the potential solutions that comes into my mind:

1) Deploy a special servlet that would do the following steps:
* will match all http(s) requests that would result in 404 on running AS instance (is it doable?)
* will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)

2) Deploy a special servlet that would do the following steps:
* will reside on /wsrm/* web context
* all "GET WSDL" http(s) requests would return a modified WSDL document to reference the endpoint using /wsrm prefix for web context. (Of course only if such WSDL exists - otherwise it would return 404.)

Example:

client request GET .../wsrm/ctx/endpoint?wsdl
special servlet request GET .../ctx/endpoint?wsdl
 RETURN modified WSDL or 404 (if above WSDL isn't available)

* will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)

For both above approaches it is supposed to use ServletContext.getContext() method to gain access to the context for various parts of the server, and as needed obtain RequestDispatcher objects from the context.

[ropalka]

Second identified problem is HA WS-RM in combination with WS-Security.

HA WS-RM must reside on top of transport layer (this results from WS-RM specification).
Current WS-Security and WS-RM un/marshalling processings reside in JAX-RPC/JAX-WS handlers.

In order to support HA WS-RM plus WS-Security joint combinations (as required by e.g.
Microsoft Web Services Interop Plug Fest Scenarios) it is necessary to move both
WS-RM and WS-Security one layer lower in the processing chain i.e. implement it
in transport un/marshallers because of the following two requirements:

WS-Security processing must be the last/first thing in client and endpoint
outgoing/incoming processing chain.

HA WS-RM must reside on top of transport layer

[ropalka]

It's not possible to move WS-Security to the transport layer. The reasons are:

* WS-Security is implemented in JAX-WS/JAX-RPC handlers
so there's tight junction of WS-Security with MessageContext.
And MessageContext is constructed during the request/response
huge processing.
* WS-Security is highly configurable from Endpoint point of view.
Users can specify custom WS-Security configuration for particular
port or port operation. In transport layer the information i.e.
operation that will be executed is unknown.

[ropalka]

Third identified problem is ESB integration with JBossWS.
Both org.jboss.soa.esb.actions.soap.SOAPProcessor
and org.jboss.soa.esb.actions.soap.WebserviceContractPublisher
replace our servlet transport layer.

To be more precise:

SOAPProcessor uses method

org.jboss.wsf.spi.invocation.RequestHandler.handleRequest
(
 Endpoint endpoint,
 InputStream inputStream,
 OutputStream outputStream,
 InvocationContext context
)

and WebserviceContractPublisher uses method

org.jboss.wsf.spi.invocation.RequestHandler.handleWSDLRequest
(
 Endpoint endpoint,
 OutputStream output,
 InvocationContext context
)

directly from ESB internals.

What about the WebserviceContractPublisher it even modifies the
JBossWS returned WSDL contract and rewrites it to use ESB for
messages exchange.

[ropalka]

It's not possible to move WS-Security to the transport layer.

We decided to decouple WS-Security from handlers and provide generic interace for accessing WS-Security from other system components. Related bug is:

http://jira.jboss.org/jira/browse/JBWS-2022

When this bug will be fixed there's no problem with WS-Security anymore.

[ropalka]

First identified problem is HA itself. Imagine the following usecase:

Client sends WS-RM message to a webservice endpoint that is not available.

The default AS behaviour in such case is 404 (resource N/A).

To overcome this problem here are the potential solutions that comes into my mind:

1) Deploy a special servlet that would do the following steps:
* will match all http(s) requests that would result in 404 on running AS instance (is it doable?)
* will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)

2) Deploy a special servlet that would do the following steps:
* will reside on /wsrm/* web context
* all "GET WSDL" http(s) requests would return a modified WSDL document to reference the endpoint using /wsrm prefix for web context. (Of course only if such WSDL exists - otherwise it would return 404.)

Example:

client request GET .../wsrm/ctx/endpoint?wsdl
special servlet request GET .../ctx/endpoint?wsdl
 RETURN modified WSDL or 404 (if above WSDL isn't available)

* will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)

For both above approaches it is supposed to use ServletContext.getContext() method to gain access to the context for various parts of the server, and as needed obtain RequestDispatcher objects from the context.

We (JBossWS team) brainstormed new and better HA solution ;)
The solution is the following:

Server side:
* we will provide two types of RMProxy (secured/unsecured)
* this RMProxy will implement Provider and MBean
* the secured RMProxy will have WS-Security handler in the handlers chain
* each RMEnabled endpoint must register itself to the RMProxy (using JMX)
* RMProxy will handle only registered endpoints
* RMProxy will use RMReceiver internally to ensure HA and QoS
* RMReceiver will forward endpoint invocations to RMEndpointInvoker
* RMEndpointInvoker will do endpoint invocations according to message addr. headers

Client side:
* WS-Security will move to the transport layer
* WS-RM handler will move to the transport layer

Both server and client side will survive and recover from restarts in next RM versions.

[ropalka]

Second identified problem is HA WS-RM in combination with WS-Security.

WS-Security processing must be the last/first thing in client and endpoint
outgoing/incoming processing chain.

HA WS-RM must reside on top of transport layer

This will not be the problem anymore. WS-Security will be decoupled from handlers and will provide standard interface to handle WS-Security from other system components.

On client side both WSRM-Handler and WS-Security handler will be moved to the transport layer.

[ropalka]

Third identified problem is ESB integration with JBossWS.

This will be fixed in next JBossWS versions through SPI, see:

http://jira.jboss.org/jira/browse/JBWS-2024