My work on process engine benchmarking and standard conformance testing in the last year, building tools like betsy, motivated me too look deeper into portability aspects of service-oriented processes. With the capabilities of betsy growing more and more – we now can benchmark a total of eight engines, although not all of them can be rolled out to the public for licensing reasons – we are getting a more and more precise picture of the situation. To be more specific: There are now several process languages, BPEL, WF, BPMN, XPDL, which all provide an XML serialization to enable the portability of processes among virtually any environment. This is supposed to work even for exectuable process definitions, which should be readly deployable on different engines. The data we are gathering, however, cast severe doubt on that.
I wanted the results from the engine benchmarks to be a bit more useful to developers of processes, aiming at improving process portability, and for that reason wrote a tool called bpp, short for BPEL Portability Profile. You can check it out at its github repo. Basically, bpp is a static checker. It analyzes process defintions, highlights any portability issues it finds, and reports on that with a list of warnings. Now, the name of the tool does not come out of the blue. My intention was to have the tool work similar to and be more or less integrateable with the Web Services Interoperability Organization (WS-I) testing tools. The WS-I is known for building profiles that aim to enhance the interoperability of Web Services. In the same fashion, bpp implements a profile that aims to enhance the portability of process-oriented services. I want to defer the closer description of the profile to a future post, when I will also describe some results of using it. For now, I want to focus on how to use it. Fortunately, that is pretty easy!
Bpp is written in Java (well, mostly Java. There is quite some XPath involved as well) and uses gradle as build and execution system. I use the gradle wrapper, so everything you need to have installed is a JRE. When you execute the wrapper script, it will download gradle and install it to a temporary directory, download all dependencies (Saxon HE, basically), compile the code, and analyze whatever you told it to analyze. For the time being, I am supplying a
bat script, so the program will work on Windows systems. In case anyone needs it, supplying a similar script for Linux shouldn’t be much of a hassle. The command to execute the program looks like this:
$ gradlew run -Pargs="<ARGS>"
ARGS should be any valid path in the file system, either a single file or a folder. If you provide a folder, bpp will scan the folder and all its subfolders for files ending in
.bpel and will try to statically check these files. If you provide a single file, it will just look at that file. If the file contains something bpp can analyze (such as BPEL code), it will write a report file named
ANALYZED_FILE_NAME-report.xml in the same folder next to the analyzed file. This report contains whatever bpp found to be a portability issue. The tool also comes with a lot of sample BPEL processes (actually, these are test cases from betsy) in
/src/main/resources/, so you can test the tool for that folder. For instance, simply execute:
$ gradlew run -Pargs="src/main/resources/language-features/"
This command will analyze all sample files in the respective directory. A sample report looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <report xmlns="http://www.ws-i.org/testing/2009/03/report/" name="BPEL Portability Profile Test Report" timestamp="2013-05-29T09:58:46.505+02:00"> <analyzer> <profile> <name>BPEL Portability Profile 1.0</name> <revision>$Revision: 1.0 $</revision> <implementer name="Distributed Systems Group" location="http://www.uni-bamberg.de/en/pi"/> </profile> <environment> <operatingSystem name="Windows 7" version="6.1"/> <xmlParser name="JAXB" version="2.0"/> </environment> <analyzerEngine> <analyzerVersion>V1.0</analyzerVersion> <releaseDate>2012-11-22+01:00</releaseDate> <implementer name="Distributed Systems Group" location="http://www.uni-bamberg.de/en/pi"/> <xpathVersion>2.0</xpathVersion> <xsltEngine name="Saxon He" version="9.4"/> <generationTimestamp>2013-05-29T09:58:46.505+02:00</generationTimestamp> </analyzerEngine> <runConfig> <timestamp>2013-05-29T09:58:46.505+02:00</timestamp> <xsltEngine name="Saxon He" version="9.4"/> <docSource timestamp="2013-02-19T11:51:26.029+01:00">hello.bpel</docSource> <comments>no comments</comments> </runConfig> </analyzer> <artifact type="message"> <entry referenceID="hello.bpel"> <assertionResult id="bpp-r5" prescription="permitted" result="warning"> <failureMessage xml:lang="en">The process definition uses a query in a copy operation</failureMessage> <failureDetail xml:lang="en">Portability level widely portable, Degree: 1: Warning in line 70</failureDetail> </assertionResult> ... </entry> </artifact> </report>
As you can see from the top-level namespace, the format is the report format from the WS-I (hence, integration with WS-I tools). The reporting format is used in several other tools, such as SoapUI, so hopefully bpp reports might be displayable there as well. Apart from some meta-information, the interesting part comes from line 29 onwards. Every problem found translates to an
assertionResult which lists a descriptive message and additional information on the severity and line of code where the problematic element can be found.
If you want to contribute to bpp, feel free to do so at github, I would be happy to accept pull requests. I licensed the tool under LGPL, so you can also savely use it for something else. I will continue to update bpp when new data trickles in.