Suggestions in Documenting Hibernate

Hibernate type system defines entity type and value type; the difference between them is that entity type has its own independent life cycle in terms of persistence but value type does not have. While Hibernate Reference for 2.1.6 describes this precisely, the Hibernate in Action book causes some confusion when it discusses “component” and defines it as “a user-defined class that is persistent to the same table as the owning entity” (page 94). The book also causes confusion when it claims value type does not have database identity. Examples in Chapters 6 about collection of value type are clearly contradicted to such a claim.

I think neither the reference document nor the book does a good job in describing collection, component mapping and association. But those topics are the most difficult ones to both beginners and experienced users, and correct understanding of those topics is critical in real-life application of Hibernate. The community should try to do a better job on this front.

I suggest an exposition along the line of following ideas:

(1) Entity and value type are defined as in the paragraph
(2) Component is user-defined value type
(3) Collection can be entity types or value types, particularly components
(4) Association is relationship among entity types
(5) Aggregation is relationship between entity type and contained value types
(6) Navigation direction is an issue for both association and aggregation relationships
(7) Multiplicity is an issue for both association and aggregation relationships, and collection appear as the many side of association and aggregation.
(8) Cascading behavior applies to both association and aggregation relationship
(9) Fetching strategy applies to both association and aggregation relationship
(10) “inverse” is an indication for bi-directional relationship, with purpose of tuning persistent life cycle actions by Hibernate

Generally the exposition should refrain from discussion on the how objects are persisted in database, instead, follow strictly a top-down approach with the well-accepted persistence techniques for various objects and object relationships. Otherwise, the exposition can be so complicated that there is just no way for people not to be lost.

Comments on Hibernate in Action

Hibernate in Action by Christian Bauer and Gavin King is probably the best book of its type. I mean the type of book that teaches a popular development tool (other books in this category includes those on JUnit, XDoclet and Ant etc..).

It is best because of several reasons. (1) Object/Relational Mapping is one of the fundamental problems every developer in this era (when object-oriented language and relational database are the corner stones of almost all enterprise systems) needs to have a minimal understanding. It deserves a serious exploration in computing literature. (2) It has a fine balance in discussing the general concerns in ORM and introducing the specific solution in Hibernate. The first aspect provides the necessary depth that similar books usually lacks. (3) The authors obviously have a clear understanding of developers’ mentality, therefore are able to articulate the topics in a logically cohesive manner that is certainly very accessible to developers.

I particularly like the discussion on the relationships among application transaction, system transaction, session and variables in ThreadLocal scope. Those relationships are critically important for enterprise developers, and never related to the real–life technical professional better elsewhere. For example, in JMS specification, relationships among Thread, Session and Transaction are not well defined. In JSP and Servlet specifications, variable scopes such as Application, HttpSession, Request and Page are deservedly emphasized, but transaction issues, particularly concurrency, puzzle a lot of beginners.

Another interesting discussion is on “Dirty Check Strategy” in the appendix. Interception has a lot of use cases, therefore the similar strategies have been used in quite several other spaces such as AOP etc.. I had a similar requirement in synchronizing objects with persistent XML in a configuration framework. The lack of interception in Java has pushed Chain of Interceptor pattern to a prominent status in J2EE development community. It will be interesting to write an article comparing all those strategies and comments on their pros and cons in various use cases.

Comments on J2EE Development without EJB (2)

Further thoughts on IoC, particularly, Dependency Injection (DI).

DI is depicted as a mechanism to enable collaborations among objects. But object collaboration mechanism is a very large topic, potentially containing a lot of different patterns, Apache Avalon, Pico Container and Spring etc.. actually are concerned mainly with some more common use cases: one is (1) configuration between managed object and configuration model, and the other is (2) collaboration between business service provider and enabling system service providers.

It will be interesting to properly classify all the collaboration patterns in object-oriented programming. The popular term “design pattern” can be regarded as a collaboration pattern identification effort from the system point of view.

In the configuration case, there are three participants in the pictures: the managed object, the configuration model, and the context. Looking from this perspective, what is in this IoC movement is still the classical pursuit in software architecture: loosely coupling and reusability. It is a separation of managed objects and configuration model. The context (the XML file defining reference relationship of beans in Spring) glues them together. In Spring framework, the context is statically defined and very simple, only includes instance by instance relationship in one JVM between managed object and configuration model. In reality, the context definition mechanism can be very complicated. The context may need to be defined dynamically, and we may also have to consider relationships (1) across JVMs; (2) across class-loaders. For example, the same managed object defined by the class file, when loaded by different class-loader, may need different instances of the same configuration model.

A second example is in integration. Suppose we have a connection object. If we want to add a new system, the configuration of the new connection instance is different from the old one, therefore a new instance of the configuration model is needed.

To make the dynamic context definition possible, a controlling interface and a persistence mechanism for context definition is required. The way those are achieved in the OAM framework I discussed in (1) of this series is as follows: a fourth entity is introduced to manage the configuration model. This fourth one is MBean. Associated with the introduction of mbean, there comes the requirement of synchronization among managed object, configuration model and the mbean. It is achieved through a event notification mechanism.

As a side note, IoC is not really inversion. In the old case, the managed object eagerly looks for the configuration model; in the new case, it is not that the configuration model will look for the managed object. The light-weighted container is acting as a broker, and the governing rule is the defined context.

Looking for Future...

I am looking for a new job …

After two years of devotion and hard working, with all the innovations and successes from me and from my team, the company I worked up to today did not prevail at the end, and is essentially closing its operations today.

All the possibilities are open now. And this time things should be different.

The Trend of Software Industry

There are several fundamental changes in software industry in recent years:

(1) Major software providers are gradually shifting focus from selling license to selling services, and are securing more revenue from services than from licenses.
(2) High end server and storage providers are going back to IBM System/360 model of technical business, that is, selling hardware with software as value-added.
(3) Software as utilities such as the model of salesforce.com and others.
(4) The so-called professional open source model exemplified by JBoss, Linux and MySQL etc..

Those changes will properly indicate the future of software industry. The old model of selling license may not be dominating for a long time; instead, in near future this industry will probably go with the model of service as the major sources of revenue. Associated with this may be the disappearance of differentiation between technical consulting firms and software providers.

The value proposition of software from the end users’ point of view is that software solves problems or boost productivity. The assumption behind this proposition is that the end users are able to use software to create value. The evidence is that this assumption may not always be valid particularly when infrastructure level software (ERP, SCM, CRM and Integration Backbone etc..) is concerned. The underlying issue here is that in-house development force or a third party in most cases does not have the knowledge or skills to apply the software to their full potentials. Therefore, the task of using software effectively goes back to the original software provider. This value chain is not optimized either from the end users’ point of view or from the software provider’s point of view.

In traditional industries, people buy services from the professionals because the services are what they are really concerned and what they use to estimate the value. There, the norm is that tools of the professionals are not sold in general. Software is a tool, and only the value realized through software is interested to end users; hence, when more and more analysis elucidate the ineffectiveness of the current software industry value chain, this industry will and should fall back to the same model as all the old professional services follow.

The phenomena in software industry we observed in the beginning of this article are the first steps in the direction of back to future.