The SOAPProcessor action, formerly known as "JBossWSAdapter", allows you to expose JBossWS 2.x and higher Webservice Endpoints through listeners running on the ESB (“SOAP onto the bus”).
A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. This means that these Services are invocable over any transport channel supported by the ESB (http, ftp, jms etc).
In order to achieve this, ESB defines a "wrapper webservice" that maps calls to the target Service.
Let's see in practice how to use the SOAPProcessor action. If you have downloaded the ESB service bus
move to the folder "samples\quickstarts\webservice_producer". There you can see one example of a WebService Producer.
Let's take a look at the jboss-esb.xml configuration file
The first thing to notice is that JBoss ESB uses JBoss remoting interfaces as provider for http and socket transport. We'll explain later a bit more about jBoss remoting. In order to receive http/socket requests it's necessary to install a listener for this interfaces. This is achieved with the <jbr-listener>

Picture 1: JBoss ESB exposing WebServices over http,socket,jms protocols
Said that, the action needed to invoke the webservice is very straightforward. The action requires only one mandatory property value, which is the "jbossws-endpoint" property. This property names the JBossWS endpoint that the SOAPProcessor is exposing (invoking).
Notice : There's one optional property "rewrite-endpoint-url" which is not used in this sample. This property is there to support load balancing on HTTP endpoints, in which case the Webservice endpoint container will have been configured to set the HTTP(S) endpoint address in the WSDL to that of the Load Balancer.
The Web Service endpoint is deployed in the .esb archive as web application. It's made up of only one class and exposed 3 WebMethods:
ok time to deploy your .esb archive.
$ ant deploy
| 11:40:56,546 INFO [TomcatDeployer] deploy, ctxPath=/Quickstart_webservice_producer, warUrl=.../tmp/deploy/tmp51717Quickstart_webservice_producer.esb-contents/Quickstart_webservice_producer-exp.war/ 11:40:58,515 INFO [WSDLFilePublisher] WSDL published to: file:/D:/jbossesb-server-4.4.GA/server/default/data/wsdl/Quickstart_webservice_producer.esb/Quickstart _webservice_producer.war/GoodbyeWorldWSService51718.wsdl |
If everything was successful .esb archive is now available and the wsdl archive was generated.
Ok now the webservice is deployed but how the client interface knows which protocol can be used to interact with the WebServices ? this problem is solved by the ESB exposing a contract for the webservice.
This application lists URLs that can be used by your Webservice Client (e.g. soapUI) for accessing a Service's WSDL, enabling WSDL based invocation of the Service through an ESB Endpoint.
The SOAPProcessor Action publishes contract information by being annotated with the org.jboss.internal.soa.esb.publish.Publish annotation as follows :
If you want to inspect the Contract for the Webservice take a look at the Contract console at
http://localhost:8080/contract/

Picture 2: JBoss ESB Contracts console showing the available protocols for WebService endpoints
Connecting to your webservice
Last piece of the puzzle is the client which connects to the WebService. We'll skip the JMS sendMethod (which is a plain JMS client ) rather it's interesting to note how to connect to your remote listener:
This method used JBoss remoting framework : What is it about ? JBoss remoting is a core framework that provides remote services like remoting JMX MBeans, remoting EJBs, and so on. It supports an invocation model much more versatile then RMI or old-styled web services. There is no need to generate and compile a client-side agent for each service. As a result, JBoss Remoting provides the basis for more complex and heavyweight remoting frameworks.
JBoss Remoting defines the org.jboss.remoting.InvokerLocator class : this is the object that identifies the location of our service, as well as describing what transport protocol to use.
As you can see from the method sendMessageToJBRListener, the code is independent from the protocol: you simply feed the protocol : so for example if you use http, you'll use the JBR protocol "http://localhost:8765" , while for socket you'll use JBR protocol "socket://localhost:8888"
This is all you need in order to create a client that can be used to locate and connect to a remote service.












