WebLogic Integration(WLI) to Oracle SOA Suite Migration

Objective

The Objective of this prototype is to analyze and assess the effort, and process involved in migrating the existing applications which are on WLI/ALDSP to Oracle SOA Suite 11G.

Purpose

IDEXX’s WLI applications had too much of hand-written custom java code and WLI extended support by Oracle is soon coming to an end. So, IDEXX is looking for options to migrate their WLI/ALDSP codebase.

Challenges

Custom written Java code and stability of the existing WLI/ALDSP code are major challenges for this WLI to SOA migration approach.

Approaches

There were three options considered initially for the Migration. Each of these options explained below.

Option 1: Migrating to SOA Suite 11G

The developer Workshop (BEA-branded Eclipse Editor for WLI and ALDSP) allows converting the JPDs (Java Process Definitions) to BPEL automatically. However, this has limitations. It may work for simple processes but for complex systems, a manual migration is necessary. A per component based migration fits this scenario. This would be manual, but all the WLI controls have an equivalent adapter in SOA Suite 11g. The advantages are obvious -- as this option gets to leverage a range of full capabilities of SOA and Oracle SOA Suite 11g, which is a robust and SOA based middleware platform. Their final architecture state is much more sustainable, agile and requires less maintenance. Developers who have worked on WLI will often have a small learning curve to start working with Oracle SOA Suite 11g, this is because it’s relatively easy and straightforward. The same applies to other development teams too. The current licensing costs of WLI+DSP compared to Oracle SOA Suite 11g to be factored (if licensing is a deterrent for the customer).

Option 2: Migrating to JAX-WS/JPA or Other Java Based Frameworks

This could look easy and promising initially but get multiple frameworks to work together can be a bit challenging. This will also mean a lot of code based re-writes as pre-existing WLI controls available with the tool cannot be used. However, option 1 is much lesser code and migrating to a standard technology.

Option 3: Migrating to Oracle Service Bus

This would be a solid anti-pattern to what OSB is designed for and we should certainly not recommend it. This business logic is medium to medium-complex, and OSB will not stand as the right candidate to migrate them to, although a lot of transports in OSB may be available as equivalents of the WLI controls.

Selected Approach

The reasons for choosing SOA over the other migration approaches are explained below.

 . Robust and SOA based middleware platform

 . Agility and less maintenance

 . Working on SOA 11g is relatively easy and straightforward for developers from WLI background.

 . Exceptional handling Policy based Fault Handling and Management (Notifications, Audit Trails, Retry from point of failure)

 . Standard based integration platform.

 . Minimum or zero coding in the migrated prototype.

 . No Java coding competency is required unlike the WLI, where the source code editing requires java skills

 Tools/Technologies Used

 . WLI Eclipse based Workshop for 9.2

 . JDeveloper 11.7

 . soa-jdev extension Plugin

 Migration Plan

  Analysis

. Install the WLI workshop and important the WLI project into eclipse start analyzing the WLI code. The analysis of the BillingReprocessErrors jpd process can be found as below.

BillingReprocessErrors.jpd

. The BillingReprocessErrors.jpd is a complex type project which has 5 Perform nodes, one DSP control call (getBillingHeaderById). Each of the perform nodes has java code, which is basically xmlbeans code to retrieve and initialize values to/from the xml elements.

BillingReprocessErrors.jpd also calls a utility java class BillingReprocessErrorUtils.java, which has calls to DSP namely getCustomerHeaderById, getActivePriceGroupsByCustomerId, getLaboratoryHeaderByLabId, getOrderHeaderById, getBillingErrorById.

The Below steps explains the BPEL process activities corresponding to the WLI JPD

1. The first obtainBillingErrorRequestInfo Perform node logic in the WLI process is represented using switch case in BPEL to check if billingErrorArg is not null.

2. If the billingErrorArg is not null, loop through the BillingErrors using a While loop.

3. The Second perform node obtainBillingError Info retrieves the values of billing HeaderId and Owning LabId is represented using the Assign activity (InitializeVariables). Also, the other constant values used in the process are defined in this InitializeVariables Assign activity.

4. The condition  (BillingHeaderId is not Null) is represented using the switch activity. If BillingHeaderId is not null, the JPD has a call to retrieve BillingHeader by passing HeaderId and other parameters. This is represented using the Invoke Activity (InvokeDSPgetBillingHeaderById) in BPEL. The Invoke activity calls the DSP service, which is exposed as a Web service to the BPEL process.

5. The Third perform node reconcileDemographicsForBillingHeaderAndItems has call to the java utility class BillingReprocessErrorUtils.java, which calls the above mentioned of the DSP control. Each of this is represented with a series of Switch and Invoke activities in the BPEL process.

6. The fourth (updateDemographicsForBillingHeadersAndItems) and fifth (updateBillingErrors) perform node have the update DSP calls for writing the BillingHeader and BillingError data to Database. This corresponds to the Invoke activities of the BPEL process.

Design :-

The below table shows the activities in the BPEL process corresponding to the nodes in the WLI JPD Process.

WLI Node	BPEL Activity
Client send and Receive node	Synchronous Receive and Reply
If Condition node	Switch activity
While Do node	While activity
XMLBeans java code	Simple Assign/Transform activities
DSP control calls	Webservice adapter calls to Oracle Service Bus
Email Control, File Control, Web Service Control and  XMLCacheControl	Email Adapter, File Adapter, WS-Adapter, and Domain Value Maps/Cross References respectively

.   The Migration approach for ALDSP is as below.

• Migrating DML operations to SOA Suite 11G.

• Migrating Data Query operations to OSB.

• Using Coherence as an optional Layer for Data Layer Caching 

The logical and physical services have unfortunately no direct migration option on OSB or Oracle SOA Suite 11g. However, both OSB and Oracle SOA Suite 11g have an excellent support for a communicating with heterogeneous data sources using standard JCA-based database adapters. The ALDSP platform can be used to generate query plans for the operations defined in the logical services. These query plans can be used AS-IS in the JCA-based adapters providing exact same operational functionalities to be executed from within OSB and SOA Suite 11g.

Advantages:-

. Minimal Coding in the Migrated Prototype

• Existing Query Plans generated from ALDSP used to create DB adapters

• Oracle Service Bus supports result can be used query based operations.

• Seamless integration with Oracle Coherence, resulting in high volume transactions by using data tier.

. Caching

Architecture:

Development :- 

During the process, we developed WSDL files Laborator.wsdl, Order.wsdl, Pricing.wsdl, Customer.wsdl from the scratch following a bottom-up approach.

Developed SOA composite application with the project named BillingReprocessErrors, the composite application has one BPEL process named BillingReprocessErrorsprocess.bpel.

Developed OSB project with JCA DB adapter based proxy and business services.

Testing :-

Testing is planned to be executed in two phases.

Phase 1 – Sanity check is performed to ensure the web service adapters call to OSB.

Phase 2 - Actual execution of test case to test the business functionality is currently out of scope due to the in availability of connectivity to IDEXX environment, end systems, and test data. 

Deployment Process:-

Deployment of SOA applications will be done through WLST scripts or ANT scripts. Currently, the deployment is done from jdeveloper and by exporting the SCA composite jar and deploying from em console.

Effort Spent:- 

• The effort spent for the Migration of the artifacts from WLI/ALDSP to SOA/OSB is summarized as below.

Lessons Learnt:-

WLI:-

If WLI applications have less of custom java code or custom controls, the migration could be automated and manual effort can be reduced to an extent. However, the BillingReprocessErrors.jpd uses quite a bit of java code without any transform activities. The JPD has java code comprised in perform node, hence the best fit for migration is to do a manual migration from WLI to SOA/OSB.

ALDSP:-

The logical and physical services have unfortunately no direct migration option on OSB or Oracle SOA Suite 11g. Both OSB and Oracle SOA Suite 11g have an excellent support for a communicating with heterogeneous data sources using standard JCA-based database adapters.

Acronyms and Glossary:-

Term	Definition
WLI	Weblogic Integration
ALDSP	Aqua Logic Data Services Platform
SOA	Service Oriented Architecture
WSDL	Web Service Definition Language
JPD	Java Process Definition
BPEL	Business Process Execution Language
OSB	Oracle Service Bus

Please touch base with us if you need any help in migrating the WLI to Oracle SOA suite. We do automation of the smooth upgrade, code quality, auto deployments and continuous integrations.

http://www.suneratech.com/