InfoQ

News

InfoQ Article: Grails + EJB Domain Models Step-by-Step

Posted by Floyd Marinescu on Aug 22, 2006 01:13 PM

Community
Java
Topics
Web Frameworks,
Scripting
Tags
Grails,
Groovy,
Code Generation,
EJB
Grails could bring Ruby on Rails style productivity to the Java platform, built on the Groovy language and fully integrated with Java. In this tutorial, Jason Rudolph shows how to use Grails to quickly build a functional website around an existing EJB 3 entity bean domain model with very little code.  Read Grails + EJB Domain Models Step-by-Step.
As one impressive example of its enterprise integration abilities, Grails let's you quickly and easily build a web application backed by your existing EJB3 entity beans. But, it doesn't stop there. Grails gives your entity beans a hearty shot of steroids, but does so completely dynamically, without altering your EJB source code in any way. Grails Object Relational Mapping (GORM) is built on Hibernate 3 (but will eventually offer support for the Java Persistence API) and uses Groovy's Meta Object Protocol (MOP) to add all sorts of handy dynamic methods to your otherwise-static entity beans. And those methods are not only accessible from Grails and Groovy; your Java code can invoke those methods as well! We suddenly have all the enterprise-level capabilities of JEE/EJB3 and the benefits of RAD web application development!
The integration angle is quite important, as reuse of existing investments in Java is a commonly cited problem the Java community has been saying about using Ruby on Rails.  Grails brings a RAD framework bound together with our own dynamic language (Groovy) which is part of the Java platform.  Integrated stacks RAD stacks with a strong EJB focus is an area of innovation for a number of frameworks wuch as RIFE, Trails, JBoss SEAM (JSF+EJB), but Grails is the only one built around the Groovy dynamic language.  Could Grails become the Java community's answer to Ruby on Rails?

19 comments

Reply

Wow EJB is now legacy? by j c Posted Aug 22, 2006 11:46 PM
no, you missed the point by Floyd Marinescu Posted Aug 23, 2006 2:59 AM
Re: no, you missed the point by j c Posted Aug 24, 2006 11:08 PM
Integration w/ Legacy Apps versus Developing w/ Complimentary Technologies by Jason Rudolph Posted Aug 25, 2006 6:05 AM
Re: Integration w/ Legacy Apps versus Developing w/ Complimentary Technolog by j c Posted Aug 28, 2006 1:07 AM
Re: Integration w/ Legacy Apps versus Developing w/ Complimentary Technolog by Steven Devijver Posted Aug 28, 2006 11:07 AM
Re: Wow EJB is now legacy? by Graeme Rocher Posted Aug 23, 2006 3:11 AM
relationship management by Jeff Payne Posted Aug 31, 2006 4:21 PM
Re: relationship management by Graeme Rocher Posted Sep 1, 2006 3:02 AM
bug in employee list? by ma pel Posted Aug 31, 2006 9:12 PM
Re: bug in employee list? by Jason Rudolph Posted Sep 5, 2006 3:57 PM
Nice, but... by Randall Burt Posted Sep 26, 2006 7:33 PM
Re: Nice, but... by Pat Osterday Posted Nov 14, 2006 3:38 PM
Re: Nice, but... by Piero Sartini Posted Apr 4, 2007 4:36 PM
Article in pdf format? by Fred Janon Posted Nov 30, 2007 8:34 PM
having problems to run app with grails 1.0 RC2 & groovy 1.0 by Michael Brinkmann Posted Dec 7, 2007 6:49 AM
Re: having problems to run app with grails 1.0 RC2 & groovy 1.0 by Michael Brinkmann Posted Dec 7, 2007 8:04 AM
Issue GRAILS-2042 by Venky VB Posted Jan 11, 2008 12:08 AM
Scrollable results? by Siddharth Bala Ravi Posted Jun 5, 2008 11:32 AM
  1. Back to top

    Wow EJB is now legacy?

    Aug 22, 2006 11:46 PM by j c

    A legacy approach to using EJBs. Wow that speaks volumes. And do it with another language. Ouch. Floyd I cant figure if you think Java has a future or if you think we should all party on the VM like it was (a) 1999 (Corba container). This is what frustrates me about the Java space right now. Everyone is so rattled by ruby and scripts and trying to wedge Java in a buzz trend that is so far removed from where Java is that its not even worth discussing Java in a "rails" context. Or discussing rails in an EJB context. If we have to port rails to the JVM to be happy then maybe we should just use the ruby interpreter and support its toolset and let IBM handle the legacy integration as they are so keen to do. Its not interesting or all that relevant.

  2. Back to top

    no, you missed the point

    Aug 23, 2006 2:59 AM by Floyd Marinescu

    I think you missed the point - the article doesn't treat EJB as legacy, it's about developing a domain model in EJB and using Grails to quickly build a web app around it. Considering strategies like Domain Driven Design, focusing on your domain model in Java and generating the UI around that is an emerging best practice that tools like Grails can enable.

  3. Back to top

    Re: Wow EJB is now legacy?

    Aug 23, 2006 3:11 AM by Graeme Rocher

    Where was it mentioned that EJB3 is legacy? Grails is all about embracing Java, the platform, language and tools. Java has a huge future and it speaks volumes for the strength of the platform that Grails and its underlying frameworks (Spring, Hibernate, SiteMesh, Quartz etc.) exist. In terms of porting Rails, well yes that is one option, but Rails (as with Ruby's runtime) has a very different object model and idioms for developing web applications. One that its contradictory to existing knowledge about specifications like Servlets, JSP and, indeed, EJB. Grails is not a port of Rails and in fact is very different in many ways including how it is based on Java frameworks.

  4. Back to top

    Re: no, you missed the point

    Aug 24, 2006 11:08 PM by j c

    "built on the Groovy language" and "fully integrated with Java" "built on the PL/SQL language" and "fully integrated with Java" "built on Javascript language" and "fully integrated with Java" "built on ActiveX" and "fully integrated with Java" "Built on Flash" and "fully integrated with Java" I didnt miss the point. The point was accessing EJBs with something other than Java. And if EJB 3 is a big plus in combination with another language then *something* in this picture just went legacy. And something just went "integration strategy" Thats how you know what legacy is and isnt.

  5. If we were talking about using Grails to build a front-end to a VSAM file, I'd agree with you that we're talking about legacy integration; however, that's not the case. There's a distinct difference between... * Using a current technology to integrate with a pre-existing (legacy) application, versus... * Using a current technology (like Grails) in concert with another complimentary and current technology (like EJB) to build a new application.

    The point was accessing EJBs with something other than Java. And if EJB 3 is a big plus in combination with another language then *something* in this picture just went legacy.
    I respectfully disagree. We've long been dependent on another language to make our Java apps work. That language is XML, and XML does not make Java a legacy language. They're complimentary technologies. If the goal is to build a web user interface for your EJBs (which are, by their very nature, business-tier components), chances are you're going to invoke some other (complimentary) technology for your web tier. Maybe it's just JSP. Maybe it's Struts or Spring MVC or Tapestry or Grails. The use of those complimentary technologies does not make EJB a legacy technology. It's instead a choice of using the most efficient tool for the job at hand. And for many applications, Grails offers the productivity gains to make it a strong contender to be that tool.

  6. OK Ill give you that, but you cant ignore the undercurrent of the Java space right now which is desperately trying to wedge the competition into its model out of fear of outright rejection. What if the smalltalk guys had insisted that Java run in a smalltalk VM? What would people have thought of them? The smalltalk VM was way ahead of Java in the early days. So now the Java scene wants to steal ruby and rails from the cradle and I say well if Java is so great then let Java solve its own problems without coopting the vibe of the scripting languages. I think Java is trying to change before anyone acknowledges or speaks aloud of a greater failure of OO or more specifically Java projects to deliver.

  7. I think Java is trying to change before anyone acknowledges or speaks aloud of a greater failure of OO or more specifically Java projects to deliver.
    I read in a magazine a couple of years ago that "the Hummer is the greatest off-road vehicle we ever drove". And "with a Hummer you can get through any terrain except through narrow streets". Java, Groovy and Ruby are great in many areas but none is great in all areas. Particularly, Java is not so great to write web handlers. Alternatively you could use Ruby and Rails or Grails if you want to reuse Java code. In fact, we've created Grails to augment the Java platform. You can hate us for doing so and being successful. There's however no need to start a flame war.

  8. Back to top

    relationship management

    Aug 31, 2006 4:21 PM by Jeff Payne

    Any reason why the relationaship management code can't be generated too? It was a little anticlimactic to learn that the developer had to manually edit the generated groovy code just to handle the object relationaships. I'm assuming all that info is stored as annotations in the EJBs.

  9. Back to top

    bug in employee list?

    Aug 31, 2006 9:12 PM by ma pel

    Hi, I followed up this step-by-step and successfully run 'grails run-app'. Everything looked great except this case: I assigned 3 computers to an employee, for example, jane and I got 3 instances of the same 'jane' listed in the browser(IE6.0) when I click on employeeBean list link. That seems a bug. How can I fix it? Thanks.

  10. Back to top

    Re: relationship management

    Sep 1, 2006 3:02 AM by Graeme Rocher

    This is one the todo list: http://jira.codehaus.org/browse/GRAILS-172

  11. Back to top

    Re: bug in employee list?

    Sep 5, 2006 3:57 PM by Jason Rudolph

    Good catch. Thanks for your feedback. There's apparently problem with the dynamic list method, which is used to fetch the list of employees. You can track the problem here: http://jira.codehaus.org/browse/GRAILS-284

  12. Back to top

    Nice, but...

    Sep 26, 2006 7:33 PM by Randall Burt

    This is a really great article and does a very nice job of showing off the features of Grails. However, I was sort of hoping for an article about integrating Grails and EJB. As it is, the author just illustrates the flexibility of the new EJB pojo implementation as well as the rapid development capabilities of Grails. What I'd like to see (and I believe is slated for a release later this year) is the ability to map those beans to/from ones already deployed on an existing EJB container instead of simply using Hibernate and copying the pojo implementations into the project. Maybe this is already possible using some tricks with the Spring configuration, but I don't know Spring well enough to say. In any case, thanks for a great article!

  13. Back to top

    Re: Nice, but...

    Nov 14, 2006 3:38 PM by Pat Osterday

    Randall, Your comment is exactly what I was thinking! I read the article and there's no mention of an app server or anything like that! Just copying the entity code and using that. While Grails looks cool, we've got a lot invested in the JEE resources. Guess we'll have to see what develops!

  14. Back to top

    Re: Nice, but...

    Apr 4, 2007 4:36 PM by Piero Sartini

    Yes, thats what I try to find out as well.

  15. Back to top

    Article in pdf format?

    Nov 30, 2007 8:34 PM by Fred Janon

    Would it be possible to the content of this article in pdf format, to be able to read it offline and print it nicely? Thanks.

  16. Hi, I am stuck following your steps in a very early stage ("run-app" directly after "create-app"): (I am running the grails / groovy-versions mentioned above with JDK 1.6.0_03 on Windows XP SP2) > grails run-app Welcome to Grails 1.0-RC2 - http://grails.org/ Licensed under Apache Standard License 2.0 Grails home is set to: C:\Programme\Dev\grails-1.0-RC2 Base Directory: c:\Arbeit\Allgemein\Dev\Projekte\GrailsTest1 Environment set to development Note: No plugin scripts found Running script C:\Programme\Dev\grails-1.0-RC2\scripts\RunApp.groovy groovy.lang.MissingPropertyException: No such property: war for class: java.lang.String at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:48) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:474) at Config.run(Config.groovy:62) .... Do you have any hints for me? Kind regards Michael

  17. Hello again, FYI: just fixed the error by changing the line grails="error" to grails.app="error" in the generated file "grails-app/conf/Config.groovy". Kind regards Michael

  18. Back to top

    Issue GRAILS-2042

    Jan 11, 2008 12:08 AM by Venky VB

    When I try out the tutorial I get an error which is logged in the JIRA (GRAILS-2042). However there seems to be no action on this issue ? Any workaround available for this ? (am using Grails 1.0 RC3) - Venky

  19. Back to top

    Scrollable results?

    Jun 5, 2008 11:32 AM by Siddharth Bala Ravi

    Jason, Thanks for the article - it's awesome. I was wondering what needs to be done to make the following search scrollable...being very new to grails, i'm having a real hard time figuring it out...

Exclusive Content

VMware Infrastructure 3 Book Excerpt and Author Interview

VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.

Architectures of extraordinarily large, self-sustaining systems

Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.