Werner Guttmann and Data Binding
Werner additionally emphasised the importance of separation of concerns. Simply spoken: things that do not belong together should be kept separate. This idea was also supported by the other speakers and brought up an interesting discussion in the end: current trends in Java development practices (e.g., in EJB 3 or Hibernate annotations) suggest to enrich objects with all sorts of metadata. The discussion unfolded the problematic behind this approach, particularly as certain types of metadate apparently break the separation of concerns. E.g., when in an object concrete mapping information (database table name, field names, and the like) is kept in annotations.
On the one hand, this type of annotation clearly supports build-automation in the sense, that from one source file all other artifacts (XML mapping information and database metadata) can be generated (and makes it easier to keep these issues in sync). On the other hand, this mixing up of concerns can reduce the reusability of e.g., the object that is annotated.
Werner additionally suggested, that keeping concerns separated is a very important first step to go towards model driven architectures (MDA). Whereas he is still somewhat sceptical about the applicability of MDA, he also described clear advantages of these approaches (in terms of maintainability, reduced need to manually write repetitive code ...).
Jürgen Höller - Spring ORM
However, the main focus of the presentation was on the support of various O/R mapping frameworks within Spring. Here it also got very clear, that Spring can be seen as the glue between various frameworks but does clearly know its limits: Spring does not provide "own" O/R functionality and is not planning to do so, but relies on proven technology and allows the developer to choose the best fitting one. This can be observed in several fields (e.g., remoting, view technologies)
Spring supports the following O/R mapping frameworks in a consistent manner:
- Oracle Toplink
- iBatis SQL Maps
Speaking of which, exceptions are an interesting part of the integration story, that many developers might not be aware of: Jürgen stresses the fact, that declared exceptions are part of the object/contract! What does this mean:
Consider a data access object that implements the according DAO interface and connects e.g., to Hibernate. Now: within the data access operations in this DAO implementations exceptions can occur: in the case of a direct use of Hibernate, the exception would be a Hibernate exception. This is ok, as long as the exception can be handled within the DAO. But it is problematic, when the exception has to be escalated to the business logic. This would mean, that the DAO interface would have to declare Hibernate exceptions, thus would be too close coupled to this framework.Spring on the other hand, offers (among others) a consistent exception definition that is not bound to a specific framework.
Jürgen eventually iterates through the supported frameworks and summarises the "history" of O/R mapping and gives some insight into the future development. He sees Hibernate currently beeing the by far most used technology. However Hibernate (Castor, Toplink...) brings a significant piece of complexity into a project, and it might be appropriate to consider alternatives like iBatis in certain project types. Jürgen also discusses the development of the JDO and JPA standard. He actually sees in JPA the successor of JDO; there is actually a new version of the JDO standard (and Spring supports these), however, Jürgen argues that it comes too late and lacks support in industry and open source community.
Yet it is mentioned, that the JPA standard is of considerable complexity. Currently fully featured, it is only supported by the Glassfish application server. Further implementations are on the way. But due to the complexity of the standard it will not be implemented widespread.
Stefan Edlich - db4o
- Who owns the data
- "Will someone break the barrier"
- Data needs to be stored in a neutral way, different views are required
- OLAP is applied
- Clustering is necessary
- additional DB features required
- No mapping is needed (no neutreal representation is required)
- Higher performance
- Deeper object graphs can be stored easily
- Scheme changes are supported
- no administration of the DB required
As a side note: I for myself was supported that sticking to iBatis can be a good decision for many problems.
Finally, Stefan brought in a very important message in emphazising that there is a broad variety of persistence technologies out there, starting from "monsters" like DB2 and Oracle, over systems like Derby to object databases like db4o and even exotic solutions like prevayler. The concrete decision for a technology should be done early in the project, but not as a dogma without good arguments (as Jürgen pointed out).
Downloads and Comments
The collected presentations are prepared for download:
I want to add the obvious: this report is my subjective understanding of this event. Please contribute with your own ideas and observation by writing comments! This is highly appreciated!