Over a million developers have joined DZone.

Griffon + Remote GORM + X: Inspirations for the Best RIA Stack

DZone's Guide to

Griffon + Remote GORM + X: Inspirations for the Best RIA Stack

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

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.

From http://karussell.wordpress.com

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}