Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Upgrading ALSB services to OSB

Categories : How-toSOA

Recently I carried out a project in which we upgraded the middleware services from Aqualogic Service Bus (ALSB 3.0) to Oracle Service Bus (OSB 10.3). In OSB 10.3 some very useful features where introduced, for instance:

  1. Debug capability. In Workspace Studio, the Eclipse-based IDE, breakpoints can be defined. This allows you to step through the OSB actions and inspect the variables in a convenient way.
  2. Scripted Export. The configuration JAR that is used for deployment can be exported using for instance using ANT.
  3. Proxy server object. When your service needs connectivity to internet, a proxy server in the DMZ can be used. In ALSB, the only way to use a proxy server is to specify one in the server start parameters using the -Dhttp.proxyHost system property. This results in all  HTTP traffic to be routed through the proxy server. To prevent this, a blacklist of hostnames needs to be managed using the -Dhttp.nonProxyHost system property. In OSB, the proxy server object was added. One or more proxy server objects can be defined. When a service needs connectivity to the internet, the associated OSB Business Service will be configured to use a proxy server object.

The process of upgrading a service bus project is mostly a trivial matter: load the project into the OSB Workspace Studio and it will be converted automatically. We did encounter some issues which I will discuss briefly. Some issues were not directly related to the service bus. Finally I will give an overview of the new custom developed build and deployment framework.

Issues and solutions/workarounds.

1. XPath namespace prefixes

Consider the following xml message fragment:
  <soapenv:Body xmlns:soapenv="" xmlns:urn="">
    . . .  

To select the 'HouseNumber' tag, the following XPath expression can be used:

where prefix 'ns1' is defined to be the correct namespace value ""
When using very complex XSDs this is not garanteed to work in OSB! To work around this problem, we ignored the namespace altogether using the local-name() function, resulting in an XPath expression like:

2. XSLT validation in Workspace Studio

The OSB runtime environment uses the Saxon XSLT processor, instead of the older Xalan XSLT processor. One of the XSLT files used both the 'include' and the 'import' statement. Imports are no longer supported in Saxon. However, in Workspace Studio the XSLT file validated without errors, thus still supporting imports. So error occurred at runtime, but it was not immediately clear that the imports caused the problems. Includes and imports have different semantics but in our XSLT file, replacing the import with an include solved the problem.


In the custom Quartz based scheduler, the webservice client that triggers the services was upgraded from JAXRPC to JAXWS. After the upgrade the webservice client seemed to be able to make webservice calls. However these calls proved unsuccessful, while there were no errors or stacktraces, anywhere. In order to solve this issue (an XSD element without a type used as input of the operation), the WSDLs needed to be modified in both the scheduler and all services that are triggered. Due to time contraints we could not make the modifications. We switched back to JAXRPC.


In order to use .so libraries in Weblogic server, the path to the .so files need to be specified. In the admin console, 'Server Start' tab, section 'Arguments' the path can be appended to '-Djava.library.path'. But this is not enough. After a considerable amount of searching, we found that the path to the .so files needs to be added to LD_LIBRARY_PATH as well. This variable is set in the scipt:
  export LD_LIBRARY_PATH  

Custom build and deployment framework.

The custom developed framework has support for:
  1. the creation of resources: JMS (servers, filestores, modules, distributed queues, etc.), JDBC (multi)datasources, workmanagers
  2. the export and import of the configuration JAR.
  3. execution of the customization file

Building the deployment using Maven

Exporting the configuration JAR is described here. It works fine, but there is room for improvement: export errors result in one single errorcode without any useful information what so ever. Because the configuration JAR can be exported using script, the build process can be Mavenised. The final artifact is a single JAR file containing: resources defined in xml files, configuration JAR, and customzation files (one for each environment). The lifecycle of the artifact JAR is shown in the figure below. The snapshot artifact JAR is build using the maven 'deploy' goal. A release artifact JAR is build by first creating the subversion tag using the maven 'release:prepare' goal, followed by the 'release:perform' goal which checks out the tag and builds the artifact JAR into a central location: Artifactory. Artifactory is an open source, HTTP-based repository. From the Artifactory a deployment or rollback is performed using one single command.
This is post is by John Chin-a-Woeng, a Senior Oracle SOA Suite Consultant for Capgemini

About the author

Arjan Kramer
Arjan Kramer
As a Digital Solution Architect Arjan Kramer realizes Digital Business Vision and Strategies by translating them into tangible solutions. In this role he is currently responsible for one of Capgemini's Global Digital Customer Experience Service offerings called OCommerce. This offering is a solution based upon several Oracle products in the Customer Experience domain, spanning Marketing, Sales and Service capabilities, including eCommerce. This solution is offered as a single integrated solution for all-channel Commerce and CRM. His 15+ year experience in IT, implementing CRM, Online and Social solutions and integrating those into existing landscapes for several global organizations makes him the best suitable man for this job.

Leave a comment

Your email address will not be published. Required fields are marked *.