Apart from sessions in which an overview of a certain topic is presented, JavaOne also had a few sessions in which the audience got the chance to actually do some work theirselves. These so called labs typically took up two hours in contrast to "normal" sessions that took up one hour. I attended two of the labs. In this article I will tell you all about "Dynamic Service Composition with OpenESB" that took place on the third day of JavaOne.
Line out of the lab
Tuhin Kumar and Rupesh Ramachandran, both Sun Microsystems, hosted the lab aided by several other people. The lab started with a presentation about the basics of SOA and BPEL as well as a short overview of OpenESB. The use case presented in the lab was a full-functioning JavaOne conference survey/poll application. The idea was that the audience would create a Composite Application that connects to an existing MySQL database to push the results of a small survey. The lab presenters already prepared a Petaho application that would retrieve the survey results out of the MySQL database and show them in a few plots. The survey could be submitted in two ways. The first way was using the built in Composite Application tester, the second way was a prepared web application that calls the Composite Application via a web service call.
Creating the BPEL application
The Sun folks already prepared the whole infrastructure to do the lab. This means they had installed a central MySQL database with a "javaonedb" database on it. On the lab machines NetBeans 6.1 and GlassFish v2 with OpenESB were already installed and configured. Everything was setup for us to get going. The first exercise was to build a BPEL module that would take all the answers to the survey and return success. The second exercise was to enhance the BPEL module to store all survey answers in the MySQL database. At the end of the first exercise, the BPEL module was loaded into a new Composite Application that can be deployed to GlassFish.
Unfortunately the lab was done on pre-installed machines in the lab room. So I had to recreate the BPEL module to be able to add a screenshot of it to this article. Fortunately a CD was made available with all labs on it so I was able to use the prepared WSDL document that defines the web service on which the BPEL process is built. This is what my BPEL process looks like
The process doesn’t do much yet. It only consumes the input that was passed on with the web service call to the javaOnePoll web service. The assign in between the receive and reply only returns a pre-defined string as can be seen in this image
However, this still is a valid BPEL process! And it will run in a JBI compliant esb, like OpenESB, if deployed correctly.
Deploying to OpenESB
The module I created above is a Service Unit. This is the smallest deployable unit for JBI containers. In order to deploy it, the Service Unit must be encapsulated in a Service Assembly. Basically, a Service Assembly is a zip file containing Service Units and a deployment descriptor. In NetBeans, such a Service Unit is also refered to as a Composite Application or as a Composite Application Service Assemble (a.k.a. CASA or C.A.S.A.). So, the steps to deploy the BPEL process created a bove is to create a CASA project, add the BPEL module to it and deploy to e.g. OpenESB. These steps result in yet another graphical representation shown in this image:
The graph indicates that whenever the javaOnePoll web service is called, the request is passed on to the CaptureJ1Polls BPEL module. Building and deploying the Composite Application to OpenESB results in the following output in the NetBeans log:
Deploying a service assembly...
Starting a service assembly...
BUILD SUCCESSFUL (total time: 14 seconds)
Testing the Composite Application
Now the Composite Application is deployed we can test it with the testing facilities that NetBeans provides. Creating such a test case can be done by right clicking the Test node under the Composite Application tree in NetBeans and it involves three steps. The first step is to provide a name for the test case. I chose JavaOnePollTest. The next step is to select the WSDL file that the test will be based on. Here the WSDL file that was provided for the lab needs to be chosen. The final step is to choose the web service operation that needs to be tested. In this case the JavaOnePollOperation needs to be selected.
NetBeans will now create an input.xml file based on the WSDL. The values in this file can be adjusted to your needs. Here’s the one I used to test my Composite Application:
<jav:Name>Wouter van Reeven</jav:Name>
The rating values range from 1 (bad) to 3 (excellent). Right clicking the
and selecting Run generated this output
<?xml version="1.0" encoding="UTF-8"?>
Connecting to a database
The next exercise was to store the input values of the web service call into a database. During the lab, MySQL was used (of course, Sun recently acquired MySQL) but it should make no difference what database is used. To prove that, I will try to store the data in an Oracle XE database. The first steps involve creating the database schema and making a connection from GlassFish to that schema. This is very trivial stuff and I will not show you how to do that. If you have troubles making the connection from GlassFish to a database, check out one of my previous blog entries.
In order to be able to store the data to the database, we need to setup a partner link to the database. Every partner link is based on WSDL so we need to create a WSDL based on the database. NetBeans has a nice wizard for this. To start the wizard, go to the CaptureJ1Polls project and choose File -> New File -> SOA -> WSDL From Database
Follow the steps in the wizard to create the WSDL. There is one tricky part to it. In the final screen you need to provide the JNDI name of the GlassFish datasource that connects to the database by yourself. I hope the NetBeans team will extend this screen in the future so the available JNDI names are presented in a drop down list and the possibility to create a new data source will be available too. This is all possible in Java EE project wizards so it shouldn’t be too hard to create that here too.
With the newly created WSDL it’s not hard to create a partner link in our BPEL module. Reopen the CaptureJ1Polls BPEL diagram if closed and drag and drop the JavaOnePollsTable WSDL file to the partner link lane to the right (or left) of the BPEL diagram. Next, an Assign activity needs to be added before the Invoke so the data that was passed on to the web service can be passed on to the database. The final BPEL diagram looks like this
The mapDataToDB Assign activity is shown with warnings due to a namespace mismatch that can safely be ignored. The new Assign activity itself looks like this
After recompiling both the CaptureJ1Polls and the J1PollCASA projects, the J1PollCASA project looks like this
Testing the Composite Application again goes ok and using SQL Developer I can now see the data in the database
NetBeans provides a very good graphical editor for orchestration of Business Process Modeling and for creating Composite Applications. The facilities for laying out BPEL diagrams, Assign activities and XSTL mappings are very easy to use and provide powerfull (BPEL related) tools. I will need to do a LOT more investigation, though, to find out all the details.
By the way, on May 22, Alexis Moussine-Pouchkine from Sun in Paris will come over to our company to do a presentation about OpenESB. After that I will do a presentation on NetBeans and BPEL and Composite Applications. If you are interested to attend this event and live in (or close by) the Netherlands, then please visit our agenda for more info and how to subscribe.