Okay, as an Enterprise Software Architect, you were successfull in the process of implementation of the SOA in your organization. You built SOA services to the highest standard, you adopted all the best practices, you established design-time and run-time SOA governance, however your end users keep complaining about the quality of the data served by your services. As a matter of fact, despite all the efforts that your company has made in order to re-design and to re-implement its services, such that to achieve a very high quality of the business infrastructure, these services still deliver poor quality data. Suddenly, you realize tha your SOA infrastructure doesn’t store operational data and that you need to provide as much management and governance for your enterprise data as you provide for your enterpeise services. Enter Master Data Management (MDM).

Having the right level of sponsorship from your business, you, together with other enterprise architects, create a roadmap meant to define the global strategy towards implementing a full MDM solution in your organization. This solution, based on the utilization of the Oracle MDM Suite and Oracle Data Quality familly products, is designed such that to steward, profile, match, merge and audit your enterprise data. Given the extremly etherogeneous landscape of your enterprise IT software, the business data has critical issues as the fact of being redundant in different systems like CRMs, ERPs, B2C services, etc. and not providing a centralized and unique enterprise wide view. So, one of the most critical challenges of your MDM solution is to unify your data by defining a business comon semantic and to promote this common semantic as being your enterprise master data. But while MDM subject-matter experts recruited to assist you are working hard to construct and implement the solution, you identify a new challenge : using a business common semantic as the enterprise master data requires to constantly collect and replicate data from your enterprise various systems. And since these systems are many, this seems like an onerous task and designing the right interfaces is not trivial.

However, after having conducted several researches, you and your other colleagus in the enterprise architecture team, discovered that Oracle provides so-called Process Integration Packs (PIP) in its Application Integration Architecture Foundation Pack (AIA FP). These PIPs are constructed to address end-to-end integration challenges in processes like « Order to Cash », « Procure to Pay », « Record to Report » and « MDM Integration ». This PIP come out-of-the-box and their implementation and customization requires generally little effort, saving this way many work-hours. One that particularly retains your attention is the Customer MDM Integration Based Pack which aims at being a true Customer Hub for all your enterprise services and systems. This Customer Hub will offer an unified view of the Customer business object to your Siebel CRM, your Oracle e-Business Suite ERP, your Oracle BRM revenue management system, your B2C web-apps, etc.

Implementing PIPs that come out-of-the-box with AIA FP is a win to win scenario because it not only accelerates the MDM rollout but, given that they are SOA based, all the enterprise systems and services are potentially beneficiaries. Moreover, by adopting Oracle AIA FP, the enterprise takes advantage of all the artifacts provided by this foundation, including the use of the Oracle Enterprise Repository (OER) to promte services visibility, re-use and policy enforcement. Also, using the JDeveloper plugins, business services, WSDls and XSDs that come out-of-the-box with Oracle AIA FP, and adopting AIA FP standards and taxonomies, the enterprise should be able to dramatically reduce costs and to mature and enforce its SOA best practicies.

AIA FP features and facilities would be difficult to resume in a couple of lines as they make the object of several hundreds of pages of product documentation. This foundation provides a real development life-cycle with all the required tools, including but not limited to

• Runtime artifacts like policies, composites, pre-built integrations and error handling frameworks.
• Utilities like Business Process Analysis (BPA), Process Lifetime Workbench (PLB), AIA Service Constructor, etc.
• AIA Refernce Architecture providing service re-usability, modularity, granularity, composability, loosing coupling, discoverability, etc.
• AIA Conceptual Architecture providing process, activity, data and utility services.
• Etc.

But one of the most important component of the AIA FP is probably its Shared Service Library, consisting in a number of artifacts and defining the AIA Service Taxonomy. Based on this taxonomy, complex SOA solutions can be implemented using the following building blocks :

• Composite Business Processes (CBP) : application agnostic processes implemented in BPMN2 using BPM Suite 11g or in BPEL using SOA Suite 11g.
• Enterprise Business Services (EBS) : application agnostic activity or data services, exposing coarse grained business logic like CRUD operations against first-class enterprise entities like customers, sales, orders, purchases, etc. They are implemented as SOA Suite 11g Mediators.
• Enterprise Business Flows (EBF) : application agnostic activity services responsible of delivering specific business tasks and implemented as BPEL with SOA Suite 11g.
• Application Business Connector Services (ABCS) : data services providing fine grained business logic and connection logic. They are implemented as SOA 11g Mediators. They come in two flavors : ABCS Requesters and ABCS Providers depending on their responsibility to receive messages or to expose fine grained functionality.
• Application Business Flows (ABF) : dedicated services to support point-to-point integrations. While usefull in scenarios where introducing several layers of abstraction might be penalisant from a performance poit of view, this kind of pattern is to be used carrefuly.

All these service patterns are exchanging abstarctions like Enterprise Business Messages (EBM) and Enterprise Business Objects (EBO) defined as WSDLs and XSDs and comming out-of-the-box with AIA FP. All the first-class enterprise entities are present and, consequently, they don’t have to be any more invented by every application, system or service as it is so often the case.

Download the stuff, try and enjoy !

Apache Camel provides a powerfull unit testing framework that developpers use since years and which name is Camel Test Kit. This unit testing framework consists in a number of classes on top of JUnit that facilitate Camel routes unit testing. Among these classes, one of the developer’s prefered is ProducerTemplate which represents a very convenient way to send Camel messages to Camel routes, for testing purposes. But when it comes to deploy Camel routes into the new Fuse Service Works application server, the developer skeptically discovers that, while SwitchYard comes with a very strong unit testing frameworks supporting HTTP, CDI, HornetQ/JMS and Smooks, the old good Camel Test Kit is not supported. At least this is what the Red Hat technical support will advise to the developers submiting tickets in order to complain that statements like :

@Test public void testStartService() throws Exception
{
  template.sendBody ("switchyard://HelloWorldComponentService", "Hello World !");
}

raise the following exception :

java.lang.ClassCastException: org.apache.camel.impl.DefaultCamelContext cannot be cast to org.switchyard.common.camel.SwitchYardCamelContext at …

What happens here is that the Camel ProducerTemplate uses a CamelDefaultContext while producing message to SwitchYard endpoints obviously requires a SwitchYardCamelContext instance. And the SwitchYardCamelContext cannot be casted to a CamelDefaultContext instance. How then is one supposed to use the Camel unit test framework with SwitchYard ?

The Red Hat support will tell you that this is simply not supported and that, if you want to test Camel routes using HTTP or JMS endpoints, then you may do it using SwitchYard MixIn like explained here  https://docs.jboss.org/author/display/SWITCHYARD/Testing, otherwise you need to use real test clients like in integration/functional testing. This is what happened to me and, after a several days debate at the end of which they simply closed my ticket without my agreement, I decided to submit the same case to the SwitchYard community forum. And guess what ? One hour later, thanks to Keith Baboo, I got my solution. Given a SCA service like the following :

<sca:service name="Hello/HelloService" promote="Hello/HelloService">  

  <sca:interface.java interface="org.jboss.example.ExampleService"/>  

  <camel_1:binding.uri name="camel1" configURI="direct://HelloService"/>  

</sca:service>

One may test it like this :

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig (config = SwitchYardTestCaseConfig.SWITCHYARD_XML, mixins = { CDIMixIn.class }) 
public class ExampleTest 
{
  private SwitchYardTestKit testKit;  
  @Test  
  public void testIntake() throws Exception 
  {  
    ServiceDomain domain = testKit.getServiceDomain();  
    CamelContext ctx = (CamelContext)domain.getProperty("CamelContextProperty");  
    ProducerTemplate producer = ctx.createProducerTemplate();  
    producer.sendBody("direct://HelloService", "Message content");  
  }  
}  

The way we instantiate the Camel ProducerTemplate here is very different compared to the way we do it in plain vanilla Camel and, since this is not documented, the developer would probably have difficulties to guess it. Hence, I wanted to document it here, waiting that the official documentation be updated and hoping that the Red Hat FSW technical support will also read it. The morality is that, sometimes, it is not worth paying expansive technical support because free users forum might be more proficient and, in any case, more polite and respectfull.

Thanks Keith !

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.