JCAPS to Oracle SOA Migration = Old wine in a new Bottle?
Having aged with Java CAPS and Oracle SOA Suite, I take the liberty to rattle on the ongoing trend - filling Old wine in a new Bottle.
Software migration is as exciting as getting a new vehicle for ride, without changing the Passenger or Destination. Likewise, migration provides the thrill of exploring new tools and functionalities, without changing the Business logic or Data.
The comparison may not be fully apt, as IT has more fancy complications and Business cycles…like "(quick) End of Lifecycle". Let us also keep in mind Software has no resale value like your car.
Now, let's get down to Business, on various approaches we could take on this Migration task.
Development Methodologies of JCAPS and Oracle SOA
Let us analyze the Development patterns of JCAPS and Oracle SOA before getting into Migration possibilities.JCAPS has gone through constant revamp to catch up with the latest technologies.
-
Seebeyond
SeeBeyond is the legacy version of the Middleware. It provides us Monk and Java as Development medium.
The architecture adopts Message oriented Middleware pattern. The Functional Components are either developed in Java or Monk ( SeeBeyond’s proprietary language ).
The components interact with each other or with the external components through Messaging Queues or Topics.
-
ICAN aka JCAPS 5+
ICAN / JCAPS 5+ is the JEE based Middleware. It relies on Repository based development. The Development artifacts are stored internally in a Version Repository.
The business logic is embedded in an EJB. the EJB collaborates with the source and target adapters and business data carried by the adapters. The Adapters translate the Business data to a common Java Object.
The EJB holds the Business Logic code by interacting with the handles provided by the adapters.
ICAN also inherited a strong Messaging component from its ancestor, SeeBeyond. The EJBs talk to each other internally via JMS Messaging Queues / Topics.
-
JCAPS 6+
JCAPS 6+ / Open ESB is based on JBI specification, very similar to Oracle SOA’s Service Component Architecture. Please refer to Additional resources for more details on SCA.
JBI leverage SOA - BPEL development approach. It exposes all your Business functions as Web Services. The Business logic is implemented in BPEL code, which interacts with the Web Services.
The major difference to the earlier approach is that the Common Interfacing mechanism is a Web Service instead of Java Objects.
-
Oracle SOA
Oracle SOA Suite development is based on Service Component Architecture, similar to JCAPS - JBI Version.
The Business logic is built as Service components ( a Web Service ). The service component thus built could be a BPEL component or Service Bus component or Java Spring Component.
The components can be connected together, in a typical plug and play fashion, via Composite architecture. Please refer to the SCA architecture Document for further explanation.
Migration calls...Let's go!
Now, we have an understanding of various Development patterns of the Products. Let us focus on the approaches we could take.
-
Seebeyond → Oracle SOA
Legacy version is too primitive for easy migration. Just rewrite the code to Oracle SOA.
-
JCAPS 5+ ( Repository based ) → Oracle SOA
Approach 1 : Convert your CAPS' JCDs to Oracle SOA's Spring Service component.
The Migration is done by translating the JCD in JCAPS to Java Spring component in Oracle SOA. The Oracle SOA migration Tool helps you on the conversion.
Pros : This is easier migration path. The Development and testing efforts are less since the JEE components can be reused.
Cons : You just deployed the components from Glassfish server to Weblogic. Actually, you do not need Oracle SOA Suite to do this. A simpler and Cost effective Approach is to deploy the components to a Standalone App server, rather meddling with SOA Suite. Leveraging Oracle SOA Suite for this type of migration is as good as buying a Truck and using it for commuting to Office
Approach 2 : Translating the Business logic in CAPS' Java Code to Oracle SOA's BPEL Service Component.
The Migration is done by translating the JCD in JCAPS to Java Spring component in Oracle SOA. The Oracle SOA migration Tool helps you on the conversion.
Cons : Additional development effort to rewrite the Java Components.
Pros : Oracle SOA Suite is more sophisticated tool compared to JCAPS and has state of art Monitoring and Development features to aid BPEL / ESB SCA approach. This approach makes your code truly Web Service enabled and Business Process friendly ( Processes can be changed on the fly with configuration changes. No Java coding or Debug logs).
-
JCAPS 6+ (JBI based ) → Oracle SOA
As both the Product’s architecture are very similar, Oracle migration tool helps you in a big way.
Epilogue
Migration is a challenging Process.
Shall we try simplistic thinking, employed by George Boole to zip our entire Business logic into Ones and Zeroes. Let's retrospect ourselves with few questions...
-
Do I need to do this migration?
-
What are the target goals for this exercise? How do I benefit from this migration?
-
Should I go for Quick fixes, to survive the Support / EOL scare? or... a cleaner approach by completely rewriting?
-
If I opt for a complete rewrite, what are my Development Tools. Should I choose Oracle SOA OR other licensed alternatives OR Open Source Tools?
So...this migration is filling 'old wine in a new Bottle'? Well... it depends solely on your decisions. I've come across brave souls in IT ( following Robert Frost ), who have converted these challenges to great Opportunities, by even coming up with their own IP / Solution. Are you the next one?