Wednesday Aug 24, 2011
Tuesday Aug 23, 2011
Friday Aug 05, 2011
Axon 1.1 resolves issues with HSQLDB 2.0
In this post we mentioned that the Axon framework didn't like HSQLDB version 2.0. However, after migration to version 1.1 of the framework, the problems mentioned in the previous post were no longer observed! Now we can finally expect more sensible error messages from HSQLDB.
Wednesday Apr 13, 2011
CQRS and command validation
During the implementation of our CQRS-based application, we initially had discussions where the validation of the commands needs to reside (client side versus command objects) and the precise distinction between validation and business rules. Today I found an excellent post, titled Clarified CQRS, that very concisely and very accurately addresses these issues and more. A lengthy, but very worthwhile post, with over 100 comments already. I surely recommend anybody interested in CQRS to check this post out.
Concluding: applying the CQRS pattern forced us to think over these concepts thoroughly from the start, which is now reflected in an even more robust and maintainable application.
Wednesday Mar 16, 2011
Axon framework sample applications
Today I found a site with some sample web applications that are based on the Axon framework. If you need to get acquainted, this is the place to be!
Friday Oct 22, 2010
Today I found an excellent post on CQRS (Command Query Responsibility Segregation) by Rick van der Arend. A Dutch version is available too: CQRS & de bijkomende architectuur. This post not only introduces the principles of CQRS, but motivates them too, e.g. it is argued that the introduction of event sourcing offers a solution to keep your domain model clean of getters and setters and makes it possible to restore state without performance problems. This is exactly what we found out implementing our current application for booking office rooms (we first tried to go without event sourcing)!
The pictures that are used in the post are also very instructive:
From CQRS & the architecture coming along by Rick van der Arend.
Thursday Sep 23, 2010
Instructive domain-driven design application
Today a colleague pointed me to a link referencing a sample DDD application. This application is authored by DDD gurus such as Eric Evans and Greg Young. We think their code is very inspiring!
Monday Jun 02, 2008
Howto avoid generation of getters and setters (and why)
The generation of getter and setter methods using an IDE has never felt right to me. Recently I stumbled upon two excellent blog posts on domain-driven design that made these feelings explicit and clear. In fact, I think that everyone should (re)read these posts everytime they are about to activate the "generate getters and setters" feature in their IDE. So let's start reading these posts right now: http://sbtourist.blogspot.com/2006/07/avoid-your-getters-and-setters-part-1.html and http://sbtourist.blogspot.com/2007/10/avoid-your-getters-and-setters-part-2.html.
Wednesday Dec 05, 2007
Relation between domain model, service layer and lazy loading
As stated in my previous post on model driven engineering, the key incentive for using domain driven design is to "reduce maintenance and development by working on the model instead of the code level". This way it becomes much easier to link your code directly to its accompanying functional specifications! A good domain model should at least be "rich" in the sense that:
Wednesday Jul 04, 2007
WebSphere Portal and the OSiV pattern
This post describes some peculiarities when working with the Hibernate 3.x and Spring 2.x frameworks in a WebSphere portal 5.1 environment and in particular the realization of the OSiV (Open Session in View) pattern in this environment. A solution is proposed for both IBM API type portlets as well as JSR-168 type portlets.
In many web-applications, data that is persisted in the EIS (Enterprise Information System) layer is mapped onto domain objects (c.f. the previous post on domain-driven design). These domain objects "live" in an object oriented world, whereas the character of the EIS layer is inherently relational. This is better known as the object relational impedance mismatch. Consequently, there usually isn't a one-to-one correspondence between tables in the database and the object model implemented in Java. In the remainder of this post, such a one-to-one correspondence will be referred to as a trivial mapping.
It is especially in this area of (non-trivial) mappings, where the Hibernate framework really shines. One may transparently "walk around the object graph", without taking precautions on uninitialized associations (child relations). This is primarily established by Hibernate's "lazy loading" mechanism. However, a proper understanding is essential for this mechanism to work and behave as expected, in particular a proper handling of the Hibernate session management within a web-application context, as lazy loading only works within one and the same Hibernate session, which basically boils down to a transactional cache for persistent objects. This holds even more for Hibernate versions 3 and higher, as it boasts a more "lazy behaviour" by default than its predecessors.
Summarizing, Hibernate session management is both an essential and non-trivial issue to be dealt with, in particular in case of web applications. Luckily, this is precisely where the Spring framework really shines. It solves most of the Hibernate session management related issues in an almost transparent way, meanwhile offering a loose coupling of your (web) application layers, by externalizing all object dependencies via dependency injection.
Hibernate, Spring, session management and portal
As was mentioned in the above introduction, most of Hibernate related "side effects" have already been dealt with by the people that developed the Spring framework, hence it is logical to incorporate the available standard solutions offered by their framework.
In web-applications, lazy loading is essential, since certain associations might not have been loaded until the JSP has completed its rendering of all properties that need to be displayed. As stated before, this requires the Hibernate session to be open as long as properties may be retrieved; hence it is necessary to keep a session open over the full request/response cycle. Although this could in principle also be achieved by including the view in a transaction, it is much cleaner (i.e. much less resource consuming) to employ the former solution, the so-called Open Session in View (OSiV) pattern.
Open Session in View
Keeping the session open for the complete request/response cycle is generally known as the Open Session in View pattern. It is most naturally implemented using servlet filters (available since servlet 2.3), and is all that is needed when doing read-only operations. Spring offers a readily available OSiV filter, where one merely has to configure the filter and its associated URL matching pattern in the
Objects that are thus loaded and are kept in an (HTTP) session, are said to be detached while being edited. When such detached objects need to be saved, it is necessary to re-attach these objects to the new session. This is what the Hibernate "save" and "saveOrUpdate" methods accomplish. In practice, this is intuitively done by programmers. Associations are automatically taken care of, as long as the "cascade" property in the mapping files is set accordingly (e.g. "save-update" for cascading on save and update operations).
Since Spring's OSiV filter implicitly configures the Hibernate session to be
Open Session in View and portlets
When working with portlets, Spring's OSiV filter cannot be configured in the standard way, since WebSphere portlets have their own (proprietary) way of configuring filters: serlvet filter definitions in the
This requires the Spring framework JARs to be available to the parent (i.e. portal wide) class loder of the portlets that are actually using Spring and its OSiV filter. Since many portlets are using Struts too (Spring boasts a very nice means to integrate with Struts), this requires the Struts libraries to be available to the parent class loader too. This in turn causes an avalanche of related class loader problems that basically renders this approach useless. More detailed explanation: class loaders cannot "descend" in the class loader hierarchy, hence Struts classes in the web application's
So what can we do to fix the OSiV pattern for WebSphere 5.1 Struts portlets?