8 Replies Latest reply on Mar 11, 2008 5:59 AM by Richard Opalka

    RM Sender/Receiver as High Available (HA) Components

    Richard Opalka Master

      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

        • 1. Re: RM Sender/Receiver as High Available (HA) Components
          Richard Opalka Master

          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.

          • 2. Re: RM Sender/Receiver as High Available (HA) Components
            Richard Opalka Master

            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

            • 3. Re: RM Sender/Receiver as High Available (HA) Components
              Richard Opalka Master

              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.

              • 4. Re: RM Sender/Receiver as High Available (HA) Components
                Richard Opalka Master

                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.


                • 5. Re: RM Sender/Receiver as High Available (HA) Components
                  Richard Opalka Master

                   

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


                  • 6. Re: RM Sender/Receiver as High Available (HA) Components
                    Richard Opalka Master

                     

                    "richard.opalka@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.

                    • 7. Re: RM Sender/Receiver as High Available (HA) Components
                      Richard Opalka Master

                       

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

                      • 8. Re: RM Sender/Receiver as High Available (HA) Components
                        Richard Opalka Master

                         

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