The Artima Developer Community
Leading-Edge Java | Discuss | Print | Email | First Page | Previous | Next
This article is sponsored by the Java Community Process.

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

Page 1 of 2  >>

Advertisement

Summary
Linda DeMichiel is Sun Microsystems' specification lead and chief architect for Enterprise JavaBeans 3.0 and the Java Persistence API (JSR 220). In the concluding segment of this two-part interview, she discusses the role of interceptors, dependency injection, the Java Persistence API, and how EJB 3 relates to other Web frameworks.

Frank Sommers: What are interceptors, and what role do they play in EJB 3?

Linda DeMichiel: Interceptors give you a convenient way to factor out logic that might be common to multiple components, or that you may not want to have main-line in your code. As an example, you might want to reuse auditing logic, logging logic, or perhaps security logic, in different components.

When a caller invokes a method on the business interface [of an EJB], before delegating that invocation to the component, the container interposes to provide transaction management services—whether to start or check for the existence of a transaction—and the container also interposes for security checks. After this interposition by the container, the interceptor is run.

The interceptor gives the application logic—the interceptor code written by the bean developer—a chance to interpose before the business logic is run. That way, for instance, you can audit who is calling what and under what circumstances. Or you might want to check the arguments [passed in to the business method], perhaps transform those arguments in some way, or you might want to check the results being passed back, or maybe do some custom security. That's typically more sophisticated functionality than you might find in straight business logic—logic that is a little more towards the system edge of the spectrum. So [interceptors] give the developer that interpositioning capability.

You can also insert lifecycle callback methods with interceptors, for example, if you wish to perform some action on activation or passivation. In those cases, interceptors let you move that functionality out of mainline code.

Interceptors' functionality is quite flexible in general. You can have default interceptors, interceptors that apply to all the components in your EJB JAR. You can have a number of default interceptors, and specify in the deployment descriptor the order in which they are run. You can also have interceptors that apply to specific component classes, and define one or more interceptors that run for all the business methods of a class, again specifying ordering. And you can define method-level interceptors that only run for a specific method, or multiple specific methods. And you can customize the ordering in which these interceptors run as well. You even have the capability to exclude default interceptors for a particular class.

Interceptors are configurable by both annotations or XML, with the exception of default interceptors—those can only be configured by a deployment descriptor, since there is no application-level metadata annotation for them.

Frank Sommers: Could you tell us about new features related to dependency injection?

Linda DeMichiel: We debated a number of techniques that we could potentially use [for dependency injection]. The goal was to simplify environment access, and to get away from the requirement of having to use the JNDI API. These were somewhat awkward to use—you had to catch the checked NamingException, for instance—and were an obstacle to newcomers learning EJB. We were looking for more flexible mechanisms.

Dependency injection, obviously, was not new to EJB. It was out in the community, [and] it served our needs, so it was one of the mechanisms we discussed in our early draft. And it seemed to get considerable traction: the whole [Java EE 5] platform as well seized upon its use.

In EJB 3, a developer annotates either an instance variable or a setter method with the corresponding annotation. When the instance is created, and before the bean comes online to service a method request, the container supplies the annotated component with the reference to the requested resource. Such dependency specification could be done in XML as well, but annotation is considerably more convenient.

The other mechanism is that of a simplified lookup method we added to the EJBContext interface. That allows you to express the dependency in either annotation or XML, and then call the lookup method to do a dynamic lookup at runtime rather than use injection. The lookup looks up the resource in the JNDI name space.

Both the injection and the lookup are wrappers around JDNI lookup. They're just a simplifying mechanism.

Page 1 of 2  >>

Leading-Edge Java | Discuss | Print | Email | First Page | Previous | Next

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