The two actions we have covered so far have discussed the invocation of remote web service endpoints, but what if the endpoint is deployed within the same server? We can still use the previous actions to invoke the endpoints but this will incur a cost, both from the network access at the transport layer and from any resource pooling on the receiving side.
The SOAPProcessor action provides a simple, optimized mechanism which allows the invocation of a web service within the same server but without taking any additional performance hit.
The ability to invoke co-located web services lies within the org.jboss.soa.esb.actions.soap.SOAPProcessor action class. The input to this action is an ESB message which contains the raw SOAP request as its payload, allowing the indirect invocation of the web service through any listeners configured on the service.
In addition to providing indirect access to the web service endpoint, the SOAPProcessor action will also expose a WSDL if the service contains a HTTP or
JBoss Remoting gateway, allowing the service to act as a proxy for the target web service.
A minimal configuration using this action would look like this:
<action name="JBossWSAdapter"
class="org.jboss.soa.esb.actions.soap.SOAPProcessor">
<property name="jbossws-context" value="webservice_war"/>
<property name="jbossws-endpoint" value="BookService"/>
</action>The properties which can be configured are as follows:
jbossws-endpoint: The name of the JBoss WS endpoint that theSOAPProcessoris exposing. This property is required.jbossws-context: The name of the web service's deployment context. This property is optional.rewrite-endpoint-url: The default action, when exposing the WSDL through one of the gateways, is to rewrite the URL so that it appears to come from the gateway's endpoint. Sometimes this behavior is undesirable, for example when the web service container has already been configured to override the endpoint to that of a load balancer. Setting this tofalsedisables the rewriting capabilities.