|
IoC in Beehive
by Garrett Conaty
October 13, 2004
The Inversion of Control (IoC) pattern facilitates loose coupling in Java code. More aptly named dependency injection by Martin Fowler, IoC addresses the binding time of an implementation class to an interface. In a tightly bound Java application, a client directly instantiates an object that implements some interface. For example, suppose you have the following class:
class DiscountPricingService
implements PricingService {
Money calculatePrice(Customer c, Product p};
}
Then a client using this service to generate a sales quote might have a method:
public Quote generateQuote(…) {
PricingService pricer =
new DiscountPricingService();
pricer.calculatePrice(…)
…
}
This instantiation might be wrapped by using a factory object, but the net result is the same—though the client is using interface-based programming, it is tightly coupled to the implementation of that interface.
The IoC solution to this direct instantiation is to invert the control from the client to an assembler outside the client. A client specifies the interfaces of the objects it requires and an assembler provides the needed implementations. The Beehive control framework provides a powerful IoC solution that leverages the metadata annotation capabilities of J2SE 5. Beehive controls facilitate IoC through two annotations: @Control and @Context. Because controls are deployed into a container, these annotations form an implied contract that the container must honor for them to be deployed.
Declaring that your code uses the services of some control is as simple as:
class QuoteGenerator…
@Control PricingService pricer;
This type of variable declaration has been around in some form since WebLogic Workshop 7.0 and is refined by Beehive. With this declaration, the QuoteGenerator can use the PricingService without being tightly coupled to an implementation. In fact, the PricingService might be represented by a remote Web service, an EJB, a plain old Java object (POJO), or a database stored procedure. During the control assembly phase, a Beehive container will inject the proper implementation into the client.
Similar to a control client using @Control to specify its needs, a control provider specifies the environment its control needs with @Context. These contexts include support for basic life cycle, dynamic properties, Web tier, and EJB tier among others. As a simple example, the JMS control does initialization work and cleanup during its life cycle. The JMS control author specifies this need as:
@Context ResourceContext resourceContext;
In this case, declaring this variable ensures that the control must be deployed into an environment where the life cycle events onAcquire() and onRelease() will get triggered on the control implementation.
Effectively, @Context is a realization of IoC that allows loose coupling between a control and a container. With Beehive, a control doesn't need to be hard-coded to any vendor's container, but can be deployed to WebLogic Server, Tomcat, and so on if that container can provide the needed contexts. In this way, Beehive facilitates investment protection for the control developer.
The Beehive framework uses the @Control annotation to enable loose coupling between the control client and implementation. Loose coupling between a control and its environment is provided by Beehive through @Context. Through these annotations, the Beehive control framework provides an elegant IoC implementation that will help you avoid building tightly coupled Java applications.
About the Author
Garrett Conaty is a principal technologist at BEA; he works with the Beehive team on developer and partner adoption activities including the development of Beehive service control packs.
Back to top
|