[Java] Introduction to Wicket

Wicket is a young component based web framework under Apache License, currently available in version 1.3. I've found a good introduction article hosted on TheServerSide , discussing the fundamental concepts behind the framework.

Wicket focus on Seperation-Of-Concern by providing the developer a rich component based model to develop components, which are associated with HTML pages. The logic of the components are written in Java, using the full power of the Java language and the IDE. The design of the pages and components are done by the web designer using powerful HTML design tools. Therefore you have a clean separation between presentation layer (HTML/CSS) and application layer (Java).

The first part of this article gives you a detailed overview about Models in wicket, which are used to associate your web componentes with your domain objects. Then he walks through a small Wicket example and explains the basic architecture about a Wicket applications, including WebApplication, WebPage and how components are associated with HTML pages. The example provides a solid basis to understand the basics of Wicket.

[Java] SpringSource acquires Covalent Technologies

SpringSource the company behind the popular Spring framework announces their acqusition of Covelant Technologies, providing service and support for apache products. Spring and Tomcat are the most used technologies in middleware. Read more about the acqusition in Rod Johnson blog.

[Arch] Consistency Rethought

So easy was it some years ago, when we had a database server and some telnet clients or forms-application that interacted with the database. ACID was the way to go (consistency, transaction-wise). See for example Jim Grays paper from 1981. Now we go Internet, distributed. And it became clear, that this would change the reception of consistency. In a recent article in his blog "All things distributed", Werner Vogels, the CTO from Amazon.com discusses these issues in detail: Eventually Consistent. A must read, I believe.

He quotes also Eric Brewer with his CAP theorem:

"Eric presented the CAP theorem, which states that of three properties of shared-data systems; data consistency, system availability and tolerance to network partition one can only achieve two at any given time."

And in modern distributed (web) applications it seems to become clear, that e.g. system availability is something you do not want to sacrifice. It might be irrelevant for my personal webpage, if there is a downtime of some hours, but when you operate a webshop, social website, webmail and the like, this seriously damages the trust in your service. Not to mention the financial loss, when people cannot set orders for that given down-time. The consequence? Read Werner Vogels article and get Eric Brewers keynote!

Btw.: during VLDB 2007 we had the opportunity to interview Werver Vogels and Eric Brewer to very similar topics. Check out the blog article (Interview with Vogels, Interview with Brewer, and get the audio!

[Misc] Design or Platform skills?

Martin Fowler writes in his last blog article:

"Imagine a hiring situation. There's two candidates both with a few years of experience. In the blue corner we have someone with good broad design skills in the style of design that you favor [...]. However she knows nothing of the particular platform technology that you're using. In the red corner we have someone who has little knowledge (or interest) in those issues, but knows your platform really well - edge cases in the language, what libraries are available, fingers move naturally over the tools. Assume all else about them is equal (which it never is except for thought experiments like this) and that your team doesn't have any gaping holes that this candidate might fill. Which one would you prefer?"

In the following discussion he analyses why he would prefer the person with the design skills, but read it for yourself!

I mean, he is discussing the topic quite balanced, still I have the feeling that he underestimates the importance of platform skills. My impression is, that in the last (10) years platform knowledge became significantly more important (as the "big" platforms, e.g. Java, .net grow in terms of tools and features). Actually, writing a non-trivial application in, say Java, demands a very good knowledge about available libraries, the "best-practice" tool chain (build automation, testing), component frameworks, server frameworks, configuration management, testing frameworks, JVM issues, and so on. There are so many odds and ends you better know for not wasting unnecessary time or going into a unproductive direction.

Plus, I would wonder how a person that has really deep knowledge about the specific platform and tools (as I mentioned it above) could be unskilled in design issues anyway. Just be dealing on an intimate level with modern frameworks like Spring, Guice, Eclipse RCP, Maven, GWT and other open source projects you get an idea about how to design applications properly!

Plus I find it easier to get a new team member on speed that is very good at the platform details but has some lack of knowledge in patterns and design then vice versa. Why? Because in the starting phase this person would rather implement "details" that are designed by more experienced staff or work close with experienced staff. However, I know that this new person does not make platform-rookie mistakes in the implementation process that turn out to be "time-bombs" in the later phase of the project. Getting a broader "design-oriented" view is only a matter of time for a bright person.

Am I naive here?

[Java] Generic Data Access Objects with Java Generics

The Data Access Object (DAO) pattern is an essential design pattern in enterprise applications. In a DAO all data access to the underlying data source is encapsulated by providing a generic interface. Service components use the DAO in order to load and save data to the data source.

A DAO interface usually provides common CRUD (Create, Read, Update, Delete) operations. The implementation of such DAOs can become a painful and boring work, because almost the same code is written for every DAO. Consider an application with hundreds of domain objects, where each object must provide a DAO!

In my post “Has JPA killed the DAO” I summarize the necessity of the DAO based on the discussion from Adam Bien. In this post I mentioned that JPA provides a generic data access functionality. In the present post I will show how to write a Generic DAO interface by using Java 5 Generics, Hibernate and Spring.

Java 5 Generics allows to parametrize and to create typesafe DAO interfaces. So it makes sense to adapt generics to implement a generic DAO. The following code snipped provides such a DAO interface

public interface GenericDao {

 public T saveOrUpdate(T entity);

 public void delete(T entity);

 public T findById(ID id, boolean lock);

 public List findAll();

 public List findByExample(T exampleInstance);
}

The interface definition gets two parameters: T for the type of the domain object and the ID for the type of primary key. These parameters are then used in the interface methods. There are no specific domain objects but still typesafe by using Generics. Now we have an implementation with Hibernate and Spring. In this case we use HibernateDaoSupport from Spring:

public class HibernateGenericDao extends HibernateDaoSupport implements GenericDao {
 private Class type;

 public HibernateGenericDao(Class type){
     this.type = type;
 }

 @Override
 public T saveOrUpdate(T entity) {
     getHibernateTemplate().saveOrUpdate(entity);
     return entity;
 }

 @Override
 public void delete(T entity) {
     getHibernateTemplate().delete(entity);
 }

 @Override
 public List findAll() {
     return getHibernateTemplate().loadAll(type);
 }

 @Override
 public List findByExample(T exampleInstance) {
     return getHibernateTemplate().findByExample(exampleInstance);
 }

 @Override
 public T findById(ID id, boolean lock) {
     return (T)getHibernateTemplate().load(type.getClass(), id);
 }
}

Also the implementation needs no specific domain objects, we still work with Generics. The type attribute in the class is important. It specifies the type of the domain object for which the DAO should work and is further injected by Spring when using Dependency injection:

Instead of using two separate DAO implementation we only have one generic DAO and instantiate the DAO for the business object. The constructor gets the type of the domain object. That makes sense, wow.

If you need domain specific DAO operations extend the Generic DAO!!

Hope this blog impresses you to take a look to Java 5 Generics and Generic DAOs.

[Event] Berlin / March: Object Database Conference

Let me wish you a happy new year and welcome this year with a little announcement:

On 13+14th March there will be an Object Database Conference in Berlin.

Some facts, before I explain why this is important for Software-Engineering and not only for the Database / Persistence area.

A) The conference is split into a Science Day (13th March / Thursday) and an Application Day (14th March / Friday). There will be peer reviewed talks and papers on 13th and many practical talks on Friday.

B) The conference already has joined up an impressive line of (keynote) speakers. To name a few: Christof Wittig (db4objects), Robert Greene (Versant), Leon Gudzenda Objectivity), Mike Card (OMG), Roberto Zicari (odbms.org), Carsten Czarski (Oracle), Rald Westphal (.NET Expert), Carl Rosenberger (db4objects Chief Architect), ...

C) There will be a lot of hot topics as Standardization (OMG), Spring, Eclipse, Android, and more. All connected to object databases.

D) Talks and Papers are still welcome. Please tell your colleagues about the conference link http://icoodb.org

E) And finally Berlin is always worth a trip, the conference itself does not have the normal exaggerated prices and hence is quite affordable.

So you might think: Well I am in love with MySQL / Hibernate and I have understood the relational data model. That's pretty perfect and you might have a wonderful solution at hand that suites pretty well in most cases.

But as an advanced Software-Engineer you should consider the following:

1. You should know the entire persistence space. Are XML Databases as Tamino, eXist, or Xinidce important? Yes they are! Are Object Databases important to fit perfectly in specific areas? Believe me: they are, they do. The conference will help to clarify this and lets you play the entire persistence keyboard.
2. Did you know that some of the largest and fastest databases are run on ODBMS (Obejct Database Management Systems)? Did you know that on the other hand embedded object databases can be found everywhere? And did you know there is a smarter and mostly faster database on Google Android then SQLite?
3. And for the Software-Engineers reading this:
   

Even if you are plan to run a monster big and relational database you can benefit from Object Databases (ODBMS):

a) Add a simple Object Cache to your application using ODBMS. It's really trivial.

b) Are you building a prototype first where the persistence layer comes later? Simply add a DAO Layer that saves ANY object (even the deepest) with only 2 lines of code any nothing more to do! Later when your relational persistence comes, you can easily switch to the EJB 3 / JPA / Hibernate Layer if needed. But till then your persistence layer simply works even simpler then with these 'cool' class annotations.

c) You need to test your Business Code? You use Mock-Objects generated by jMock, asyMock or *Mock? You sometimes want to write a mock without the database connection? Use an object databases plugged in your mock to provide your mock with arbitrary domain objects to test with.

To conclude: We hope that these examples gave you lots of arguments to join the ICOODB.org conference, spread the word about ICOODB.org or get in touch with us.

Any questions? Please write a comment here or get in touch with us:
info[at]icoodb[dot]org

And perhaps CU in Berlin!