[jbossws-dev] [Design of JBoss Web Services] - Re: RM Sender/Receiver as High Available (HA) Components

[richard.opalka@jboss.com]

"richard.opalka at jboss.com" wrote : 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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135553#4135553

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135553