I’m using Oracle SOA Suite since many years now and I’m quite satisfied. As an ancient BEA WebLogic, Workshop and AquaLogic specialist, I’m glad to see that this product stack is still here and still the number one of SOA/SCA development platform, after BEA’s fade-out. My only concern using SOA Suite, OSB, etc. is the heavyness of the whole platform, which includes several databases or database schema, several WebLogic application servers, several developer tools like JDeveloper and OEPE. In order to have the whole platform up and running, with all the required components and services one needs generally several working days. Oracle currently makes available for free several appliances which are pre-built virtual linux machines, comming with all the Oracle Fusion Middelware pieces installed. The last release of this appliance contains a ready to use installation of SOA/BPM 11.1.1.7.1 which only needs to be downloaded and ran in an Oracle VM VirtualBox.

But even this approach, much easier and lighter then the one consisting to install one by one all the Oracle Fusion Middleware required pieces, might be heavy as it requires to download 7 files of 2GB each and to run a virtual machine having at least 12GB of RAM and minimum 2 processors. Hence, given the JBoss platform reputation of being lightweight, I was glad to hear that JBoss Fuse Service Works is available since several months now. This platform is the current release of the previous JBoss SOA-P 5.3 and it is based on JBoss EAP 6.1 on top of which there are several add-ons like Switchyard (the SCA engine), Riftsaw (the BPEL engine), Smooks (the transformation engine), jBPM6 (the BPMN2 engine), OverLord (the SOA governance), etc. For an overview of JBoss FSW see http://www.jboss.org/products/fsw/overview. As opposed to JBoss Fuse which exists since almost 2 years now, after thepurchaser by RedHat of FuseSource and which runs on OSGi platforms like Apache Karaf/Fuse Fabric, JBoss Fuse Service Works is a full Java EE 6 platform running on JBoss EAP 6.

Thinking that I could take advantage of the JBoss Fuse Service Works  lightweightness by using it to replace my Oracle Fusion Middleware platform. This article emphasizes my conclusions further to an attempt to use JBoss FSW in a real SOA project and compares this platform with Oracle SOA Suite.

The project

In order to give a try to JBoss FSW I used a simple case of a BPEL having to orchestrate the execution of two pre-existent web services. Basically, this BPEL is invoked asynchronously and, in its turn, synchronously invokes an already deployed web service. Based on the returned result, the BPEL will either synchronously invoke a second web service and make the returned result available to the initial caller via a callback port, or i twill throw an exception which will be catched by the caller. So, a very simple BPEL.

Using SOA Suite and JDeveloper

To provide a solution to the prevous presented problem with SOA Suite and JDeveloper is quite straightforward. I need to create a new application and a new SOA project in JDeveloper. This results in the creation of a new SCA composite. Here, using the JDeveloper Component Palette, I create a new BPEL. The associated wizard let me choose between the BPEL specification release (1.1 or 2.0).  After that, I can choose to create my BPEL based on 5 templates, which most important are asynchrounous BPEL, synchronous BPEL, one way BPEL or WSDL based. In my case I will choose an asynchronous BPEL. Next, I can choose the delivery policy between the following : async.persist, async.cache and sync. Next, I have to define my BPEL input and output. This is very simple using the SOA Suite wizard as I can select either XSD types or WSDL messages by browsing the file system, the MDS (MetaData Service), the OSR (Oracle Service Reporitory), the OER (Oracle Enterprise Repository), or simply using the deployed WSDL’s URL. Completing these steps creates the following new elements in the the current composite :

• A new composite service corresponding the the BPEL client having a WS (web service) binding.
• A new component corresponding to the BPEL itself having a BPEL implementation.
• Two composite references to the web services to be orchestrated, each having a WSDL interface and a WS binding.
• All the required import statement with all the required namespaces.

One point to note is that this operation automatically creates the required partner links for the orchestrated services, based on the WSDLs used as input/output messages. And since the original WSDLs don’t contain partner link types, the wizard automatically creates a wrapping WSDL defining the required partner link types and importing the original WSDLs.

Now, everything is okay and I cana dd business logic to my BPEL. One of the most important points are the assign statements used to prepare the inputs/outputs of the invoked services. Whatever the complexity of the manipulated variable is, all the assign/copy operations are entirely performed with the help of a wizard having an expression builder, able to construct xpath expressions or xquery transformation by simply clicking and draging different elements. At any point I don’t have to edit my BPEL such that to manually type in the copy statements. Here is a screen shot :

<a href="http://fr.tinypic.com?ref=2akh2ep" target="_blank"><img src="http://i61.tinypic.com/2akh2ep.png" border="0" alt="Image and video hosting by TinyPic"></a>

Finally, once compiled, the project is deployed by simply right-click on it and selecting deploy to the local WebLogic server. To test it is one simply needs to select the new deployed service in the EM console and to click the test button. A form allowing to fill-in the input values and different other options like security, quality of service, etc. is displayed. Then sending the request will trigger the whole process and the result will be displayed in the response screen.

Using JBoss FSW and JBoss Developer Studio

To do the same exercise with JBoss FSW and JBoss Developer Studio, one needs to create first a switchyard project. The first good point to note is that this will create a maven project. In my opinion this is really great as maven is probably the most usual build tool and I always regretd that, for some reasons, SOA projects in JDeveloper are not maven based. Besides that, the developer may choose the implementations and bindings to be included in the new SCA composite. In my case, I chose a BPEL implementation and a SOAP binding as there is no any WS binding. I suppose that this should be equivalent.

Now, in order to create my BPEL, I select Process (BPEL) in the JBDS palette and drag it onto the compsite canvas. This will open a wizzard which let me select the parent folder of the BPEL. Also, here I can choose weather I want to base my BPEL on an existent WSDL, in which case I can select it from the file system, or to create a new WSDL skeleton for the BPEL. In my case I don’t have any WSDL for my BPEL but, if I had, I could only select it from my project in the local filesystem. I couldn’t use a deployed WSDL via its URL or one in the SOA repository. As a matter of fact, FSW comes with a SOA repsitory called OverLord and which is an implementation of OASIS S-RAMP specification. One could create different artifacts in this repository, for example WSDLs and XSDs, but it is not possible to use this artifacts directly, from the repository. At least this is what I could get from the support service. So, in order to use an SOA compliant approach one has to start the projects by identifying the shared artifacts, like common WSDLs, XSDs, java classes, etc. and to load them into the SOA repository. But, as opposed to the SOA Suite/JDeveloper solution which is able to use several types of repositories (MDS, OSR, OER) for design-time, build-time and respectivelly run-time, the FSW/JBDS solution can only use artifacts in the current project. This is true at least for the design-time. For the build-time, given that the a switchyard project is maven based, the dependency management is delegated to maven. As for the run-time, this is done by handling the MANIFEST.MF dependencies. Nevertheless, at the design-time the only way to use shared artifacts is to download them from the repository in every using projects. This is not only very annoing but also this is an SOA anti-pattern.

So, in my case, I will simply create a new WDL skeleton for the BPEL. For this WSDL skeleton, the wizzard let me define its namespace and prefix, the protocol (SOAP or http) and whether it is document literal, rpc literal or rpc encoded. Strangelly enough, I cannot choose wheather the WSDL is synchrounous or asynchronous, which represents another important limitation. The wizzard will create a WSDL skeleton which will need to be substantially edited manually. We are here far from the JDeveloper capabilities. A partner link type will be created also for the BPEL client.

Now, I’m ready to add business logic to my BPEL. In order to orchestrate my web services, I need to copy in my project the associated WSDLs as oposed to JDeveloper which will rather reference them from the MDS or another SOA repository. So now, from the JBDS palette, I will select invoke operations in order to orchestrate my services. This orchestration process requires data transformation of the input and output variables. But the associated assign operations don’t have any facility to help and assist in building the required xpath expressions. The following screen shot shows that the developer need to manually write an Xpath expression in order to be used in a transformation. Or, if queries are to be used, in the case of a transformation from a variable to variable type, these queries are also to be edited manually.

<a href="http://fr.tinypic.com?ref=2akh2ep" target="_blank"><img src="http://i61.tinypic.com/2akh2ep.png" border="0" alt="Image and video hosting by TinyPic"></a>

Inserting invoke operations using WSDL messages parts doesn’t automatically create the required partner link types as in the case of JDeveloper. No, the developer needs to explicitly create thes partner link types and to use them with the invoke operations. And given the complexity of the XML notations, this is really very error prone. At such a point that one is right to wonder what is the reason of providing wizzard as far as the develoiper still needs to edit huge amounts of obscure XML statement having 300 characters lengthy each.

Last but not least, JBoss FSW uses behind the scene Apache ODE (basically it uses Riftsaw which, in turn, uses Apache ODE) and hence, in order to deploy the switchyard project, one needs to creat an ODE deployment descriptor. JBDS comes with an ODE descriptor editor but it only works for BPEL projects and it miserabily fails in switchyard projects with an error message saying that the current project … is not a BPEL project. No, of course it is not. It is a switchyard project.

Finally, I managed to build, deploy and run my project but this required a lot of XML/WSDL editing operations. My conclusion is that, while Oracle SOA Suite and JDeveloper are more complete and sophisticated tools, they come with an inherent heavyness which requires important resources. This is going to change with Oracle Fusion Middleware 12c. Waiting for that, several appliances are available and since they represent a much more practical solution, the final infrastructure is still heavy. Compared to this solution, JBoss FSW/JBDS is a lighter solution but, in the current release (6.1), it lacks productivity tools and features which leads to more error prone operating modes requiring the developer to manually edit XML/WSDL/BPEL files. But the next releases will certainly bring important improvements so, even not yet usable in a high productivity and reliability context, JBoss FSW/JBDS could be an appropriate choice for prototyping and POCs.