Take control with WS-BPEL

Page: 1 2 3 4 5 6 7 December 11th, 2009 by Henri Bezemer

My quest for a good WS-BPEL engine was not a short one. I decided to look for a WS-BPEL engine as part of an ESB product. I think an ESB is the natural habitat for a WS-BPEL engine. WS-BPEL specifies the communication is has with its partners on the abstract level of WSDL port types. An ESB allows WS-BPEL to communicate with its partners via any of the supported transports, thus providing the necessary concrete level of communication. To demonstrate how powerful the combination of WS-BPEL and ESB can be, I’ve bound the web service call to the back-office system to the Open ESB File BC, which will produce a CSV type of output file. The back-office system should be scheduled to import and process this file. This is probably the most basic form of interaction between ESB and legacy technology. Note that in a more realistic example, the back-office system would produce a journal type of file, which the ESB imports and forwards to the WS-BPEL engine, which in turn would continue or terminate the processes based on what happened in the back-office system. This is how WS-BPEL can really help to get a grip on cross-system and cross-department processes.

Some ESB’s support the JBI (Java Business Interface) specification. In theory, JBI components that come bundled with such an ESB (for instance its WS-BPEL engine) can run on other JBI enabled ESB’s. However, there is a big change that the JBI components have dependencies on their own specific ESB platform, so full portability is – at this moment - a promise for the future. Still I decided to prefer an ESB with support for JBI.

I choose OpenESB 2.1 (a.k.a. GlassFish ESB) for the following reasons: it is open source (so I can try before I buy), it turns out to be quite stable (production quality), it is $upported (by Sun), it is well documented (for an open source product), it implements JBI and it is very tightly integrated with strong development tooling. I also took a look at the Apache “stack”, but I was a bit dissappointed with the lack of (documented) integration between the various layers of the stack (Geronimo, ServiceMix, ODE) and the lack of documentation in general. A short peek at the JBoss stack didn’t get me as enthusiastic as I am about OpenESB, so I decided to look at JBoss in more detail at a later moment. It amazes me that OpenESB isn’t much more popular at this moment! I understand that it shares a crucial component – the Metro web service stack – with Oracle’s strategic (formerly BEA’s) SOA product. In my opinion, OpenESB is a great open source ESB.

The development tooling mentioned above comes in the form of NetBeans. I’m not a NetBeans fan. I use Eclipse (with Maven) as my de facto Java development tool since version 2 came out. However, it is WS-BPEL that needs to be developed and not Java! I found that NetBeans provides an truly excellent WS-BPEL editor and a briliant ESB deployment tool. The deployment tooling (the CASA editor) is needed to create a JBI service assembly, which will be the vehicle to deploy the WS-BPEL and related artifacts to OpenESB. Actually, you can almost completely ignore the CASA editor, it does its work silently.

OpenESB 2.1 comes bundled with NetBeans 6.5. I took a quick look at NetBeans 6.7 because that offers standard integration with Maven. I have to say it looks promising, I was able to build one of my existing Maven based EJB projects without any problems. I think it is possible to integrate NetBeans 6.7 with OpenESB 2.1 but I didn’t try. Maybe in the future I’ll be converted from Eclipse to NetBeans, but for now I’ll stick with the WS-BPEL tooling.

If you decide to build the example in NetBeans, you have to create a new WS-BPEL project: File->New Project…, then choose the SOA category and a BPEL module project. All the example code goes in to this project. After right-clicking on the project, NetBeans lets you chose wizards for XML Schema, WSDL and WS-BPEL files. After starting a wizard change the proposed default name of the file to something more appropriate, finish the wizard and then, when the file opens in an editor window, replace the contents with the code supplied in this blog. If you have the CRM component up and running, you can import the WSDL into NetBeans by right-clicking on the project and choosing New->External WSDL Document(s)…

In the next part I present the XML schema’s that are necessary to build the example.

Previous pageNext page

One Comment

December 15, 2009 at 11:12 am BPEL_evaluator

1

Thanks for the example. I now heve a better understanding of correlation Keep up th good work!