The context
During the last years, you developed and invested in JCAPS, set up reliable infrastructure and deployed a solid integration platform. Today, your teams are trained and sharpened on JCAPS architecture and development.
Nevertheless, a background music tells you that this time is over, JCAPS is a deprecated technology, not improved for many years. Regularly, you receive emails informing you that Oracle support will finish in 2017 and every week, you meet consultants that push you to a “smooth migration” to another integration platform.
However, you are nonetheless loath to go to some other platform because you know the effort and the budget required to initiate and complete a migration. Despite the promises of consulting companies and editors that tell you the migration will be easy and inexpensive, you have a strange feeling that something is wrong. They promise you than 60% of your application will be transferred automatically to the new platform they propose.
Nevertheless, you know that usually, the migration of 20% of your applications will consume 80% of your budget and automatic migration tools will not solve this pitfall. Moreover, in their budget forecast, the consultants take into account neither the training of your development, infrastructure and support teams, the cost of the new license nor the time consumed to setup a completely new environment.
Moving to large editor product such as Oracle, IBM or WebMethods, often means walking into the lion’s den. For example: Oracle SOA Suite requires to install an Oracle database and a Weblogic application server and ultimately adopt Oracle portfolio. The context is the similar for IBM or Microsoft.
What is OpenESB?
OpenESB is a JCAPS sibling developed by Sun Microsystems. JCAPS and OpenESB are from the same family and share the same code. Consequently, a migration between the two products is simple and straightforward. After its merging with Sun, Oracle cancelled its support to OpenESB and any improvement on JCAPS. 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 an application server is not required to run OpenESB anymore, but just a simple JVM.
With its new architecture, OpenESB runs more efficiently with more reliability and overall, it relies neither on a Glassfish server nor any additional software. Its improve dramatically its reliability, efficiency and scalability. Today, OpenESB is the perfect integration platform from IoT to enterprise project.
Migration to OpenESB
During the last years, Pymma acquired a great skill on JCAPS to OpenESB migration. We help leading global companies and governmental organisations to move hundreds of applications from JCAPS to OpenESB.
Since the two products are very close, applications’ migration is evaluated in term of days, with minor impact on the architecture and application. Architecture, development, infrastructure and support teams’ skill are kept. Quickly, IT teams are operational and able to go forward and develop new and powerful applications. Your budgets are saved and the transition is successful without heavy impact on your development plan.
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.
Backward compatible with OpenESB and JCAPS, OpenESB EE is optimized and does not require a JEE container to run, but just a simple JVM. The improvement and the optimisation we made in OpenESB EE, made the product 100% faster than JCAPS with a memory footprint divided by two. Every day, OpenESB EE processes billions of messages and events for large companies and governmental organisation. 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 stay on the technologies coming from JCAPS, even after January 2017.
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 when they decided to start working with JCAPS.
For any further information on migration to OpenESB Enterprise Edition, please contact us at contact(-at-)pymma.com
FAQ on Migration to OpenESB
1- Could we migrate from Glassfish ESB to OpenESB EE?
Yes, OpenESB EE code inherits from Glassfish ESB code. The migration from Glassfish ESB is as easy as the migration from JCAPS.
2- Our applications have been developed with JCAPS 5 (ICAN, eGate…). Is the migration possible, as described in the document?
Yes, the migration is possible but will require more reengineering since OpenESB EE is not backward compatible with eGate and ICAN Suite. It deeply uses JBI features. In that case, the migration to OpenESB EE will not be as easy as a migration from JCAPS 6 with JBI architecture.
3-In JCAPS, we develop web services based on EJB. Without, an application server, how OpenESB EE supports these developments?
You are right. OpenESB EE does not embed an application server. To run your Java EJB services, there are many options.
If your services infrastructure relies deeply on JEE infrastructure, keep your application server to run EJB services (Glassfish, JBoss, Weblogic, Websphere…) and use Web Services to invoke them. Our customer feedback showed us that in the same sub-LAN the impact on the performances is negligible but the gain in flexibility important. In that case, we promote a split between service implementation and orchestration.
Alternatively, if you use your application server to run Java code, POJO components can be used in OpenESB. In OpenESB, POJO runs Java code and exchanges directly with the other component such as the BPEL.
Whatever your case, our consultants will help you to design the best and the most efficient solution for your migration
4-JCAPS used JNDI to access to the database. What about OpenESB EE?
OpenESB EE embedded a JNDI framework that replaces the one implemented on Glassfish Server. It provides access to your databases through your binding component as usual.
5-How do you manage component and applications without Glassfish Admin console.
OpenESB Enterprise Edition comes with a completely new web admin console. Light and efficient, the new console is very fast, whatever the number of composite applications and service units.