Migration Oracle to OpenESB

MigrationFromOracle

 

Introduction

Leaving an integration platform from editors such as Oracle, IBM, Microsoft or SAP is a not common decision but many arguments can justify this choice:
    Complex relationship with the editor
    Insufficient attention from the editor
    Invading and intrusive portfolio associated with the integration platform
    Expensive budgets for license and support
    Performance or inefficiency issues
    Lack of skilled people on the platform with reasonable rate
    Strategic decision to move to open source solutions

Such decision creates many reluctances in the teams and its application is often slowed down with time, resource and budget constraints on the ground. Migration cost is clearly one of the main brake that stops companies in their decision as well. However, some migrations are easier when the source and the target are similar and use close technologies and development processes. This document shows how OpenESB is the easiest and the cheapest alternative to Oracle SOA Suite.

 

Why a migration to OpenESB?

At the first glance, offering a migration from Oracle to OpenESB could be surprising. One can think that there are very few common points between OpenESB (OE) and Oracle SOA Suite (OSS). However, for the ones who knows the history of both products, the filiation is obvious. Both products have been designed for the same objective and are based on similar specifications, close architecture and after Oracle and Sun merging, a part of OSS has been developed by OpenESB team.

 

OpenESB – Oracle SOA Suite shared background

OpenESB and Oracle SOA suite shares many concepts:

Migration OSS OE

 

Shared concepts Comment
Bus Both products defined a bus of service and not a route manager
Specification SCA has been deeply based on JBI
Composite application Same concept in both products
Binding component Same concept in both products
Orchestration Same concept in both products based on BPEL Specifications
Development process OSS and OE development process are very closed and bases on service definition and orchestration.

Thanks to that shared background OSS applications can be easily understood by OpenESB developer and VS.

 

OE-OSS Shared development process

In a service oriented development, time and budget consumed to design and implement a project can be divided in steps as follows:

 

Migration OSS OE 02

 

Steps Objectives
Capture business requirement Mapping business services to technical services.
Services definition Message structure, Operation, Fault, compensation services…
Orchestration design Map technical services to business process to BPMN / BPEL activities. Fault management, handler definition, compensation process, correlation use, data mapping (XPath, XSLT)
Service implementation Services implementation (often in Java)
Orchestration implementation Implementation of BPEL process in a BPEL engine
Composite application definition Service unit organisation, choice of concrete communication channel (binding component)
Composite application Deployment Deployment of Composite application on the platform
Tests Validate services and not implementations.
Governance Manage services and not implementations

 

In this set of steps, many are independent from the integration platform used. Just the steps linked to the implementation are product dependant. It is interesting to notice that in a service oriented development, test and governance steps are focused on service and not on the implementation. Consequently, tests and governance planned for a platform are available for any others

A large part of the business process steps is shared by both products. Implementation steps are obviously different, nevertheless, as explained above, OSS and OE share the same concepts and good practices and consequently, implementation steps are similar.

Let’s take the test step as an example: Tests are made against services (and not implementations) that are shared by OpenESB and OSS applications. So, a test designed and implemented for service implemented by OSS worked perfectly when the service is implemented by OE.

Our involvement in many large projects, showed us that the implementation steps represent around 20 to 30% of the application cost. Consequently, during a migration up to 80% of the development cost can be saved if the work made is conformed to the service development best practices.

Thanks to its closeness with OSS, OpenESB is the easiest and the cheapest alternative to move to another light open source and light platform.

 

What is OpenESB?

OpenESB is a service oriented platform developed by Sun Microsystems. After its merging with Sun, Oracle viewed OpenESB as a worrying competitor for its WebLogic integration platform and stopped its support to OpenESB. Fortunately, at the same moment, a new community has been created to support and improve OpenESB. For many years, Pymma has been its main sponsor and contributor to this community.

During these years, OpenESB has been dramatically improved and upgraded. Its architecture has been completely reviewed to be compliant with the new virtual and cloud architectures and contrary to OSS, an application server is not required to run OpenESB anymore, but just a simple JVM.

Migration JC OE 04

With its new architecture, OpenESB runs more efficiently with reliability and overall, it relies neither on a Glassfish server nor any additional software to run. This improves dramatically its reliability, efficiency and scalability. Today, OpenESB is the perfect integration platform from IoT to enterprise project.

 

OpenESB Enterprise Edition

During the last years, Pymma acquired a great skill on OpenESB implementation. We help leading global companies and governmental organisations to develop large and reliable integration platform.

In order to answer to our customer requirements on high reliability, security and enterprise monitoring, Pymma developed and issued an OpenESB Enterprise Edition that comes with a strengthened code, professional support and many additional features for enterprise monitoring and security.

Migration JC OE 05

OpenESB EE is optimized to run on a simple JVM. The improvement and the optimisation we made in OpenESB EE, made the product faster with a memory footprint divided by two.

Every day, OpenESB EE processes billions of messages and events for large companies and governmental organisations. We are improving continuously OpenESB Enterprise Edition code quality, reliability, compatibility with new Java libraries and specifications. Pymma offers you an attractive, serious and credible alternative to the large editor’s integration products such as OSS.

With our involvement, our skill on this platform, with our 24x7 support on OpenESB, companies and governmental organisations find again the enthusiasm, the reliability and the expertise that prevailed at Sun Microsystem.