Do you like and/or already use Grails but at times want to create an application based on Java and Spring instead of Groovy?  If so, it probably makes sense to take a deeper look at Skyway Builder. Skyway Builder and Grails have the same goal: simplifying life for the developer.  Both Grails and Skyway Builder offer a powerful application scaffolding capability as a key feature.

Scaffolding is best described as having a web application completely or partially generated from a data/domain model specified by the developer.  Scaffolding has become very popular with developers as it offers significant gains in productivity.  By specifying a minimal amount of information about your application, and rest of the application is generated for you according to templates and conventions.

In addition to scaffolding, Skyway Builder and Grails are similar in many other ways, including:

• Open Source – the source code for both solutions is freely available
• Java – both create Java-based web applications
• Spring MVC and Spring Web Flow – both leverage the leading web application frameworks
• ORM and Hibernate – both support modern frameworks for database access and persistence
• Groovy – both support for the leading dynamic language for Java
• Application architecture - both encourage the partitioning (layering) of application components in web, service, and data layers
• Maven Integration – both support Maven for application builds and dependency management
• Extendability – both support the use of third-party and/or custom plugins for extending the functionality

However, there are some fundamental differences in Grails and Skyway Builder as well.  These include the following:

• Grails is web application framework, and Skyway Builder is Spring application generator.
• Applications built in Grails are based in Groovy whereas applications built in Skyway Builder are pure Java Spring applications.
• Grails tools are primarily command-line tools, and Skyway Builder is Eclipse based.
• Grails applications are implemented using Groovy, and Skyway Builder applications can be implemented using Java or Groovy.
• Compared to pure Spring applications, Grails may be perceived as too risky for some projects due to limited options for discontinuing the use of Grails.

Grails and Skyway Builder are both very powerful development tools that provide significant increases in developer productivity when used in the right context.

The remainder of this post is going to dive a little deeper into both solutions and review these fundamental differences to help developers choose when to use Grails and when to use Skyway Builder.

Spring Tooling vs. Web Application Framework

Grails is a web application framework.  It’s an alternative to other MVC frameworks, and it uses Groovy as the programming language and doesn’t require any XML configuration.  Developing a web application in Grails consists of implementing models, views and controllers, and Grails has a set of technologies for implementing each element of MVC.  Controllers are implemented using Groovy classes.  Views are implemented using GSP, a technology that is similar to JSP and contains several Grails-specific improvements.  Models are implemented using Grails-specific object-to-relational mapping framework called GORM.  The Grails approach to simplifying the life for developers was to invent new simplified versions of pre-existing frameworks.

Skyway Builder is a scaffolding and code generation tool for accelerating the development of Spring-based web applications.  Spring provides a framework that abstracts the complexities of enterprise software, and Skyway Builder adds an even higher layer of abstraction to provide a generation framework for Spring.  The abstraction is accomplished by employing a metadata model to capture the specifications from the developer, which in turn drives the code generation process.  For defining the specifications, Skyway Builder provides Eclipse-based tooling which includes the use of metadata, editors, wizards, and modeling.  The generation framework then converts the metadata into generated code and Spring application artifacts (XML configurations).

In summary Skyway Builder and Grails employ two different approaches to simplifying the life for developers.  Skyway Builder does it’s magic at design-time, and Grails does most of it’s magic at runtime.

Use of  the Spring Framework vs. a Pure Spring Web Application

Grails makes extensive use of several Spring frameworks, including Spring Core, Spring MVC and Spring Web Flow.  By leveraging these widely used JAVA frameworks, Grails can focus on value-added functionality instead of recreating all the infrastructure code provided by Spring.  Grails is also able to benefit from the progression of the Spring frameworks and the Spring community.  As new Spring capabilities become available, Grails is well positioned to leverage the capabilities and expose them to Grails developers.  Grails relation to the Spring frameworks also enables a very natural integration with Spring-based artifacts.

While a Grails application is essentially a Spring-based web application, it should come as no surprise that the Grails framework sits between the Spring frameworks and the Grails application.  The following diagram shows the relation of the Grails framework in the application stack.  Grails is a framework on top of a framework.  To get the benefit of Grails, the application stack is a bit more complex because Grails does a lot of it’s magic at runtime.  A Grails application is dependent on the both the Grails libraries and corresponding Spring libraries.

As mentioned earlier, Skyway Builder generates pure Spring web applications.  Skyway Builder doesn’t introduce another layer to the application stack because Skyway Builder doesn’t exist at runtime.  When an application generated by Skyway Builder is deployed, it’s a pure Spring web application, looking just like a hand-coded applications.  The pure Spring web applications conform to Spring best practices.  The code has been vetted by Spring experts and certified by SpringSource, and the applications don’t contain any proprietary code or libraries.  Spring web application development is abstracted using a very simple meta-data model that correlates directly to Spring concepts.  All model-based artifacts have direct links to the generated source files.  So there’s full transparency.  Familiarity with Spring frameworks is rewarded, and a developer can see exactly what was generated.

In summary Skyway Builder and Grails both leverage the Spring frameworks, but they do it in different ways.

Skyway Builder abstracts the use of Spring, and Grails disguises the use of Spring.  Grails also introduces an additional framework to the application stack.  Given that Grails can leverage pure Spring-based artifacts and Skyway Builder generates pure Spring artifacts, Skyway Builder could be used to generate portions of a Grails applications.

IDE-based vs command-line tools

As mentioned earlier Grails is primarily a web application framework.  However Grails also has some command-line tools for starting new projects, creating new Grails components, and leveraging Grails plugins.  While the command-line tools are effective, there are some challenges associated with the tools not being integrated into an IDE.  There is support for Grails and Groovy in some IDE’s, but the integration with the Eclipse IDE is generally considered to be marginal at best.

Skyway Builder on the other hand is an Eclipse-powered development environment. The functionality of Skyway Builder is integrated into the Eclipse platform using the Eclipse plugin architecture.  A developer using Skyway Builder can leverage all the benefits of an IDE, including editors, refactoring support, integrated version control, testing, and deployment.  Integration with Eclipse – arguably the industry’s leading and most dominant IDE – also allows Skyway Builder’s code generation functionality to be run side-by-side in a unified workspace with hundreds of other open-source and commercial plugins in support of the software development lifecycle.

By integrating with the Eclipse IDE, Skyway Builder can also leverage other Eclipse frameworks.  For example Skyway Builder uses the code generation facilities of the Eclipse Modeling Framework (EMF) for generating the Spring and Java code.  Skyway Builder also uses the Graphical Modeling Framework (GMF) for implementing graphical editors for Spring artifacts.

While Grails isn’t IDE focused, it could be argued that Grails doesn’t need to because it’s primarily a runtime framework.  In contrast with Skyway Builder – which is purely a design-time tool – most of Grail’s functionality is accomplished at runtime.  Therefore Grails may not need strong IDE support.  Nevertheless many development teams may prefer to have an integrated development solution and not have to switch between an IDE and command-line tools.

Using Groovy or Java and Groovy

Dynamic languages offer a lot of benefits to application development and Grails makes very extensive use of a dynamic language called Groovy.

Groovy scripts can run on the Java platform, making it a very complimentary technology to Java.  Groovy supports the Java language, making it easier for Java developers to start using Groovy.  Groovy also has it’s own abbreviated syntax for simplifying the implementation of certain functions (i.e. XML processing).  Since Grails is highly dependent on Groovy, the two solutions are often considered one of the same.  However Groovy is an independent project that can be added to any java application.  Java applications choosing to use Groovy are not required to use Grails.

Skyway Builder also supports the use of Groovy.  The pure Spring artifacts that are generated by Skyway Builder can use Groovy (instead of Java) to implement the logic.  This lets developers use the enhanced Groovy syntax for expressing logic that would have required considerably more Java logic.  This also enables developers to do things like quickly scripting out portions of an application prototype.  During development some or all of the Groovy script from the prototype can be replaced with pure Java code.

Applications generated by Skyway Builder integrate with Groovy in the manner prescribed by Spring, where the Groovy script is maintained externally from the Java code and wired-in (injected) using Spring.

Skyway Builder and Grails – Strategy for discontinued use

When using new technologies like Skyway Builder or Grails for productive work, it’s important to consider the strategy and consequence for discontinuing the use of the technology.  It can happen for a variety of reasons, and it’s important to understand the exit strategies prior to choosing the new technology.

With Skyway Builder it’s pretty simple.  The consequence of walking away from using Skyway Builder is that you will need to maintain your Spring application by hand.  Since the generated application is well-formed, SpringSource certified code, the application as generated resembles a hand-coded Spring application which Spring developers can easily maintain by hand.

For Grails it’s a different story.  It’s not easy to discontinue the use of Grails.  As a consequence of being a framework, if you decide to stop using Grails, you will need to re-implement major portions of your application.  Depending on the lifespan of the application, the effort of ongoing maintenance may be a concern.

Summary – Decision Criteria for Skyway Builder

Hopefully I’ve shed some light on the differences between Skyway Builder and Grails.  It basically comes down to this:

If you want to create Spring-based applications but do not care if they are “pure” Spring applications then using Grails framework may be the appropriate choice.

On the other hand if you want the power of Grails but need to be able to build and/or extend pure Spring web applications then Skyway Builder is likely worth consideration.

Here’s a summary of some Skyway Builder community feedback for having chosen Skyway Builder over Grails:

• Requirements were to develop a pure Spring application.
• Needed to extend the functionality of an existing hand-coded Spring application
• Have extensive Spring expertise that we wanted to leverage, if needed.
• Interested in Skyway Builder’s approach to MDD (model-driven development) for Spring applications.
• Skyway’s code generation framework can be extended through Eclipse plugins.  During a proof-of-concept with Skyway, we were able to build custom plugins to augment Skyway’s code generation, all in one day.