The Artima Developer Community
This article is sponsored by the Java Community Process.

Leading-Edge Java
Refactoring the EJB APIs
A Conversation with Linda DeMichiel, Part I
by Frank Sommers
June 13, 2006

<<  Page 2 of 2

Advertisement

Annotations or XML?

Frank Sommers: One of the things the specification no longer requires is deployment descriptors, but the EJB 3 specs still allow their use. What guidelines can you give us for deciding when to use annotations and when to use a deployment descriptor?

Linda DeMichiel: The EJB specifications don't give such guidelines, but I'll give you some of mine. Annotations are very useful for things that are semantically part of the application. As an example, consider dependencies that your application has on an environment resource. That's intrinsic to your application: If that dependency is not satisfied, then your application isn't going to run. So that's a declaration of a dependency. Dependency on another EJB with a particular interface type is another such dependency. Those dependencies will have to be satisfied in the deployment environment, but are also intrinsic to the semantics of the application.

I would argue that the transactional structure of an application is also quite intrinsic to the behavior of that application: If you're using user transactions [UserTransaction API] versus container-managed transactions, that's not something that can be changed later in the deployment cycle. That's something that would be appropriate for annotations, as are the transaction attributes.

Some other aspects of an EJB application are more amenable to later binding. An example is the exact configuration of what security roles are allowed to invoke what methods. You might want to use a deployment descriptor for that to externalize that information so that [security] might be more readily configurable per deployment environment. Except for such cases—where you would want late binding—what was [specified] in the earlier deployment descriptors is now appropriately expressed in annotations.

You would also use a deployment descriptor for default interceptors. These are interceptors that apply to all of the components in an EJB JAR. Using Java language annotations, there is currently no way to express through the annotation mechanism that an annotation applies to an application, not just to some smaller scope, such as a method or a variable or even a package. Given the absence of application-scoped metadata annotations, you'd use the deployment descriptor for that.

I want to make another point here about the use of XML with the Java Persistence API's O/R mapping configurations. Again, with Java Persistence, some annotations are expressing semantics that are intrinsic to the application: for example, relationships—what's a related entity, what is the cardinality of that relationship, or what an ID field is. These are, basically, logical-level annotations.

There is another set of annotations that are generally separate from the logical ones. These have to do with the physical mapping to a relational database, such as table and column, join column, or secondary table annotations. These are often specific to the database that is being mapped to. If you wanted your application to be deployed across different database systems with different configuration properties, you might want to externalize these O/R mapping annotations to XML. If you externalize annotations that deal with the column and table-level mapping, in particular, you could potentially define alternatives that are each tailored to a particular database system.

Frank Sommers: Is it possible in the EJB 3 APIs to mix and match annotations and external deployment descriptors?

Linda DeMichiel: Yes, it is possible in both APIs [the EJB 3 Core and the Java Persistence API]. You can use a combination of annotations and XML, and you can use XML as an overriding mechanism. You have considerable flexibility in the configuration.

For instance, you are permitted to override certain annotations in XML. That way, you could have part of your metadata in the form of annotations, and part in the form of XML and combine them in an overriding way. In addition, you can use XML as a complete alternative to annotations. By the way, it's possible also in the Java EE 5 platform in general to specify that you want only the XML to be used as definitive rather than a combination of XML and annotations.

Simplifying the EJB Interfaces

Frank Sommers: What changes were made to the home and remote interfaces in EJB 3?

Linda DeMichiel: We simplified what in the earlier specification was called the component interface—the EJBObject or the EJBLocalObject interface—and we now term that a business interface. It's not an EJBObject interface any more, just a Java interface exposed as the business interface of a component. That interface can be remote or local. By default it's local, but you can specify it as remote either by annotation of the interface or the bean class, or using XML.

In addition to not being an EJB object interface, another difference is that the business interface's methods are no longer required to throw a RemoteException. If you [still] wanted to expose a RemoteException, you are permitted to do that, but it is no longer required.

Frank Sommers: What are the semantics of network failure in a remote interface?

Linda DeMichiel: EJBExceptions are thrown. If needed, the developer can unwrap those EJBExceptions to expose whatever the protocol-level exception was, and handle that exception in an appropriate way.

Frank Sommers: What changes were made to the home interfaces?

Linda DeMichiel: These were an interesting case. We need to distinguish between stateless and stateful session beans here. In the stateless session bean case, in the earlier EJB specs, the home interface was a placebo because it didn't really create the instance. The container was permitted to create the instance in advance, [or] to pool it and use a pooled instance when a stateless session bean was needed. Basically, ejbCreate() did not necessarily create the stateless session bean instance.

Because this [type of] bean is stateless, there wasn't a need for a ejbCreate() method. Instead, by simply pushing more work onto the container, the creation could be handled at the time of the business method invocation. That is, if you needed an instance [of a stateless session bean] to delegate the business invocation to, you could either create such a bean, or retrieve one from the pool. It was not necessary to maintain the home interface API to do that.

Stateful session beans are a little more interesting because the stateful session bean ejbCreate() method in the 2.X APIs performed the useful function of initialization. When it came time to simplify stateful session beans, we wanted to simplify them in much the same way as we did [with stateless session beans]. There is no reason the initialization step could not be handled by a business method rather than a special ejbCreate() method. By regarding initialization as part of the application API, we could eliminate the requirement for home interfaces for stateful session beans as well.

Frank Sommers: Did any of the EJB bean lifecycles change?

Linda DeMichiel: Bean lifecycles are basically the same, but lifecycle callbacks are simpler. In earlier EJB versions, a stateless session bean was required to implement the SessionBean interface. That interface had the ejbActivate() and ejbPassivate() methods on it, which were never used for stateless session beans. On stateless session beans, these methods were always empty, and that was just not a good situation. I always thought that stateless session beans should be unencumbered by these methods.

Again, we leveraged Java metadata annotations so developers can use annotations to specify lifecycle callback methods when, and where, such callbacks are useful. Instead of implementing to the interface, you just specify what you need. That can either be done in a method on the bean class, or you can factor that out of the bean class and place such callbacks on an interceptor class. You don't need to have such callbacks in your main-line code.

Next week

Next week, in the concluding segment of this interview, Linda DeMichiel will discuss the role of interceptors, talk about the Java Persistence API, and share her thoughts about future directions for the EJB standard.

If you'd like to receive a weekly newsletter announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Talk back!

Have an opinion about EJB 3? Discuss this article in the Articles Forum topic, Refactoring the EJB APIs.

Resources

The EJB 3.0 specifications, including the simplified document mentioned in this article, are available at the following URL:
http://www.jcp.org/en/jsr/detail?id=220

About the author

Frank Sommers is an Artima senior editor.

<<  Page 2 of 2


This article is sponsored by the Java Community Process.

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us