One of the things that worry me when sharing a domain model and of course the same database between two applications is how the 2nd level hibernate cache could mess things up.

One application could have a different view of the data than another app.

Did you think about this issue?

Emmett :

While Ill be using the spring security plugin for security in the web app i’m not sure what the best way would be to manage authentication and authorization to consumers (i.e. a native iphone/android apps) of the restful services exposed by the 2nd web app

You can still use spring security with basic auth for services and standard web form login for webapp:
http://burtbeckwith.github.com/grails-spring-security-core/docs/manual/guide/9%20Authentication.html

Thanks

Also one more question, if I may..
While Ill be using the spring security plugin for security in the web app i’m not sure what the best way would be to manage authentication and authorization to consumers (i.e. a native iphone/android apps) of the restful services exposed by the 2nd web app

thanks again
Emmett

It sounds like for your particular environment, using a Grails plugin to contain your DBO abstraction won’t work out well.

This article is targeted towards those who are using a 100% Grails stack and want to reuse their domain classes in two or more applications.

Since some of the applications which you want to share the same data model are in frameworks besides Grails, you’ll have to take another approach.

Without knowing a lot about your application, I’d suggest that you bundle all of the DBO abstraction into a shared java library. The underlying technology would have to be something like Hibernate or straight JDBC to be most compatible.

You could (as you noted) also expose your data model via a much richer webservice for other clients. Though, I would advise against this if you need a great deal of access and control over the data model.

Were I faced with the same scenario, I would probably setup a separate grails application which exposes your domain classes via a SOAP or REST/JSON web service, and leave the main grails application unchanged in the way it accesses your domain classes.

The underlying reason for writing this article was how to use the same Grails domain classes (including all of the GORM and meta programming magic) in more than one Grails application. Basically making your DBO abstraction portable so that many different systems can access the data model in a shared, and predictable manner.

If your main application, which consumes the domain classes in your plugin, uses GORM directly on the domain classes, you’d have to do a lot of refactoring to abstract that behavior into services.

By launching a totally separate app which exposes your domain model via a webservice, you also have the choice to limit that service to only the data access which would be necessary for remote clients. For instance, your main application may need to do a complex query across many domain objects, and have write access to everything, where a remote client may only need to have read access to a few domain objects.

You can even make the webservice appear to be part of your main application by putting it in an appropriate application context in Tomcat which I talk about in this post. I.E. http://www.yourmainapp.com/api/

If you’re strict about version control you can make sure that the main application, and the webservice layer are both consuming the same version of the domain classes plugin, and it’ll work seamlessly!