Griffon+Remote GORM+X: Inspirations for the Best RIA Horse!

Today I explain a possibility of a pure Java-based client/server application (the client side should be a Rich Internet Application) with a database backend.

I know that other people might already had this idea and others implemented this in a different way and Griffon is on the way, but let my explain it now in (more) detail. It is only an aggregation of existing tools.

How should it look like?

We simply replace the HTML-view of an ordinary Grails application with Griffon! So instead of a browser we will have the mature JVM and we could programm all in Java/Groovy! No JavaScript, no HTML, no CSS, no …!

(Ups. No CSS? Okay we could use css on the desktop, too)

Shouldn’t this be an easy task to replace the V in an MVC application? The problem lays in the detail. E.g. do we need the full GORM functionality on the client side (‘remote GORM’)?

The cayenne framework (a nice hibernate alternative) supports the so called remote object persistence which would be great for this kind of application. They use the hessian library to communicate over HTTP from the client ‘over’ the server to the database. So, the db-programming-style on the client is nearly identical to that on the server!

So, do we need Person.findByXY and all the other, useful methods on the client? I fear tweaking hibernate is necessary but maybe with some grooviness we could avoid this!?

Another simpler approach would be to use the already available services of Grails for the client side. With Xml (Un-)Marshalling or SOAP like it was done before? But hmmh, I prefer the cayenne way … its groovier!

So, what do we need for our 3 tier pure Groovy solution?

We’ll need Grails!

To be a bit more specific: we would actually only need the GORM plugin (and Spring) from the Grails project for the server to communicate to the DB and manage the migrations.

We’ll need Griffon!

We need the full Griffon stack for the client. And if we only use GORM from Grails we will use Griffon also on the server side, I guess.

So either GORM+Griffon+Griffon (db+server+client), which would be more consistent

or GORM+Grails+Griffon which could be easier to implement at the moment.

We’ll need Spring Rich Client!

We need some nice to have packages from the Spring Rich Client project for the client side: validation, window-docking, master-details stuff, …

We’ll need the Hessian Library!

Additionally to the GORM plugin we will need the Hessian library to easily (!) communicate between the client and server. (Short explanation: Hessian library is RMI without drawbacks.) Later on we could implement a remote GORM with the help of this library (see above)! Without this functionality we won’t have fun: either we can only implement a two tier applications (client+db) or the programming is as slow as it would be with an ordinary non-groovy desktop application (via SOAP etc).

We’ll need JavaFX!

Why do we need JavaFX if we already have Groovy as the UI DSL? Marketing! That would mean a broader audience and maybe some tiny  support of Sun ;-)

Another feature of JavaFX would be that designers could create good looking SwingUIs for us without knowing Java/Groovy.

XML Marshalling

3 thoughts on “Griffon+Remote GORM+X: Inspirations for the Best RIA Horse!

  1. Both Grails and Griffon have a hessian plugin already, that’s a start.
    I see the following challenges on the road to a remote GORM solution:
    1. all dynamic methods must be replace by remote ones
    2. transactions must work flawlessly
    3. fetching of collection data
    4. local cache of “lookup tables” to avoid hitting the network so often
    there are more of course.

  2. Thanks Andres! (Did you catch the twitter question or found it via rss?)

    I wasn’t aware of those plugins. For all the others: the necessary procedure is described here: http://griffon.codehaus.org/Hessian+Plugin

    > all dynamic methods must be replace by remote ones

    yeah or roll your own not so generalizable communication … for a quick shot a

    Object DomainClass.remoteEval(String)

    could help here ;-)

    > fetching of collection data

    yes, with hibernate I often got LazyInitializationException’s

    All in all as I said: one will end up to tweak hibernate if it should work properly :-(

  3. Pingback: CRUD with Wicket + Guice + Db4o / NeoDatis « Find Time for the Karussell

Comments are closed.