The J2EE community has seen a growing trend toward lightweight containers that provide an integration framework to wire Java services. Examples of these frameworks include Geronimo’s GBean, the Spring Framework (or Spring), Jakarta’s HiveMind and Pico. Common to all these frameworks is that they are all more or less based on the Inversion-of-Control (IoC) principle.
The IoC principle is based on the separation of concerns concept which in computer science specifies that a complex software system should be partitioned such that each component has a clearly defined focus or interest while the overlap of functions between components is minimized [1]. IoC in particular focuses on the separation of concerns between a framework and its hosted services. A service should focus entirely on its business logic and not on how it interfaces with the framework and other services. The framework’s concern is then to make sure all its services are properly wired and their lifecycle managed.
Based on this principle, one of the most prominent design patterns employed by IoC is Dependency Injection [2]. Applying this pattern, the container resolves and creates all the dependency references for a Java service and all configuration data, and “injects” these references into the said service. When a service is started by the framework, all its references are already created and bound to local variables. Thus, services are mutually encapsulated as their implementation details are known only by the framework, not between the services themselves.
Along with this IoC container trend comes a school of thought that emphasizes noninvasive frameworks. A non-invasive framework means that its components need not implement any framework-related code in order to be managed by the framework. In other words, non-invasive frameworks can manage components that have no knowledge of the underlying framework. This non-invasive concept advocates encapsulation between components and frameworks that allow components to be highly portable across frameworks.
The GlueCode team, having worked on various versions of Geronimo’s GBean framework, is the first team in IBM to advocate building portable components based on the IoC principle with a non-invasive framework. More specifically, the GlueCode team identifies eleven best-practice principles in Java programming that serve as the guidelines to develop portable components. This document describes in detail the eleven while discussing what they are and how they can be adopted.
By: Woody Yun-Wu Huang; John Ponzo; Matt Hogstrom; Dain Sundstrom; Tom Musta
Published in: RC24092 in 2006
LIMITED DISTRIBUTION NOTICE:
This Research Report is available. This report has been submitted for publication outside of IBM and will probably be copyrighted if accepted for publication. It has been issued as a Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and specific requests. After outside publication, requests should be filled only by reprints or legally obtained copies of the article (e.g., payment of royalties). I have read and understand this notice and am a member of the scientific community outside or inside of IBM seeking a single copy only.
Questions about this service can be mailed to reports@us.ibm.com .