Upgrading to Java EE 7 from J2EE versions

Java EE 7 is now an immense step up in productivity from the J2EE 1.4 specification, yet there are many businesses out there still reliant on source code with legacy practices. Java EE 7 strongly leans on the annotations, therefore we recommend your business upgrades their Java SE environment to at least JDK 7. In February 2013, Oracle Java SE 6 declared End-of-Life of public releases (http://www.oracle.com/technetwork/java/eol-135779.html).

The serious actual effort of upgrading J2EE to Java EE is proportional to the number of lines in your application, whether it is based at all Java SE 5 or better, using generics, enumerations, and annotations. It depends on the interaction complexity in your existing software. The task can be straightforward, lasting several careful, agile development iterations, but it equally can be very tough to upgrade your software. Upgrading from J2EE in the future is set to get even harder, especially when the next standard, which is aimed at Moving to the Cloud, comes aboard. Our advice is simply to upgrade sooner rather than later.

Here are a few tips to help the architectural team along with this upgrade:

  • Please test and test continuously: Write lots of full encompassing unit and integration test suites, if you do not have them. Ensure your application is running against a continuous integration server like Jenkins, Hudson, or Atlassian's Bamboo.
  • Prefer annotations to XML configuration: Refactor your old stateless and stateful session EJB to annotated @java.ejb.Stateless and @java.ejb.Stateful. Replace singleton beans that utilize proprietary application server APIs with the standard @java.ejb.Singleton beans.
  • Prefer DI: Use the full power of strongly typed dependency injection. Prefer to inject dependencies in EJB with CDI @javax.annotation.Inject and replace those older JNDI lookup service codes. Prefer Resource Injection for database connections, JMS destinations, and concurrency executors with @Resource injection.
  • Simplify transaction declarations: Replace and remove declarations for container manager transactions, because they are implied in EJBs.
  • Remove older EJB Remote and Home Java interfaces: Do this because they are no longer required in Java EE 7. We assume that you have tests!
  • Take care of J2EE Entity Beans: Examine cases where J2EE entity beans are being used very carefully. Refactor them into JPA entity beans in the Entity Control Boundary (see Chapter 1, Java EE 7 HTML5 Productivity) pattern. Move the business logic surrounding the older entity beans into the appropriate architectural layers.
  • Clean up XML deployment descriptors: Prefer the recent Java EE ease-of-development feature: Convention-Over-Configuration. Delete extraneous and unnecessary XML configuration where appropriate.
  • Upgrade messaging: Upgrade your Message Driven Beans with annotations to use JMS 2.0. Many enterprises send messages asynchronously; upgrade those senders to annotations around JMS 2.0.
  • Review the upgrade: Review the lifecycle of endpoints, consider the impact of management for session beans, remoting, transaction handling, concurrency, and state management.
  • Prefer Java EE 7 asynchronous feature: Upgrade the application parts that rely on proprietary application server's asynchronous and concurrency features; see if you can replace them with the Java EE 7 platform standard. Pour over the Concurrency Utilities and @Asynchronous methods in EJB.

These tips should help you get over the curve to a fully working, tested, and ingrained Java EE 7 application. Only then should your architects decide on approaching new features: CDI, JAX-RS, and WebSocket.

Note

Golden rule of performance and migration: Test before, test afterwards, and measure the difference between the results.

Legacy application programming interfaces

CORBA and Object Request Broker is a technology designed in the late 1990s into the millennium, which provided inter process communication over distributed systems. This standard of communication is still maintained by the Object Management Group. IIOP systems can be implemented in any language such as Java, C++, or C#. RMI is the Java implementation over this protocol.

The full specification of Java EE 7 permits the removal requirement for supporting EJB. CMP (Container Managed Persistence), BMP (Bean Managed Persistence), JAX-RPC, deployment API instead are made optional. Support, therefore, for CORBA, is now optional for application server products.

The following table lists the other older technologies that are supported or are optional in the Java EE 7 standard:

Name

Description

RMI-IIOP

Remote Method Invocation over Internet Inter-ORB protocol is a framework designed to support interaction of abstract protocols of object request brokers, specifically with legal CORBA services.

Java IDL

Java Interface Definition Language is a component service and tooling that permits Java EE application components to invoke CORBA objects. The functionality is closely associated with RMI-IIOP. Java applications, therefore, can act as bonafide clients of CORBA services. Only legacy Java EE application may require this service.

JAF

JavaBean Activation Framework is an extension support framework. It is designed to allow developers to write code that handles data in different MIME types. JAF is extensively used by the JavaMail API

JAAS

Java Authentication and Authorization Service is part of the Java SE; some Java EE 7 application server products may elect to use it as a security feature.

JAXP

Java API for XML Parsing, a framework for using SAX and DOM XML parsers in Java.

STAX

Streaming API for XML, a framework for processing and parsing XML documents using a stream pipeline of input to output, which can be very efficient for large data sets.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.12.136.119