Web Service Deployment Tutorial (How to deploy your web services into B2J)

Author: Antony Miguel, Last Updated 21st April 2006

If you found this tutorial useful or lacking in any way or if you think there are certain areas which could be better explained or more fully explained please Let Me Know.

---

B2J uses a single system to extend the engine in a variety of ways. Under the org.eclipse.stp.b2j.core plugin folder there is a folder called conf. This folder is expected to be in the folder that B2J is run from (it's working directory or current directory) and contains a variety of configuration information.
The conf folder contains any number of other folders. Each of these folders is one B2J extension. The Default folder contains all the standard B2J extensions including Daemon and HTTP proxy configurations, standard WSDL bindings such as WSIF Java and SOAP, a standard WSDL resolver and the standard Session Transport (TCP/IP).
Click here to view the latest Default B2J extension conf.xml file in CVS

---

To create your own extension, create a new folder under the conf folder and create a new conf.xml file with a root node called <Dependencies>.
Under this root tag you should create an ID tag and a Version tag. This identifies your B2J extension. Regardless of what the folder is called, if B2J finds two extensions with the same ID it will ignore all but the latest version of that extension.
The ID of your extension can be any string you like. Generally speaking it is probably a good idea to practice some form of namespacing such as prefixing your extension ID with 'com.yourcompany.yourextension' to prevent conflicts with extensions from other vendors.
The Version of your extension is of the form [Integer][[dot][Integer]]*. This basically means it must be something like 1 or 1.2.3 or 5.3.2.5.2 where the first number denotes the highest version point (so 4.0.1.1 would override 3.3 for example). If you're not sure what all this means you can just use a single number for your version and increment it each time you make some changes.

---

Since you wish to make some JARs available to BPEL programs running in the B2J engine, you should now add a Resources tag under the root element. Under this tag you can add as many Resource tags as you like, each containing a JAR tag with a path to your JAR in it. Note: the path to your JAR file is relative to your extension folder under the conf folder. This means you can put JARs directly alongside your conf.xml file and reference them as './MyJar.jar'.
Please be careful to specify the correct case for your JAR files as on some operating systems case is relevant for the filesystem.

---

In many cases, if you are creating some kind of library or standard web service to be distributed with B2J you will want to pair some WSDL files with your implementation. You could just make these WSDL files available on the internet and let users import them directly. However, an easier solution for the user is to package the WSDL files with your B2J extension and create a WSDL file resolver.
Note that all in this section that applies to WSDL files also applies equally to XSD files - a WSDL import resolver can also resolve XSD imports
When resolving import URIs for WSDL and XSD files, the B2J BPEL compiler will check to see if any of the registered WSDL file resolver extensions can resolve the WSDL file rather than having to go via the internet and try to download the file. You can therefore register your WSDL file resolver to resolve any WSDL files you want to bundle and the BPEL compiler won't need to use the internet.
To provide a WSDL file resovler, create a tag named WSDLResolvers under the root tag in your conf.xml file. Under that tag you can create as many WSDL file resovlers as you like (although each resolver can resolve as many WSDL files as it likes, so in most cases just one will do). Create a tag under WSDLResolvers called WSDLResolver. Under this tag you should create two further tags: Name and Class.
The Name tag is any string you like to identify your WSDL file resolver. This name is used if errors occur while the BPEL compiler is trying to resolve WSDL files via your resolver.
The Class tag must specify a fully qualified classname to a class that implements the interface org.eclipse.stp.b2j.core.publicapi.extension.wsdlexport.WSDLExportResolver
Click here to view the latest WSDLExportResolver in CVS
This interface has three methods: canResolve, getWsdl, getBaseUri. By implementing these methods your WSDL resolver can provide the BPEL compiler with any WSDL is asks for.
To get a reference to a file in your extension's folder (e.g. a WSDL or XSD file to pass back to the BPEL compiler) you can use the class org.eclipse.stp.b2j.core.publicapi.B2JPlatform. The method getDependencyInfo returns a B2J extension given any ID string (e.g. B2JPlatform.getDependencyInfo("com.yourcompany.yourextension") ). This in turn has a method getRelativePath which allows you to get an absolute reference to any path relative to your extension folder (e.g. B2JPlatform.getDependencyInfo("com.yourcompany.yourextension").getRelativePath("/WsdlFiles/MyWsdl.wsdl") ).
For example code, see the default WSDL import resolver extension in the Default B2J extension conf.xml file.
Click here to view the default WSDL resolver extension StandardExportResolver in CVS
Your class implementing WSDLExportResolver should be contained within one of the JARs you referenced earlier in the Resources section of the conf file (see above for more details).

---

The cases we have covered so far allow you to expose a web service with a Java implementation to the BPEL running in the B2J engine. In some cases, you may wish to expose services which are not located where the runtime engine is located, but instead are located where the runtime engine client is located (e.g. the Eclipse Workbench).
In such cases, you can create an extension to tell B2J that it must run some class of yours to launch your client-side service, before running the BPEL inside the engine. In this way, the running BPEL can use the standard B2J engine web services to get a reference to the client host and then use SOAP to connect back to these services to use them.
In this way, you can run distributed BPEL processes on the B2J engine but you can have the various parts of the B2J engine connect back to your client side SOAP service and use it for any purpose.
To get B2J to launch some of your code before each BPEL process run, create a new tag PreRunServices under the root tag in your conf.xml file. Under this tag you can create multple PreRunService tags, all of which will be run before each BPEL process is run.
Create a PreRunService tag and create two further tags underneath it: Name and Class.
The Name tag can be any string you like.
The Class tag must be a fully qualified reference to a class implementing the interface org.eclipse.stp.b2j.core.publicapi.prerun.PreRunService. The class you reference must be contained within one of the JAR files you referenced earlier on in the Resources section of the conf file.
Click here to view the PreRunService interface in CVS

If you found this tutorial useful or lacking in any way or if you think there are certain areas which could be better explained or more fully explained please Let Me Know.