I'm happy to announce that Oracle has just released the Java CAPS Migration Tool under Controlled Availability to Oracle customers and certified partners.
Oracle customers, partners and consultants can now migrate JCAPS artefacts and intellectual property to Fusion Middleware, often saving several "person decades" of redesign and recoding. What's more, the tooling and methodology cover the most recent versions of the ICAN, JCAPS and JBI releases and support a number of SRE and e*Gate use case as well. The tool is available for download by existing customers and partners via the Oracle Support channel. This article explains what the methodology and tooling can do and provides some pointers on how best to engage Oracle for a successful JCAPS to Fusion middleware migration.
Oracle has an official migration methodology to help customers migrate their Java CAPS (“JCAPS”) systems to Oracle's Fusion Middleware whilst implementing architecture that follows best-practices. A very important part of this methodology is our JCAPS Migration Tool, a powerful accelerator for migration.
As owner of both the source (JCAPS/SRE/e*Gate) product lines and the target (Fusion Middleware) product stack, Oracle has spent significant Engineering dollars investing in a migration Tool to help accelerate the process. The methodology and tooling cover the latest versions of ICAN (Java EE) 5.0, JCAPS 5.1, 6.0 (classic), 6,0 (JBI) and some of the use cases for SRE 5.0 and e*Gate 4.5.3 releases.
In this article, I provide an overview of why the methodology is important, what the tooling can do and some pointers on how best to engage Oracle for a successful migration.
First, an important point about terminology. The terms “JCAPS” and “Migration” are heavily overloaded – they mean different things to different people.
JCAPS - For the purposes of my articles, consider “JCAPS” to encompass the following Sun/Seebeyond Product stacks and integration platforms: e*Gate 4.5.x, SRE 5.1.x, ICAN 5.x, Java CAPS 6.x (both classic and JBI).
Migration – To sales and budget holders, this means migrating software and support licenses (license migration); to business users this means migrating business functionality (functional migration); to managers and consultants, this means migrating actual design patterns and code (code migration – the sweet spot). A successful migration project requires planning for all three: license, functional and code migration.
Whilst the natural urge is to "try out the tool" to "see what it generates", successful customers take a step back and first look at all factors for success.
Every JCAPS implementation is different, often projects within an implementation are different and various stakeholders within the organisation have different approaches, constraints and priorities. So how to address all these differences within one methodology?
A successful migration methodology starts with fully understanding the requirements. Is the migration project strictly to migrate business functionality exactly “as-is” from one platform to another? Or is there actually a requirement to fix current problems with the JCAPS implementation? Is this an opportunity to extend functionality? Does the budget stretch to allow for redesign, even when the actual code will migrate "as-is" without much effort? Or does the JCAPS code have such important intellectual property, that rewriting it all is too large a risk with little benefit? Can some JCAPS projects be "black-boxed" and retired rather than migrated? What can the migration tool help with and what is the total effort of code migration?
The next step is to define a reference architecture for a Fusion Middleware solution that follows best practices. Customers who are new to Fusion Middleware often start with a short orientation with SOA Suite, OSB and Weblogic so that all are familiar with the products. Then, an evaluation project or a series of small workshops is conducted to flush out the requirements, to determine phased approaches to migration and to bring all stakeholders together, supporting the same migration project plan.
Finally the actual migration project is set in motion to implement the reference architecture using the migration tool, often in a phased approach.
Oracle’s JCAPS to FMW migration tool migrates JCAPS and SRE/e*Gate projects directly to JDeveloper where they can be compiled and deployed to Weblogic. The aim of the tool is to migrate all intellectual property, business logic and code artefacts to the equivalent FMW components. In particular, JCDs, OTDs, ETDs, BPEL business processes and supporting design patterns are migrated “as-is” and JCAPS connectivity maps or SRE/e*Gate schemas are migrated to Composites as needed.
This automated process not only avoids re-coding everything from JCAPS (often representing a saving of several years of effort), it also ensures that the resulting projects are compliant with JDeveloper, reducing risks and time to implementation. In all cases, what the tool generates is what you would implement as best practices by hand.
As an example here is a CM migrated to a Composite:
The following "diffs" were the only changes required to be made by hand to a typical JCD (in this case 2,500 lines long). All other code was retained as is, the project compiled and deployed and working in Weblogic:
You can request access to the tool in a number of ways. i would recommend reaching out to your Oracle Account team directly or raising a Service Request through Oracle Support. Alternatively, you can request the tool from either the Product Management (Suresh Sharma) or myself in the A-Team (Mike Somekh). The Tool comes with a full Use Guide and the A-Team has a quick-start sample and template structures that can be shared.
Successful customers are following Oracle's JCAPS to Fusion Middleware methodology, where the Migration Tool forms an important part of the process. Once the actual migration requirements and new functionality have been identified, a PoC or series of workshops to define the right reference architecture is often undertaken. The migration tool can be obtained from a number of sources including your Oracle account manager, Oracle Support, Product Management or the A-Team.