A common use case for an ESB is to use it as a web service proxy.  This article is an attempt to show one way to create a web service proxy with SOA-P 4.3 without writing any code (for the ESB portion).

Prerequisites:

Install Java 1.5

Install SOA-P 4.3 GA

Install JBDS 2.0.0.CR1

Configure SOA-P as a server in JBDS

Install SoapUI 2.5 (optional, for testing the web services)

We are going to do three main steps in this example:

1.)  Create and deploy a web service that we can proxy with the ESB.  You may have already created a web service and can skip this step if that is the case.

2.)  Create and deploy the ESB service that is the proxy for the web service in step #1.

3.)  Use a client to invoke the web service directly and also invoke the ESB proxy service (this is optional, but proves that what we did actually works)

Step #1

First, we need to use JBDS to create a new Dynamic Web Project that will be our Web Service

Now, we need to create a new Java class in our src folder that will be our JSR 181 web service implementation

Add our web method and JSR 181 annotations (don't you love JSR 181?)

Register our JSR 181 class as a servlet by editing the web.xml file so that JBoss will automatically deploy it as a web service

Right click on our SOA-P server and add this WebServiceProject to the server

To make sure our web service deployed correctly, we can look at the WSDL in a browser

That's it for Step #1, we now have a web service that we can create a proxy for!

Step #2:

Now we'll use JBDS to create an ESB project that will have an ESB service that acts as a proxy for this web service

Make sure the Target Runtime points to your SOA-P runtime - in this screenshot, I should have used a better name than JBoss 4.2 Runtime 1 for my SOA-P 4.3 runtime

When the new ESB project is created, it should automatically open the editor for the ESB project's jboss-esb.xml file.  Right-click on the Providers folder and add a JBR Provider, specifying the protocol and port.  JBR stands for JBoss Remoting and is the provider mechanism for creating an HTTP gateway in SOA-P 4.3.

Right-click on the Services folder and add our new proxy service

Make sure that the new service has the GLOBAL InVM scope so that we don't have to configure a non-gateway listener

Right-click on the Listeners folder and add a JBR Listener so that we can setup this service to use the HttpGateway we created in the Providers section

Make sure the new listener is marked as a Gateway (isGateway = true)

Right-click on the Actions folder and add a new generic action pointing to the HttpRouter that SOA-P 4.3 provides

Add two properties to the action:  endpointUrl and method.  The "endpointUrl" needs to point to the URL of the web service we want this proxy service to invoke.  In this case, I'm pointing it to the webservice created in Step #1 - you may point it to your own service if you have one.  The "method" is to specify that the SOAP envelope is going to be sent via HTTP POST as opposed to HTTP GET.

Make sure that the action chain is RequestResponse so that a response will be return to the ESB service's client

Right-click on the Actions folder and add a System Println action just so that we can see when the ESB service is invoked (this is optional but helps prove that our proxy is actually getting invoked)

Now we need to right-click on the server and add our ESB project to it - just like we would any other project

That's it!  Now we have a web service and an ESB proxy for that web service deployed.  Notice that to create and deploy the ESB proxy we did not have to write a single line of Java code or write a single line of XML.

Step #3:

To invoke the two web services (proxy and real web service), I'm going to use SoapUI, but you can use any client you like.  So, we'll start up SoapUI and create a new Project using the WSDL for the "real" web service just to make sure we can invoke it.

Runing the client shows that we get our "Hello" response from the real web service

Now we'll click on the URL in SoapUI and change it to the port of the ESB service and make sure we can invoke that as well

Now when we execute the SoapUI web service, we'll see the same response (because the proxy is just a pass through proxy) but if we look in the SOA-P console log on JBDS, we'll see that our ESB println action was invoked meaning that we actually did invoke the ESB which passed the request to the real web service (via HttpRouter) and then passed the response back to the SoapUI client.

That's it, we've now created a web service with JBoss and proxied it via the ESB.  Here are a couple follow-on notes:

1.)  Where's the WSDL for the ESB proxy service?  There isn't one.  However, you could take the WSDL for the real web service, change it's port (and host if you web service is on another machine) and then you have the ESB Proxy's WSDL.

2.)  What if I want to do more than just proxy, like maybe I want to transform the request after the ESB gets it but before I send it to the real web service, or maybe I want to transform the response after the real web service returns it but before the ESB proxy returns it?  No problem, add an action before the HttpRouter to transform the request and/or add an action after the HttpRouter to transform the response.  You can use XSLT via our Smooks transformation action (see the transform_XML2XML_simple quickstart for an example) or you can create a custom Java action to do the transformation.