SOA Suite Build, Deployment and Test Automation – part 2: automating ESB deployments

This is the second in a series of three posts. The goal of these posts is to outline an automated build procedure for Oracle’s SOA Order Booking demo application and deploy it to an Oracle Application Server that runs the SOA Suite. Oracle’s demo application is selected because it uses all components in the SOA Suite: the brand new ESB, BPEL and Business Rules.

Focus of part 1 was on describing the nuts and bolts of the automated build environment and subsequently on building the Web Services and BPEL components in the SOA demo application. Goal of this post is to build the Enterprise Service Bus (ESB) services. Finally, in part 3, I will focus on the new automated unit test capabilities of Oracle BPEL processes.

A very short introduction to ESB and Oracle’s ESB

The ESB concept combines a number of integration patterns. At the heart is the idea of a Message Bus that enables disparate applications to work together in a decoupled way via the exchange of messages. This concept is illustrated in the following picture (taken from www.enterpriseintegrationpatterns.com).

Oracle’s ESB product implements this and additional enterprise integration patterns for working with messages in a secure way. It provides functions to connect, transform, and route business documents which will most likely be XML messages.

In the industry, an ESB is regarded as the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA). The following picture (which really should have been introduced in part 1 ) provides an overview of Oracle products in SOA & EDA space putting the different components into perspective.

Certainly, BPEL and ESB have common characteristics. For example, both are very capable of handling message transformations and both Oracle BPEL and Oracle ESB allow the use of adapters to connect to a myriad of sources and business services. BPEL is business process oriented where ESB is more a part of the (technical) infrastructure. Combine BPEL and ESB and put each to good use. From an ESB perspective, use the Oracle ESB for:

• crossing boundaries between semantically different domains in order to keep your BPEL-supported business processes free from technicalities like transformations;

• fast message handling without the overhead of BPEL.

For an excellent hands-on introduction to Oracle’s ESB product, read the article Building Event-Driven Architecture with an Enterprise Service Bus from my colleague Lucas Jellema that was recently published on Oracle Technology Network.

Automating builds and deployments for Oracle ESB?

Like almost any other component in an Oracle technology stack, ESB services are developed using Oracle JDeveloper. In a JDeveloper project, you construct ESB Systems, Service groups and Services. Systems and Service Groups are provided as a means for organizing the ESB Services. JDeveloper also provides a function for deploying an ESB project and its contents to the ESB Metadata (aka design time) server via the ‘Register with ESB’ option.

But in an automated build and deployment environment the intention is to stay away from tools that require manual intervention. Unfortunately, for ESB components Oracle does not provide automated build and deployment facilities (yet!).
A little investigation of the contents of the directory for the FulfillmentESB project shows that a zip file is constructed when the project is registered with the ESB. The zip contains the System and the Services definitions (a Service Group is not used) and the modules that make up the Services. While this is not hard to construct, e.g. via Ant, the remaining question is: how is this archive file actually registered with the Oracle ESB server? I relayed that question to Clemens Utschig, an Oracle product manager in the SOA Suite group with whom I hope to deliver a joint presentation at the ODTUG Kaleidoscope conference later this year (given that our schedules match). Clemens passed it on to his colleague Doug Gschwind, a principal solutions architect in Oracle’s Application Server Solution Architects Team. Doug sent me an engineering marvel that made my life very easy: an extension to Ant for building and deploying ESB projects.

Putting it to the test

Based on the excellent documentation provided by Doug, the following Ant build file was constructed:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<project name="FulfillmentESBDeploymentProject" default="usage">
    <property file="build.properties"/>

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
      - Import, to enable the custom ESB Deployment ant tasks ...
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <import file="${dir.lib}/ESBMetadataMigrationTaskdefs.xml"/>

    <target name="deployProjects">
      <deployESBProjects esbMetadataServerHostname="${esbMetadataServerHostname}"
                         esbMetadataServerPort="${esbMetadataServerPort}"
                         userName="${esbServer.userName}"
                         password="${esbServer.password}">
          <esbProject directory="${dir.esbProjectToDeploy}"/>
      </deployESBProjects>
    </target>

    <target name="undeployEntities">
      <undeployESBEntities esbMetadataServerHostname="${esbMetadataServerHostname}"
                           esbMetadataServerPort="${esbMetadataServerPort}"
                           userName="${esbServer.userName}"
                           password="${esbServer.password}">
        <system guid="3C2D63E0CC1811DABFA0CDAACB57527A"/>
        <service guid="68CC671116A611DB8F22F7EF54089965"/>
        <service guid="FFF9F230D18F11DA8F7635853D6BAACC"/>
        <service guid="84A618D1D18E11DA8F7635853D6BAACC"/>
        <service guid="81944430CC1811DABFA0CDAACB57527A"/>
        <service guid="802F6421D19611DABF86ADAC868E14B0"/>
      </undeployESBEntities>
    </target>

    <target name="usage">
      <exec executable="ant" dir="${basedir}" vmlauncher="false">
	      <arg value="-projecthelp"/>
      </exec>
    </target>

</project>
 

And that’s all there is to it!

Please note: there are other functions available, for example for metadata promotion to different ESB Metadata Servers. These are beyond the scope of this article and therefore not mentioned.

The Globally Unique Identifiers (guid) in the build file for the System and the Services are available in the descrip
tive files for these modules, with
extensions .esbsys and .esbsvc respectively.

Using the Ant file within JDeveloper

In order to use the Ant extensions from within JDeveloper as well, I had to add the Apache commons-codec library and the library that contains the extensions to the classpath of the default Ant version that is used in JDeveloper.

The extensions to Ant for building and deploying ESB projects were provided ‘as is’ and are not an official part of the Oracle SOA Suite product stack. Clearly, this package should be in the next version of the SOA Suite. Just before publication of this blog post, Doug informed me that it will be included in an upcoming patch release. In the meantime, you should contact Oracle through your usual channels to request this Ant package.
 

Revisited: stop talking, start building!

Given the working Ant solution, the configuration of Luntbuild for the FulfillmentESB and OrderBookingESB components of the SOA demo application is straightforward. In line with the SOA Demo Application installation guide, the start of the build and deployment has now been switched to the FulfillmentESB services. Successfully building this component triggers the roll-out of the remaining projects from the Subversion repository.

And again, pictures speak louder than words:

Concluding remarks

Thanks to Clemens and Doug this exercise is still on the right track. With sustained little effort: it takes more time to write the text for this blog post than I find myself spending on configuration of the build and deployment environment.
If you enjoyed this, stay tuned for part 3 of this series that focuses on the new automated unit test capabilities of Oracle BPEL processes.