Part of the reason for industry standards to exist is to avoid vendor lock-in. Such was the premise of J2EE (now JEE) – mostly fulfilled. It is not that hard to take well written JEE application and migrate it from one vendor JEE 5 or 6 runtime to another. IBM provides free migration plugin for Eclipse to do just that and supports migration of applications from JBoss, WebLogic, OAS, Tomcat and older versions of WAS into WAS v7 and v8. There are tutorials and books written on this subject (in fact, I co-authored one of the migration redbooks). Here is a nice recorded demo that shows automatic application migration from WebLogic to WebSphere.
IBM also offers a class WebSphere Application Server V7 Workshop for WebLogic Server Administrators. In the past few years hundreds of customers migrated from WebLogic Server to WAS and the methodology is well proven by IBM own migration team as well as several IBM business partners.
Can one take BPM application and migrate it from one vendor runtime to another? The short answer is: “it depends”. Generally the migration of a BPM application from say Oracle BPM (or other BPM) to IBM BPM is not nearly as easy as migrating JEE application, however there are few options available:
- One such tool is the IBM BPEL 2.0 Importer. This article describes the tool in detail. The WS-BPEL 2.0 Importer translates process definitions compliant with the OASIS WS-BPEL 2.0 standard. The Importer can be installed on IBM Integration Designer 7.5 (also on WID 7.0.x) and produces process definitions in the BPEL dialect understood by IBM BPM. It has been tested with BPEL artifacts created with several 3rd party BPEL designer tools. The BPEL Importer is relatively new, but has already been used successfully at several customers to migrate Oracle BPEL Process Manager applications to the IBM WebSphere BPM. As you may have guessed the migration is not 100% automatic. In most cases, there is still the need for manual post-processing where language elements cannot be automatically translated to “IBM BPEL” – typically activities with inline Java code, custom written XPath functions, and handful of BPEL elements. Nevertheless, the tool provides a substantial first step in migrating BPEL artifacts into the IBM BPM environment.
- One might wonder what is going to happen with all the processes that are “in-flight”? There is no out of the box solution here, but it is possible to automate and had been done in the past. The trick is to use the BPM runtime APIs to (1) extract process states and data from one implementation and (2) import them into a new BPM runtime using APIs of such target runtime. In case of IBM BPM these APIs are quite robust and here is one such example of how it can be done.
- Another option is the ability of the IBM Process Designer to import (and export) BPMN 2.0 generated by 3rd party tools. Did you know there are 73 implementations of BPMN today? The diagram below shows an example how BPMN 2.0 today is used to exchange models between IBM and 3rd party tools:
Enterprise Service Bus (ESB) migrations
Unlike BPMN and BPEL in the business process management space, the ESB does not have any industry standard for the flow markup language, hence all ESB products use proprietary languages to implement the integration logic. However migrating from one vendor ESB to another is not a complete rewrite. Suppose you have an application built on Oracle Service Bus (or older BEA AquaLogic ESB) or other vendor ESB product (Tibco, webMethods, Mule ESB, etc.) and wanted to migrate it to IBM WebSphere Message Broker or WESB. Such migration would still be faster than if you had to build that application from scratch. Here is why:
- WSDL, XSD, XPath and XSL transformations can be reused with relatively little rework.
- Overall flow logic already built on Oracle ESB can be re-implemented in WebSphere Message Broker Toolkit quickly just by looking at the printout of the flow (if not writing a tool to migrate). This is orders of magnitude easier than starting completely from scratch. Here is an example of such tool for JCAPS migrations as described by Eric Berg in his post.
- Custom built Java code from OSB (or JCAPS or other ESB) can potentially be reused in WMB or WESB since both support “compute nodes” in Java.
- Databases, JMS and WebSphere MQ configuration and queues can also be easily reused in WMB and WESB.
As you can see migrating ESB implementations is not as hard as it may seem, despite the lack of the standard “ESB flow” language.
One might think that SQL being a standard for so many years would make it very easy to switch databases at a moment notice. However it has not been the case. It used to be that changing the database was a very difficult task – primarily because RDBMS vendors introduced a number of proprietary extensions on top of the standard SQL. Those extensions are useful because they make application development easier, but at the same time they do create vendor lock-in. This is why IBM has added compatibility layer to DB2 that makes it much easier to port Oracle databases. IBM DB2 9.7 has out-of-the-box support for Oracle’s SQL and PL/SQL dialects. This allows many applications written against Oracle to execute against DB2 virtually unchanged. This article DB2 fundamentals for Oracle professionals: Migrating from Oracle to DB2 explains it very well.
Technical migration is only part of the issue and often not the hardest one to overcome. Skills, culture, experience, risk, even politics play significant role. Did I mention financial side? Luckily this last one is often easy to solve as IBM has very competitive pricing compared to Oracle.
On the other hand if you are an Open Source user and like to get your software free of charge with optional paid support, you still may consider IBM software. In the context of a bigger picture, the cost of license and support over the life time of the project is not as significant as one might think. Number of independent university researchers suggest that software license and support costs are only about 10% of the project total cost of ownership over the life of the project. So why not pick up the best tools you can find? I know how I do my shopping for tools. I have completed a number of home renovation projects (most of them in my own house and backyard) and when I go to Lowes or Home Depot, I know the difference between the low end and professional tools. I have never done a home renovation project for a fee, but still I am willing to pay the premium for professional tools since I am using them a lot – not just once a year. To me the ROI of those investments is big and easily noticeable (especially when I am in the middle of the project and the “cheap” tool breaks).