Jease released - Java with Ease

It took its time, but finally I've done it... I've released Jease - a Content-Management-Framework built on top of db4o as persistence engine and ZK as web-interface.

Jease is an open-source framework to ease the widespread pains developing content- & database-driven web-applications with Java.

Out of the box Jease provides a fully Ajax-driven Content-Management-System as a best-practice-showcase which can easily be tailored to your specific requirements.

Check it out at: http://www.jease.org/

In-Memory Databases...

I've just read an announcement about "solidDB - an In-memory, relational database software for extreme speed"...

http://www-01.ibm.com/software/data/soliddb/

"As relational in-memory database software, solidDB performs up to ten times faster than conventional databases. Whether deployed as a cache for IBM DB2™ or IDS™, or standalone as the database of record, solidDB delivers performance-critical data with extreme speed."

Put a relational in-memory database as cache in front of another relational database to speed up your architecture? What a brilliant idea...;-)

Makes sence, because memory is so much faster than any harddisk... and holding all the semantic and structural business-data (I'm not talking about binary data like images or videos) in-memory of a standard server equipped with several tons of memory is absolutely no problem for the average business of today, because the real world (which our semantic and structural business-data reflects in some way or other) doesn't grow as fast as the memory-technology... most of the time it doesn't grow at all.

But the big problem with the idea of soldDB is simply "the relational database in front of another relational database". Still to much indirection exposed by your database if you're going to work with objects in your application anyway...

I'm running db4o as in-memory object-database for several years now to maintain mission critical data... and I'm a happy programmer with lots of freetime, because programming complex applications got so easy if you're doing things the right way: using db4o as the perfect Prevalayer... more to come, stay tuned...

Choose the right tools...

... and don't try to be smart and use one tool as universal solution for all problems. This won't work as expected...

I'm usually wondering about people who are trying to store lots of lots of lots of lots of simple data items into an object-database like db4o and complaining about performance afterwards.

Hello?

Simple data? Even displayable in a single table? Did you hear of RDBMS lately? Nothing will beat an RDBMS in this discipline because over 30 years of investigation were spent into this technology. Just use an RDBMS and you're fine.

db4o is an OBJECT database... sure, you can define a primitve class with 3 string values and one integer and declare it as object... but that's not the point about db4o. An OBJECT database is best suited for storing and querying an rich object model with lots of interrelations between the objects, so you can navigate your whole object graph easily along the defined paths. And as soon as you start to try to model this into a RDBMS, you'll wandering the JOIN-LOTS-OF-LOTS-OF-TABLES-HELL.

So there is a simple rule of thumb:

If you have lots of lots of simple data, use an RDBMS... but if you have a complex object model with lots of lots of complex relations between your objects, go with an object database.

Cayenne is hot (as hot as a ORM can be)

Today I had a look into another Object-Relational-Mapper: Apache Cayenne

I must admit that it is a very nice product... if you're walking on the relational roads. Cayenne is a little bit different than Hibernate, because you're designing the database schema first and map classes afterwards. All can be done with a little GUI-tool which simply does the job.

Cayenne uses a DataContext which is usually session-bound (whatever a session maybe, think of a web-session) and uses some caches to improve performance.

But as usual with ORM: If you're building lots of relations (every additional cross-table makes you think: who shall understand & maintain this mess in the future?) and query a whole graph of complex objects (e.g. for in memory processing), you're running into the object-relational impedance mismatch... build a prefech query via lots of inner and outer joins or run into the n+1-select-problem. Both solutions suck...

But Cayenne has a very nice concept to solve the typical caching issue. All DataContexts are registered at a controller and are synchronized automagically. So if someone is going to change an object in DataContext A, DataContext B and C and D and so on will be notified of the changed object. This solves the typical refreshing-always-kills-the-cache-problem very nicely.

I'll see if I can come up with something similar for db4o.

db4o.eases(persistence)

Today I've played once again with my favorite Object-Relational-Mapper... Hibernate. Maybe there's still something I could learn from Hibernate... maybe not. At least it helps a lot to understand people who are using Hibernate and want to switch to db4o.

So I grabbed my copy of "Java Persistence with Hibernate" (this book is worth reading it if you're interested in persistence technologies), installed Oracle Express besides MySQL on my laptop and started to work...

At the end of day I've learned this lesson: Viewing from a OO-perspective Hibernate "stores" objects just as db4o does. Both store just "data", not the methods of an object (here came the Zope Object Database (ZODB) to my mind which stores data and methods together). Hibernate uses a relational database as backend whereas db4o uses its own optimized file-format.

But when Hibernate "stores" objects as db4o does, what is the reason to stick with db4o? Hibernate and RDBMS-technology is so mature compared to the newcomer db4o...

The answer is simple:

- If you have lots of spare time in your life which do you want to convert into working hours until midnight, go ahead with Hibernate and RDBMS.

- If you're interested to get the job done in a fraction of time and ride your cyclocross-bike in the afternoon: use db4o.

db4o is the ease of persistence for the programmer. db4o helps you NOT to think about persistence. db4o just works as you're expecting it. And that is what makes db4o different: It helps you to get things done in less time with less trouble. And because db4o is so simple to use it helps you to keep control over your work. Fewer lines of code, less complexity to manage.

db4o.eases(persistence)

Templating with Jamon - another piece of the puzzle...

Something I really enjoy about db4o is the promise of statically type-checked code, because I don't want to worry about "refactorings" which get broken due to references of code in strings or strings referencing code.... a typical problem for SQL statements flying around in lots of XML-Mappings (or even more worse: Java code which builds SQL dynamically at runtime).

For the development of web-applications I'm using Echo2, which is a Java-only web-application- framework modeled after Swing. No need to write lots of ugly HTML, CSS, Javascript etc.pp. Just Java and statically type-checked code. What a fun to be a web-application-developer...

But I didn't solve the problem of statically type-checked (and therefore refactorable) templates (e.g. for reports or emails)... until I found Jamon. Jamon is a templating language which gets compiled into statically type-checked non-reflective Java code.

Just a little example:


<%args>
Person person;
ShoppingCart items;
</%args>

Hello <% person.getFullName() %>.

We're glad to send you the following books for a special prize:

<%for Item item : items %>
<% item.getName() %> - <% item.getPrize() %>
</%for>


Save this file as ShoppingMailTemplate.jamon and it gets automatically compiled into a Java-class (via a Eclipse-plugin, Anttask is also possible). Now you can use ShoppingMailTemplate-class like this:

String result = new ShoppingMailTemplate().makeRenderer(yourCustomer, customerShoppingCart).asString()

That's so simple... and now you're safe to refactor your classes without breaking the templates.

Jamon is a really wonderful piece of software for people who love statically type-checked Java...:)

Kiss Groovy...

I'm a big fan of solutions which try to keep technology simple as possible. So it is no wonder that I'm in love with db4o: No SQL, no XML, no ORM, just me and Java and Persistence which simply works. That's a deal.

Another big simplification for me (mostly developing intranet web-applications) is using the wonderful component & event-based Echo2-Ajax-framework as presentation tier. No HTML, no CSS, no JavaScript, just me and Java and a rich & responsive GUI which simply works across browsers. That's a deal too.

But the mess creeps slowly into your stack of libraries...

I've used...

• Velocity as simple templating framework for plain-text reports and mails (loaded from a db4o-database);
• JSPs for simple HTML-based reports (loaded from file-system);
• BeanShell as script-language for evaluating dynamic business rules stored in a database (db4o of course) and as ad-hoc query-processor for db4o.

Too many different technologies with a similar focus with different pros and cons... any chance to clean up the mess?

I recently started to (re-)evaluate Groovy and come to the conclusion: Groovy solves all my templating, runtime-scripting and ad-hoc-query problems with one integrated, well-balanced and very flexible technology. So I only need to know my Groovy to create complex but clean templates (text or html or whatever), dynamic evaluations of code-snippets and ad-hoc queries against my db4o-databases (and the Groovy-Syntax make these queries looking real cool).

Groovy is just another cool KISS-technology besides db4o & Echo2. It's always nice to see when things become simpler... and to learn something new...:)