Wednesday, March 26, 2008

Eclipse BPEL Project

Just wanted to give a rundown of the Eclipse (Europa) BPEL Project and my impressions at the moment. The eclipse bpel project is located at:

Eclipse BPEL Project


Having experienced most of my BPEL development in either TextPad (BPEL 1.0) or in the Cape Clear Studio solution (BPEL 1.1), the Eclipse BPEL Project was not too difficult to slide into. Here are the highlights:

- BPEL Project is only focused on BPEL 2.0. No BPEL 1.1 at this time.
- Overall GUI is nicely organized and employs a very similar look and feel to the BPEL Editor in Cape Clear.




-Assignment Editor in the current release M3, does not provide a graphical drill down to the schema element level. You can select your messages but no further.




-Activities are easily selected and placed in the panel. The Properties window needs to be visible to then edit those value.
-No tab to edit the BPEL directly with context sensitive help. I opened the BPEL in an XML Editor and flipped between the windows.
-XPath is done manually rather than created via the selection tool.
-PartnerLink defintion process is not as easy as in Cape Clear but it does generate an artifact WSDL file that includes the partnerlink definition so you do not need to muck up your WSDLs with the elements.

Issues that I have experienced:

1) Currently the Web Service Tools that is bundled with the BPEL Project appears to have a bug with imported schema. This is obviously unrelated to the BPEL Project but the full-lifecycle of developing the Service Contract and using this for the BPEL is not working properly. Currently have to use inline schema instead of importing.

What I haven't tried:

1) Deploying generated BPEL 2.0 into a container. Will try Apache ODE in either Axis or ServiceMix to confirm execution.

Tuesday, March 18, 2008

SOAPUI Benefits

As part of the previously mentioned Continuous Integration effort I am undergoing, an effective/simple approach to Unit Testing needs to be identified. JUnit works well when performing assertions on Java. When testing Web Services, I decided to look for alternatives. One alternative is to use XMLUnit as I described in an earlier post. In order to test for the current client, a different approach was in order. Their current QA Staff are not familiar with Web Services so a Web Services centric Testing tool is an additional requirement. SOAPUI available at www.soapui.org provides a very simple and capable Test environment. GUI, command line and JUnit integration are provided in the freely available version.

So currently my Continuous Integration looks like:

- CruiseControl invoking Ant Script
- Ant Script invoking:
- Build / Validation Process
- Deploy Utility
- Junit TestCase
- SOAPUI Project

More to come....

Thursday, March 6, 2008

OSS to the rescue for BPEL/ESB

Several of my customers are small independent start-ups that are heavily involved with OSS. Just recently a Web Service integration highlighted the amount of Java code necessary to broker interactions with external partners. The decision was made to examine the OSS marketplace for an ESB and BPEL development tools.

I will be examining the BPEL Project from Eclipse, Apache ODE and Apache ServiceMix. I was very suprised at the quality of Apache CXF and its inclusion in the ServiceMix container was one of the factors in proceeding with this evaluation.

The goal of the evaluation is to show the ability to compose a task service that will create users in two separate services (Apache CXF and Microsoft .Net). In addition, some of the mediation facilities will be examined for simplicity and flexibility.

Does anyone have thoughts on ServiceMix?

I may also attend a session at Sun related to their ESB/WS Tools next week. If I attend I will post my thoughts and how it rates with the niche Cape Clear solution and Apache solutons.

Continuous Builds with Web Services

In two of my current projects, I am working with clients that are moving to continuous builds from complete manual processes. What is a continuous build you may ask? Well anytime a change in the source code repository occurs, a build could be triggered and deployed to a development server. As part of the build process a suite of Unit Tests could be executed to confirm there is no regression in capabilities. Companies like Cape Clear employ this process to develop daily builds which are much improved in quality over the previous semi-automated processes.

The ingredients to this always falls into the same basic technologies and like most people OSS provides the answers:

- CruiseControl for the continuous build management
- Apache Ant for the build scripts
- JUnit for Unit Testing
- Some sort of Version Control Repository like SVN or SCM
- Web Service Container / ESB (Cape Clear or the like)

So is it difficult? Well I was suprised to see how quickly CruiseControl could be downloaded, started and configured through two configuration files (config.xml and build-.xml). In just a couple of hours the software was downloaded and a build was completed.

The necessary components to execute the build are the configurations described above but also the main build.xml that in the case of Cape Clear, invoked the Eclipse Buckminster Framework. This effectively creates a headless Eclipse Workspace and allows the ant script to run the validators, package the content, deploy it and test it. Since the Web Service/BPEL developer is not writing a compiled language, the validators are the key component in the build process.

Other things that I need to complete revolve around the rewriting of URLs or namespaces depending on which environment the build is being created for. Ant provides a soluton there via the replace feature which allows for the search/replace of tokens. This functionality is extremely helpful in complex BPEL where many partner services equates to many WSDL/endpoints. The other feature not complete is the execution of a JUnit test case using the Buckminster/Cape Clear launch feature.