Converting Java EE Applications into OSGi Applications Author: Nichole Stewart Date: Jan 27, 2011 2010 IBM Corporation
THE INFORMATION CONTAINED IN THIS REPORT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. ALTHOUGH EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BYIBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS REPORT OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS REPORT IS INTENDED TO, OR SHALL HAVE THE EFFECT OF CREATING ANY WARRANTY OR REPRESENTATION FROM IBM (OR ITS AFFILIATES OR ITS OR THEIR SUPPLIERS AND/OR LICENSORS); OR ALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING THE USE OF IBM SOFTWARE. 2
Contents Trademarks and Service Marks Executive Summary Audience What are Enterprise Bundle Archives (EBAs)? Advantages of EBAs Scenario Description Types of Applications Converted JEE Conversion Testing Conversion Procedures Tooling Known Limitations 3
Trademarks and Service Marks The following terms are trademarks of the IBM Corporation in the United States or other countries or both: IBM WebSphere WebSphere Application Server Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product and service names may be trademarks or service marks of others. 4
Executive Summary The goal of this document is to outline the steps by which the Persona Test (PT) team converted various Java EE applications into OSGi applications. After reading this test report, you should gain a better understanding of how WebSphere PT tested the conversion of JEE applications into OSGi applications. Additionally, some observations, recommendations, and known limitations in this area are shared. 5
Audience This document is intended for application developers and others who desire an understanding of the type of application conversion testing performed prior to the release of the WebSphere Application Server v7 Feature Pack for OSGi Applications and Java Persistence API 2.0 v1.0.0.0. The WebSphere Application Server test team has defined several customer personas that describe fictitious types of customers with unique but consistent patterns of WebSphere usage. The testing described here simulated the activities for several of our company personas: Carlotta Little (CLL), Client Securities Corporation (CSC), and EnthusiaTech (ENT). CLL applications currently use 3rd party libraries and they have multiple applications that use the same libraries. They wish to convert some of their applications to take advantage of versioning control and reducing the memory footprint of loading multiple versions of the same libraries into the JVM. 6
Audience CSC wishes to take advantage of the modularity of OSGi applications so that they can easily extend and maintain their applications. ENT believes that JEE industry trends generally lead to improved productivity, better application performance, and increased customer satisfaction. They therefore watch these trends closely and adopt many new technologies, including Service Oriented Architecture, to which Service Component Architecture (SCA) is a key contributor. ENT would like to take advantage of the OSGi features in their SCA applications. 7
What are Enterprise Bundle Archives (EBAs)? An EBA file is a single zip archive with a.eba file extension that contains an application manifest and (optionally) a set of application modules. An application module can either be a WAR file or an OSGi bundle. 8
Advantages of EBAs Modular and Extensible Applications Problem: Extensible web applications have turned to OSGi to provide the modularity characteristics required to enable extensibility. But these applications have to include their own OSGi framework as part of the application. Solution: OSGi FEP provides the application-level OSGi infrastructure required by such web applications, integrated into the WAS runtime Problem: Multiple Java EE applications using the same libraries each install their own isolated copies of these libraries Solution: OSGi applications can be assembled to resolve against libraries in a shared repository, reducing disk and memory footprint Problem: Application using 3 rd party libraries have little control over the dependencies these libraries have and can suffer from versioning conflicts between different libraries. Solution: OSGi bundle versioning enables multiple versions of the same library to be loaded concurrently within a server 9
Advantages of EBAs Development Simplicity Leverage Spring-like simplicity, including unit test of business components outside the server, but governed by OSGi standards and integrated with proven Java EE technologies WebSphere integrated to deliver enterprise scalability, management and QoS Optionally composeable as SCA components into SOA applications 10
Scenario Description This scenario is designed to test the conversion of various applications from JEE technologies to OSGi technologies as well as ensure that JEE applications continue to run without issue once the OSGi technologies are applied to the WebSphere Application Server (WAS) environment. There were various WebSphere environments tested with the application conversion. The environments include WAS Base and WAS Network Deployment (ND) cells. Some environments were fairly small (single Base server) while others were much larger (4-6 nodes with a cluster for each application installed). 11
Types of Applications Converted WARs not contained in EAR files Simple EAR files containing a single WAR file More complex EAR files containing multiple WAR files and/or utility jars WAS sample EAR files Sample EAR files sourced from the web Internal test applications that exercise specific functionality of WAS 12
JEE Conversion to OSGi Testing Sniff simple EAR migration Unit test WAR-WAB Component test WAR-WAB Multiple sources: Internal test applications Sample EARs sourced from web Custom EARs (e.g., multiple WARs) WAS Sample EARs Complex EAR migration m o r e c o m p l e x Customer realistic EJB 3.0, JMS, JPA conversion EJB 3.0, JMS, JPA + new features WAR utility jar support WAR migration Legacy WAS from pure OSGi bundle (e.g., JMS) Investigative testing for potential new migration routes SCA, SDO, ATOM, JMS, WS SCA, SDO, 1-way, PubSub, JMS Spring / Hibernate conversion All applications used during this testing were applications that were run during prior releases of WAS or were sample applications Goal: Ensure that it is possible to convert JEE applications to OSGi applications 13
Conversion Procedures Automatic Conversion Rename the EAR file (.ear) to an EBA file (.eba) In WebSphere Application Server, import the EBA file as an asset Optional: Modify any migrated JavaTM 2 security settings Any existing was.policy file is converted into a permissions.perm file to be used with the OSGi permissions framework and all permissions are promoted to the application level. If finer granularity is needed, then you can modify the file after conversion. Results of Automatic Conversion: The WAR files are automatically converted to web application bundles (WABs) Any was.policy file is converted to a permissions.perm file Any utility JAR or EJB JAR files are not converted EJB function is not directly accessible in the EJB container 14
Conversion Procedures Utility JAR conversion Ensure EBA can use utility JAR files by doing one of the following: Easy solution: Move the JAR file to the WEB-INF/lib directory of the WAR file, but this does not give all the benefits of OSGi. Convert the JAR file to an OSGi bundle OSGi bundle could then be included in the EBA directly OSGi bundle could then be added to a repository where it is available to multiple OSGi applications and helps to reduce the footprint of the application 15
Conversion Procedures EJB Conversion a few options are available Remove annotations and references to EJBs from a servlet (OSGi bundle and WABs cannot directly look up and invoke an EJB) Change the application to interact with EJB modules by sending JavaTM Message Service (JMS) messages so that the EJBs or message driven beans (MDBs) can retrieve those messages from those destinations and reply to them All JAR files in an EJB must be converted similar to how the utility JARs were Use a Service Component Architecture (SCA) environment and specify bindings in that environment In general, it is recommended to use SCA over JMS for the EJB conversion because this isolates the OSGi application from the details of the integration. Therefore, the OSGi application code is simpler and cleaner. 16
Conversion Procedures Spring Framework Conversion After automatic conversion, the application is an EBA but will still use the Spring Framework instead of the OSGi Framework Identify the Spring Framework components and replace them with the equivalent code to make them plain JavaTM objects (POJOs), then modify the XML files so that the OSGi framework manages the objects. This involves: Removing any Spring Framework API calls Converting Spring configuration XML into standard OSGi Blueprint XML 17
Tooling Rational Development Tools for OSGi Applications, Version 0.6 http://www.ibm.com/developerworks/rational/downloads/10/ rationaldevtoolsforosgiapplications.html Command-line console for debugging bundles at run time http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/ com.ibm.websphere.osgifep.multiplatform.doc/topics/ ta_admin_runtime_console.html 18
Known Limitations EJBs are not automatically converted EJBs cannot be invoked directly from an OSGi application Utility jars are not automatically converted Spring Framework code is not automatically converted Web bundles and persistence bundles are not compatible regarding injection of persistence contexts The directory structure within the installedebas directory might change 19