[Blog Post] WSO2 ESB Proxy Services for JAX-WS Backends

The proxy service concept is one of the main useful components in WSO2 ESB. There are a number of variant formats available to create proxy services such as pass-through proxy, WSDL-based proxy, security proxy, etc. When creating a proxy service it is possible to assign a WSDL file to describe the service and this simplifies the service invocation from the client side; usually client side tools are capable of understanding the WSDL file associated with the proxy service so that they can generate client codes or can generate expected sample messages . As an example, once the WSDL is given SoapUI can generate the expected sample messages. When a message is sent to the ESB and if it is dispatched to a WSDL-based proxy service then it's required to dispatch the message to a operation within the service in order to redirect messages to the backend service; in this case dispatching to the service level only (without dispatching to a operation) is not sufficient. But if you don't associate the WSDL file during the proxy service creation, then to redirect message to the backend service-level dispatching is sufficient.

In a user's point of view there are some use cases in which operation level dispatching is useful.

1. Apply QoS features such as throttling, security per operation level instead of service level.

2. Associate WS-Policy per operation instead of per service.

Both service and operation dispatchers use information available with incoming messages to find correct service/operation, those information can be transport level properties or message level properties some of the given below.

Both service and operation dispatchers use information available with incoming messages to find correct service/operation, those information can be transport level properties or message level properties some of the given below.

1. Request URI
2. SOAPAction HTTP header
3. WS-Addressing headers
4. QName of the first child under SOAP Body element.

Here, first it tries to dispatch messages based on transport level properties and if it fails it tries to perform dispatching based on message properties such as QName of the root element. Please note if it's possible to complete dispatching only based on transport level details that improves overall performance of the invocation because there is no need to build the message to find dispatching information. But in practical situations, due to various reasons, it is not possible to complete dispatching only by using transport level details once such a common use case is described below.

Use case -1

In JAX-WS specification it's not mandatory to generate unique SOAPAction property per each operation unless developer specifically annotate the SOAPAction with SEI, by default for JAX-WS services it generate "" as the expected value for all operation. Assume you create a WSDL associated proxy service for JAX-WS service and client send following data to the proxy service.

• Valid SOAP message
• Request URI up to service level ( e.h https://host/proxyServiceName )
• HTTP SOAPAction =""

In the above case using request URI it is possible to find the correct service, but in order to find the correct operation it's required to build the message and look at the QName of the first child under SOAPBoday; this can affect overall performance but still successful service invocation is possible.

Starting from 4.6.0 version, WSO2 ESB uses new HTTP transport called pass-through which provides anvery high performance level; this blog post provides insights into pass-through transport but in simple terms it uses shared buffer and avoids message building at all cost. Now this new transport mechanism affects the above described Use case -1 because now message building is not possible and hence operation dispatching will fail and messages will not process further. We have addressed this limitation in the upcoming ESB 4.8.0 version. Before I describe the solution, let me introduce some of the workarounds that can be used with the 4.60 and 4.7.0 versions.

For ESB 4.6.0/4.7.0

1.) Append operation name at the end of the Request URI so that request URI can be used to dispatch both service and operation

  https://host/proxyServiceName/OperationName  

2. If it's possible modify backend JAX-WS SEI so that each operation having unique SOAPAction value.

 @WebMethod(action="XXXX")   

3. Move back to NHTTP transport instead of Pass-through in NHTTP on-demand message building is possible.

This is what you have on ESB 4.6.0

 
< transportSender name="http" class="org.apache.synapse.transport.passthru.PassThroughHttpSender">
   <parameter name="non-blocking" locked="false">true</parameter>  
 </transportSender>
 <transportReceiver name="http" class="org.apache.synapse.transport.passthru.PassThroughHttpListener">
   <parameter name="port" locked="false">8280</parameter>  
   <parameter name="non-blocking" locked="false">true>/parameter>
   <parameter name="httpGetProcessor" locked="false">org.wso2.carbon.transport.nhttp.api.PassThroughNHttpGetProcessor</parameter>     
 </transportReceiver>  

Replace the above code using the following.

<transportReceiver name="http" class="org.apache.synapse.transport.nhttp.HttpCoreNIOListener">
   <parameter name="port" locked="false">8280</parameter>  
   <parameter name="non-blocking" locked="false">true</parameter>
   <parameter name="httpGetProcessor" locked="false">org.wso2.carbon.transport.nhttp.api.NHttpGetProcessor</parameter>
   <parameter name="disableRestServiceDispatching" locked="false">true</parameter>  
 </transportReceiver>  
 <transportSender name="http" class="org.apache.synapse.transport.nhttp.HttpCoreNIOSender">  
   <parameter name="non-blocking" locked="false">true</parameter>  
 </transportSender>  

The following two diagrams illustrate runtime processing when both service and operation dispatching are required and only service dispatching required scenarios.

For ESB 4.8.0 or any future versions

Now let me discuss the improvements we have done in ESB 4.8.0. Starting from this version, users have the control to specify whether the proxy service should expect operation dispatching or not. In situations like Use case -1 users can now disable operation level dispatching and it will still be possible to use high-speed pass-through transport. There is a new parameter introduced called "disableOperationValidation" to control operation dispatching on proxy service. Please refer to the following sample.

<proxy name="JAXWSServiceProxy">   
   <target>   
   <outSequence>   
    <send/>   
   </outSequence>   
   <endpoint>   
    <address uri="XXXXX"/>   
   </endpoint>   
   </target>   
   <publishWSDL uri="XXXX">   
   <parameter name="disableOperationValidation" locked="false">true</parameter>   
  </proxy>  

Source : https://ssagara.blogspot.com/2013/08/wso2-esb-proxy-services-for-jax-ws.html