Before I go into technical details, I want to thank again all speakers at this event. I personally enjoyed it a lot, and learned some new things. My impression was, that also the audience was interested: not only did I get good feedback, but also the fact, that hardly anyone left within more than three ours speaks for itself:
happy audience until the bitter end ;-)Werner Guttmann and Data Binding
The "Java and Persistence" event on Nov. 23 was opened by the first speech, held by Werner Guttmann. Werneris the project leader of the well-known Castor project and talked about general concepts of data-binding. The problem is generally speaking, how to map between different types of data-representation: typically between objects and relational tables or objects and XML. The Castor project has the advantage to do both bindings within one framework. The XML mapping gained significant importance with the rise of Webservices.
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 ...).
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
Jürgen Höller, one of the founders of the Spring Framework, held the second speech giving a brief introduction to Spring, then focussing on the O/R support. Spring is a highly modular framework, that allows to pick out the functionality that is needed for the very project. In the "core" it is an inversion of control (dependency injection) container managing the lifecycle and configuration of objects/components. (Martin Fowler wrote a good introduction into this pattern.) A second import feature of Spring is the support for aspect oriented programming (AOP). Jürgen pointed out, that the AOP functionality is important even if the developer does not define "own" aspects for the application: but consistent transaction handling based on declarative transaction management require this feature withing Spring.
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)
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:
- Hibernate
- JDO
- Oracle Toplink
- iBatis SQL Maps
- JPA
Besides these external frameworks, Spring offers support for "direct" JDBC usage wich can be appropriate in some scenarios. However, it is important to note, that Spring does not abstract these O/R mappers, but allows the developer to use the full functionality plus the API of the selected framework. Spring helps to integrate the O/R mappers into a consistent component configuaration and lifecycle management, transaction management and exception handling.
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.
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
Stefans presentation was rather short, but after all this complexity we had to deal within in the O/R world, the concept of db4o was stunningly easy and straightforward. But also Stefan pointed out, that it is crucial to select the right technology for the right problem. I strongly suggest to follow this up in his slides! I particularly recommend slide 12: Stefan asks two important questions here:
- Who owns the data
- "Will someone break the barrier"
Meaning: is there a need for an application-neutral representation of the data. According to these two questions he suggests to use RDBM systems when:
- 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
He additionally shows on own slide how easy the usage of db4o is within an object-oriented language like Java or .net.
(However, in the discussion Jürgen adds, that he sees the strength of RDBM systems in the very mature support of multi-user access and transactions. This might be still a problem for systems like db4o.)
Finally, Stefan discusses the query functionality of object-oriented databases. He actually sees the future in native queries, where query commands are part of the language (comparable to MS-Linq for C# 3.0).
Conclusion
I have drawn several conlcusions from this event. First, I was (again) impressed by the concepts of the Spring Framework. Moreover, I found myself confirmed by the observation, that Hibernate & Co bring a significant level of complexity into a project (it is good to realise, that it is not sheer stupidity on my side). So the application of frameworks like Hibernate can be a very good decision, but a decision that has to be taken carefully. In any case very good knowledge of the underlying O/R framework is required for a successful project, as Jürgen stresses.
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).
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!
