Comments on J2EE Development without EJB (1)

I am reading Rod Johnson’s J2EE Development without EJB. His first book J2EE Design and Development is solid and obviously backed by extensive real life design and development experiences.

This book has more bluff than stuff in the first five chapters. Chapters 6 and 7 provide a good high level explanation on IoC, particularly Dependence Injection. It does a fine job to make the case for DI. But I think a detailed description of how DI is achieved technically will leave developers new to this concept a deeper impression.

The bottom line here is that advanced level developers in J2EE domain all know how JNDI and other service lookup mechanism work and the mechanism behind Dependence Injection, no matter through Setter or Constructor, is no more complicated than JNDI. However, most of the literature available on DI in the public domain seems intentionally keep it as a myth. That does not help to push it to a boarder audience.

The BeanFactory centric configuration framework generally makes application configuration consistent and to be well organized. The following features are particularly interesting:

(1) Easy to setup of collaborating object graph
(2) Strong support for properties defined by Set, Map and List etc..
(3) Implementation of lifecycle management in the infrastructure layer without mandating the beans to implement interfaces as this is usually done.
(4) The powerful tree structure of ApplicationContext, equipped with an important overriding mechanism
(5) Freedom in allocation of the bean definition files

While this framework should be enough for most low-end or mid-range J2EE applications, for which the Spring framework is targeting, high-end J2EE applications may need more. Based on my experiences in architecting and developing an OAM framework for a telecom middleware, the following features are very important for those high-end J2EE applications:

(1) Support a web or other interface in a loosely coupled approach; by “loosely coupled” I mean the configuration framework should immune from changes in the interface side.
(2) Validation of changes defined by the configuration objects but enforced in the interfaces.
(3) Complicated configuration may require operations on configuration objects. Setting properties and doing post-processing may not be enough, or may not be feasible.
(4) Configuration changes may need to be reported and monitored, properly by a industry-strength management software such as HP Openview, IBM Tivoli and others, typically wired through versions of SNMP protocols.
(5) Collaboration of configuration objects (beans in Spring framework) in more rigorous approaches (not only through static reference), such as cascading changes and overriding in runtime.
(6) Configuration objects may have to serve in three different levels: JVM, class and instance. This, in Spring’s term, means the runtime may require different instances of the same bean to serve different system components, and the state of those instances may not be always the same.
(7) Security features built in the configuration objects such that different credentials may see different views of the configuration objects in the interface.

The OAM framework that my colleagues and I came up is based on JMX using Jarkata Modeler. The configuration object follows JavaBean conventions as Spring Framework does. It does not rely on an application server either. In the OAM framework, we used Castor for XML and Java objects mapping, but other similar tool such as XMLBeans should also work. The JMX implementation we used there is the one in Weblogic server, but it can be replaced with such open source one as MX4J. Front-end is based Struts with several open source tools for tree rendering and tab generation. Validation rules are defined in the configuration objects through source-level metadata and compiled with xDoclets.

All the above list features are supported in the OAM framework.