>> J2EE Releases and Technologies

J2EE Releases and Technologies
Java 2 EE Platform Releases
- Java EE 5
- J2EE 1.4
- J2EE 1.3
- J2EE 1.2

Java EE 5
Java Platform, Enterprise Edition 5 (Java EE 5) focuses on making development easier, yet retains the richness of the J2EE 1.4 platform. Offering new and updated features such as Enterprise JavaBeans (EJB) Technology 3.0, JavaServer Faces (JSF) Technology, and the latest web services APIs, Java EE 5 makes coding simpler and more straightforward, but maintains the power that has established Java EE as the premier platform for web services and enterprise application development.

The Java EE 5 SDK and Java Application Platform SDK provide support for Java EE 5 specifications, and the Java Application Platform SDK features additional runtimes such as Open ESB, Sun Web Developer Pack (Java Application Platform SDK Update 3 Preview only), Portlet Container, and Sun Java System Access Manager.

Get Started with the Java EE 5 SDK and Java Application Platform SDK

Enterprise Application Development Made Easy
The Java EE 5 platform introduces a simplified programming model and eliminates much of the boilerplate that earlier releases required. With Java EE 5 technology, XML deployment descriptors -- that is, side files for defining components and specifying deployment instructions -- are now optional. Instead, you enter the information as an annotation directly into a plain old Java object (POJO) without leaving your source editor. Annotations are a new feature, originally introduced in Java 2 Platform, Standard Edition (J2SE) 5.0. They are a form of metadata with a very simple syntax and recognizable because they begin with a leading at sign (@).

Annotations are generally used to embed in a program data that would otherwise be furnished in a side file. With annotations, you put the specification information right in your code next to the program element that it affects. This is a more intuitive and convenient approach.

The Java EE 5 platform provides annotations for the following tasks, among others:
- Defining and using web services
- Developing EJB software applications
- Mapping Java technology classes to XML
- Mapping Java technology classes to databases
- Mapping methods to operations
- Specifying external dependencies
- Specifying deployment information, including security attributes

Annotations typically contain several optional elements to allow detailed customization of an application. Also, the annotation framework is completely extensible, so future versions of the Java EE platform can expand the existing annotations and define new ones.

One immediate benefit of annotations for web services is that many formerly required markers, such as the extends java.rmi.Remote and throws java.rmi.RemoteException that were borrowed from remote method invocation (RMI), are no longer necessary.

Additionally, application packaging has been simplified in ways that go beyond what annotations allow. For instance, a Java EE 5 platform application is no longer required to contain an application.xml descriptor. If the descriptor is missing, the server automatically determines the type of each contained module through inspection and use of sensible defaults based on the file extension and contents.

Another example is the common task of bundling a number of library JAR files with an application. By default, the lib directory under the application root is reserved for library files. Previously, you had to add a manifest entry to the application module, which could be a tedious task.

Recently, engineers from the Oracle Corporation undertook two studies to measure the efficiency gain from using the Java EE 5 platform. Debu Panda, a product manager at Oracle, migrated a well-known application, AdventureBuilder from the Java BluePrints program, from the J2EE 1.4 to the Java EE 5 platform. See "An Adventure with J2EE 1.4 Blueprints" on TheServerSide.com. Raghu Kodali, consulting product manager and Service-Oriented Architecture (SOA) evangelist for Oracle, took a publicly available demo application called RosterApp that is included with the J2EE 1.4 tutorial and migrated the application to EJB 3.0 software. See the article "The Simplicity of EJB 3.0" published in JDJ.

Packaging Java EE 5 Platform Applications
The rules and conventions for packaging enterprise applications have been made much simpler in the Java EE 5 platform:

- Web applications use .war files.
- Resource adapters use .rar files.
- The lib directory contains shared .jar files.
- A .jar file with Main-Class is considered to be an application client.
- A .jar file with the @Stateless annotation is considered to be an EJB application.

Many simple applications, such as the following application types, no longer require deployment descriptors:
- EJB applications (.jar files)
- Web applications that use JavaServer Pages (JSP) technology only
- Application clients
- Enterprise applications (.ear files)

For example, a simple web application that provides a web service and an index page that describes the web service might contain only the following files:
index.jsp

- image/logo.gif
- WEB-INF/classes/MyWebService.class

No web.xml, webservices.xml, or Java API for XML-based RPC (JAX-RPC) files are required.
In similar fashion, an enterprise application example might contain only the following files:

- lib/shared.jar
- ui/web.war
- ui/client.jar
- biz/ejb.jar

And no META-INF/application.xml file is required.

Streamlined EJB Software Development
The EJB 3.0 API has been dramatically simplified. Effectively, the container does more work, so there is less work for the developer. The new version of the EJB API provides these benefits:

- Fewer required classes and interfaces. For example, EJB home and object interfaces are no longer required. Instead of a home interface, you now can supply a business interface only. There is no longer a requirement to implement the javax.ejb.SessionBean interface. Business methods need not declare that they throw checked exceptions any longer, which results in cleaner code.

- Optional deploymentdescriptors. Component definition and dependency injection are now possible through the use of annotations, removing the need for deployment descriptors.

- Simple lookups. Java Naming and Directory Interface (JNDI) APIs are no longer necessary on either the server or the client. Instead, a simple look-up method has been added to the EJBContext interface, enabling you to look up an object dynamically within the JNDI name space.

- Simplified, lightweight persistence for object-relational mapping. The new Java Persistence API has greatly simplified entity bean persistence. The new entity objects are POJOs that provide an object-oriented view of the data stored in a relational database. The specification also standardizes how such object-relational mapping information is provided.

- Interceptors. Interceptors are objects that can intercept a call to a business method. If you are familiar with aspect-oriented programming, you will recognize that the implementation of interceptors is a limited form of that concept.

In earlier versions of EJB software, callbacks from the container into the bean were supported through javax.ejb.SessionBean and javax.ejb.MessageDrivenBean implementations. Unfortunately, this approach adds clutter to the code when callbacks are not needed. With EJB 3.0 software, you can annotate methods to behave as callbacks. This removes the need for skeletal implementations of the life-cycle methods: ejbRemove, setMessage, setSessionContext, ejbActivate, and ejbPassivate.

Here are just a few of the annotations that can be used in EJB 3.0 software:
- @Stateless, @Stateful. Used to annotate a class as being either a stateless session bean component or a stateful session bean component.
- @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate. Used to annotate a method as a life-cycle event callback.
- @EJB. Used on the client to reference the business interfaces of other beans and the home interfaces, for EJB 2.1 or older beans.
- @PersistenceUnit. Used to express a dependency on an EntityManagerFactory.
- @PersistenceContext. Used to express a dependency on an EntityManager.
- @WebServiceRef. Used on the client to reference web services.
- @Resource. Used for all other resources not covered by @EJB or @WebServiceRef annotations.
- @Timeout. Specifies a timeout method on a component that uses container-managed timer services.
- @MessageDriven. Specifies a message-driven bean. A message-driven bean is a message consumer that can be called by its container.
- @TransactionAttribute. Applies a transaction attribute to all methods of a business interface or to individual business methods on a bean class.
- @TransactionManagement. Declares whether a bean will have container-managed or bean-managed transactions.
- @RolesAllowed, @PermitAll, and @DenyAll. Declare method permissions.
- @RolesReferenced. Declares security roles referenced in the bean's code.
- @RunAs. Uses the caller principal assigned to the specified security role to execute a method.

Examples From EJB 3.0 and EJB 2.1 Software
To show the benefits of the new programming model in EJB 3.0 software, let's compare how to implement the same code under both models. Example 1A shows the Java technology code for a hypothetical session bean using EJB 2.1 software.

Example 1A: Session Bean in EJB 2.1 Software -- Java Source Code

public class PayrollBean
implements javax.ejb.SessionBean {

SessionContext ctx;
DataSource empDB;

public void setSessionContext(SessionContext ctx) {
this.ctx = ctx;
}

public void ejbCreate() {
empDB = (DataSource)ctx.lookup(
"jdbc/empDB");

}
public void ejbActivate() { }
public void ejbPassivate() { }
public void ejbRemove() { }
public void setBenefitsDeduction(int empId,
double deduction) {
...
Connection conn = empDB.getConnection();
...
}
...
}

The same session bean can now be programmed using EJB 3.0 software as shown in Example 1B, with new features shown in bold.

Example 1B: Session Bean in EJB 3.0 Technology -- Java Source Code

@Stateless
public class PayrollBean implements Payroll
{
@Resource private DataSource empDB;

public void setBenefitsDeduction(int empId,
double deduction) {
...
Connection conn = empDB.getConnection();
...
}
...
}

Notice how the unused life-cycle methods can be eliminated from the code in the software's 3.0 version. Also observe how the @Stateless annotation is used to declare the class as a stateless bean component.

The implements javax.ejb.SessionBean statement is no longer needed. Instead, the bean class, PayrollBean in this case, implements the business interface, that is, Payroll. The @Resource annotation allows dependencies to be injected directly into the component when the container instantiates it, removing the need for the JNDI lookups, for example, in the ejbCreate method. Also, the @Resource annotation can be applied to a field with type SessionContext to replace the following EJB 2.1 software code:

public void setSessionContext(SessionContext ctx) {
this.ctx = ctx; }

The code is only half of the story. With EJB 2.1 software, our hypothetical session bean would require a deployment descriptor file, as in Example 1C.

Example 1C: Session Bean in EJB 2.1 Software -- Deployment Descriptor File

PayrollBean
PayrollHome
Payroll
com.example.PayrollBean
Stateless
Container

jdbc/empDB
javax.sql.DataSource
Container


...
...

But EJB 3.0 software requires no deployment descriptor file. The information previously contained in the descriptor is now inferred by the container, which looks at the annotations present on the component class. In many cases, the container will use meaningful defaults for the information, a resource authorization type of "container," thus making the descriptor redundant.

Some applications will still need to look up resources dynamically in JNDI. Such lookups can now be accomplished with a simple look-up method added to SessionContext, as in Example 2.

Example 2: Dynamic Lookup

@Resource(name="myDB", type=javax.sql.DataSource)
@Stateful public class ShoppingCartBean
implements ShoppingCart {
@Resource SessionContext ctx;

public Collection startToShop (String productName) {
...
DataSource productDB =
(DataSource)ctx.lookup("myDB");
Connection conn = myDB.getConnection():
...
}
...
}

In this example, the resource named myDB is looked up at runtime. This approach allows an application to decide which resources to access, based on their availability or on some other parameter such as quality of service.

In similar fashion, annotations can be used to replace entire sections from the existing deployment descriptors. With EJB 3.0 software, the deployment descriptor elements can be replaced by a @TransactionAttribute annotation placed directly on the method it affects, as shown in Example 3.

Example 3: EJB 3.0 Software -- Deployment-Descriptor Transaction Attributes

@TransactionAttribute(MANDATORY)
public void setBenefitsDeduction(int empId,
double deduction) { ... }

More Info: http://java.sun.com