Griffon + Remote GORM + X: Inspirations for the Best RIA Stack
Join the DZone community and get the full member experience.Join For Free
today i explain a possibility of a pure java-based client/server application (the client side should be a r ich i nternet a pplication) 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?
(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!
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.
Opinions expressed by DZone contributors are their own.