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.

As I’m saying often, scripts are the level zero of the software development and integration. By scripts, I’m reffering to these sequences of command lines ran by the Unix shell. And when I say that they represent the level zero of the software, I don’t mean to deny their utility to automate simple processes like copy a set of files, zip/unzip archives, deploy/undeploy stauff, etc. What I mean is that, while they might be practical ways to quickly perform repetitive actions, like checking-out dozens of projects from an SCM (Source Code Manager) repository, their utilisation for important things, like infrastructure management, should really be forbidden.

I’m currently working in a DevOps team of a big french gouvernment administration, where the infrastructure is quite impressive, consisting in more than 600 platforms, each one having several dozens of WebLogic domains.  And as surprizing as it might seem, all the infra-structure services consisting in installing binaries, configuring domains, application servers, databases, clusters, web servers, deploying applications, etc., is done in shell scripts having thousands of lines. These scripts look like a massive spaghetti pile, having often several thousands of lines, without any structure or clear defined interface and where evrything is done via sed and awk. And of course, to cap it all, nobody in the team has the mastership of what exactly happens in those scripts.

Different consultants, including myself, have tried to sensibilize the management to the huge technological debt they will have probably to pay for a very longtime, thanks to the choices they made and, while they become aware of this situation, they still don’t seem to be at 100% convinced. They don’t understand what’s the point as far as everything seems to almost work.  Different approaches are in-progress trying to introduce different open-source DevOps virtualisation and install engines solutions, like Vagrant, Ansible, etc. But the effort is far from being trivial as this requires to dig in thousands of lines of spagetti like scripts, to extract functionality and to think how it could be re-designed and re-implemented with tools like ansible or equivalent.

However, as far as I’m concerned, I’m still not confortable with this approach as replacing a scripting language, like the Unix Shell (Bourne Shell, C Shell, K Shell, BASH or whatever) by an automation engine, like ansible, doesn’t fondamentally change anything. While a more modern solution then using poorly designed and untested in-house scripts, while supported and professionally documented, an automation engine like ansible is not yet the tool to be used in order to implement SOA infrastructure services. As highlited by the SOA advocates, the infrastructure services are an important part of the enterprise services set and as such, they have to satisfy the following requirements :

• Modularity and granularity. In an SOA based infrastructure, services are modular and self-contained. They may be composed from other modular services, and can be mixed and matched as needed to create new composite services. Granularity is a critical quality for services—the more coarse-grained a service is, the richer or larger the function offered by the service. Coarse-grained services provide a greater level of functionality within a single service operation. This helps to reduce complexity and network overhead by reducing the steps necessary to fulfill a given infrastructure activity. Often this is accomplished by composing smaller tasks into a single coarse-grained operation. Fine-grained service operations provide the exchange of small amounts of information to complete a specific discrete task. These requirements of modularity and granularity cannot be achieved in scripting languages as they are too primitive and too closed to operating system and their commands and utilities to provide so high level concepts.
• Encapsulation. Services exhibit a strict separation of the service interface (what a service does) from the service implementation (how it is done). Encapsulation hides the service’s internal implementation details and data structures from the published interface operations and semantic model. Encapsulation is impossible to be achieved in scripting languages because they don’t have the notion of interface and because implementation is all what the scripts are about. Consequently, scripts don’t expose any semantic element.
• Loose coupling. Coupling describes the number of dependencies between a service consumer and provider. Loosely coupled services have few, well-known and managed dependencies. Tightly coupled services have many known and, more importantly, unknown dependencies. The degree of coupling directly affects the flexibility and extensibility of a system. From this point of view, it’s obvious that scripts can only be tightly coupled and, hence, unflexible and unextendible.
• Isolation of responsibilities. Services are responsible for discrete tasks or the management of specific resources. A key characteristic of service design is the isolation of responsibility for specific functions or information into a single service. This provides one (and only one) place for each function to be performed, providing consistency and reducing redundancy. But when you look at how scripts are written, even when they are written by experienced people, having a real and solid culture and expertize in the services world, you notice how far you are from notions like isolation of responsibilities.
• Autonomy. Autonomy is the characteristic that allows services to be deployed, modified, and maintained independently from each other and the solutions that use them. An autonomous service’s life cycle is independent of other services. As opposed to this concept, a script is something which heavily depends on the context it was written for and which doesn’t provide any designed to change feature or ability.
• Reuse. Together, modularity, encapsulation, loose coupling, isolation of responsibilities, and autonomy enable services to be combined into multiple processes or accessed by multiple service consumers from multiple locations and in multiple contexts. In other words, services are shared and reused as building blocks in the construction of processes or composite services. This is absolutelly not the case of the scripting technology which doesn’t provide any of these advantages.
• Dynamic discovery and binding. Services can be discovered at design time through the use of a design-time service repositories. Additionally, service consumers can be dynamically bound to providers during run time. In this scenario, the consumer asks the registry for a specific service and is routed and bound dynamically to the appropriate service provider. The dynamic binding of a service consumer to the service provider  enhances loose coupling and enables additional capabilities such as mediation. Once again, using scripting languages, we are very far from this scenario.
• Stateless. Service operations are stateless. This means that they neither remember the last thing they were asked to do nor care they what the next is. Services are not dependent on the context or state of other services — only on their functionality. Stateless services provide better flexibility, scalability, and reliability. Again, when you look at scripts where nothing is stateless, which depend on lots of things, including but not limited to the current folder in the file-systems, it becomes clear that they aren’t share the same play-ground.
• Self-describing. The service contract provides a complete description of the service interface, its operations, the input and output parameters, and schema. The contract may also contain pre and postconditions and constraints about the operations. In the case of scripts, there is no any contract, any interface or any schema. The well behaved scripts use to provide a –help switch explaining the required parametters and their meaning, but this is their maximum. They are not only not auto-describing but even not discribing at all.
• Composable. Services can be composed from other services and, in turn, can be combined with other services to compose new services or processes. Whoever ever tried to compose scripts or to chain them knows how difficult this exercice is. Besides sourcing scripts defining environment variables definitions in the context of other scripts, any other attempt of superior composition or aggregation is quite impossible, given their un-flexibility, their statefullness, their un-modularity and their un-autonomy.
• Governed by policy. Relationships between service consumers and providers (and between services and service domains) are governed by policies and service level agreements (SLAs). Policies describe how different consumers are allowed to interact with the service. In other words, what they are allowed to do. Scripts are at ages from such a processing model hence they are not mature enough to be used in SLA based environments and those having to guarantee a given quality of service (QOS).
• Independent of location, language, and protocol. Services are designed to be location-transparent and protocol/platform-independent. In other words, they are accessible to any authorized user, on any platform, from any location (within reason). As opposed to them, scripts require the user to know by hard the 120 characters long path on the file systems they are stored, together with SSH connection credentials and other horrors that make them simply unsable.

My conclusion is that, unless you need to automate simple processes consisting in running a sequence of OS commands, or even more complex processes like saving and restoring data bases or file-systems, in your daily infrastructure tasks you need to define discrete functionality units and to make them available through a contract, while making sure they are modular and in the right granularity, loose coupled, autonom, reusable, stateless, self-describing, etc. Meaning that you need to forget scripting languages. Yes, this is true even for scripting languages like Python, Jython, etc. And what other technology is the most appropriated for that ? Well, I know this is hard to be accepted by system administrators, infrastructure architects, DBAs and other production and operations engineers but, as unbeleivable as it might be, the technology you’re looking for is Java.