Recently, I posted Skyway’s Top 10 Guiding Principles for Software Generation.  These principles have assisted us in setting the course for our technology and market direction.  We are very interested in continuing this conversation with the community, so please comment below with your experiences and feedback.  In this post, I review Skyway’s approach to the implementation of these principles and lay the groundwork for future posts that dive a little deeper into our architecture.

Skyway’s Approach

Skyway was designed to deliver 4 major classifications of technologies to the marketplace.

1. Software Generation Engine

2. DSL for Enterprise Applications

3. Spring/JEE Generations

4. Spring/Eclipse Tooling Integration

Generation Engine

The reason we started with the Generation Engine was simply because we have found over many years now that as much as we would like it to not be true, no two shops, and in many cases, no two projects, follow the exact same coding standards, architectural approaches or deployment scenarios.  Historically, the resistance to software generation has always led back to this road and the idea that as soon as things get complex, generation falls down, or that people get “boxed in” to the code that is generated.  We also found that there are lots of people out there who have written their own generation utilities over the years but haven’t really had a place to put them long term.  We thought it would be good to try to create a community and supporting technology where software generators could find a home.

Finally, we found that many organizations and systems integrators were embarking on an “Industrialization” strategy which typically focused on creating a standard set of tooling and technologies that could be used consistently on software projects.  Often, the ability to generate as much of the solution as possible is an integral part of those strategies, along with project bootstrapping,  working examples, documentation, best practices, etc.  We felt strongly that it would make sense to provide a foundational technology to these groups to assist in the effort of industrializing their approach to building enterprise technologies.

DSL

Skyway defines a Domain-Specific Language (DSL) for the core concepts that are used to build enterprise applications.  This DSL has been formalized as a set of EMF models and extensions to that Core model and characterizes those things that represent the essence of the building blocks of enterprise applications.  We are working with our partners to expand the set of concepts in this model to include things like Batch, for example.

The Skyway DSL is a layered model in that it describes core concepts but allows for those concepts to be decorated through extension.  For example, a Service is a core concept, but a separate model can decorate the Service model and add JAX-WS meta-data to the Service model, or DWR meta-data, etc.  It is very important to note that in some cases, there is a one-to-one mapping between “concept” and implementation artifact. But in most cases, there are many artifacts that need to be generated or updated for each “concept”.  This is why modeling techniques that focus on modeling each “Class” often create models that are too complex for the layer at which they are being consumed.

Generations

Skyway allows for the idea of creating “Generations” which are sets of Artifact Definitions that are grouped together to support a particular target environment or generation outcome.  Anyone can define a Generation and extend the Skyway tooling to generate whatever they wish.  Skyway ships with a prebuilt set that supports a highly refined set of code and configuration best practices that have been derived through the experiences of our customers, the requirements of our partners, and the certification process of SpringSource.

Skyway currently supports the generation of a very wide set of artifacts including JPA and JAXB annotated Domain Objects, Simple Spring Components, Spring MVC based Web Controllers, Spring Services which can be configured to also emit JAX-WS Web Service code and configuration, as well as DWR configuration and many others.  Skyway has prebuilt CRUD generations that automatically create the CRUD Services and Controllers, JSP Pages, Site Mesh configuration, Spring Security Configuration, etc for a domain model that can be originated from UML, RDBMS tables, XML, or built using our own editors.

Tooling Options

Skyway has set out to enable as many developers as possible to be able to build and generate Spring-based applications.  We started first by building a rich set of visual designers to make it easy to build out applications and wire them together.  We then added support for UML to enable those who have an existing investment in UML to be able to generate running Spring applications, thereby increasing the value of their UML investment.  Over the next few months we will also offer a Command Line Interface that will incorporate the syntactical elements of the Roo project in order to provide additional generation options for users who invest in leaning that syntax.

We are also working on round tripping to enable developers to create and modify Java code files and have those files be used to generate other upstream and downstream artifacts like UML models and User Interface components and scaffolding.  We believe that when viewed in concert, these options provide something for everyone and enable developers of many points of view to build they way they want to, but to still get the benefits of standards based generation and productivity gains.

In the next week or so Mike Weaver, Principle Architect at Skyway, will post a deeper review of the extension architecture and describe the process for customizing the code generation process.  In the interim, you can check out our open-source project here.

I thought it might be worth while to start to document Skyway’s point of view regarding enterprise software generation, and the things that we think are important in this space. Our goal is to promote an active conversation and to solicit feedback of all sorts to ensure that we are working to address those areas that the industry feels are most important to the adoption of generative techniques and ultimately the simplification of delivering enterprise software.

Our Top 10 Guiding Principles for Software Generation

1. Offer Incremental and Additive Approaches - Developers should be able to realize the benefits of software generation on their own terms using as much or as little of a generation system as they wish
2. Extensibility is Key - The generation system must be extendible, configurable, and customizable at every level
3. Exploit Every Asset - The possible sources of inputs to the generation should be as diverse as possible and be expandable by developers
4. Support Every Developer - Provide tooling options that enable the widest set of development approaches and experience levels
   1. UML
   2. Skyway DSL / Visual Editors
   3. Other DSMLs (either UML-based or MOF/EMF-based)
   4. Java
   5. Command Line Interface
5. Don’t Repeat ANYONE - Enforce the DRY principle by acknowledging that Java code is not the only place, and often is not the first place, where the definition of software concepts may occur.
6. Offer Options for Post-Generation Changes - Changes to generated artifacts should be supported through a combination of:
   1. Source Round Tripping
   2. Intelligent Merging
   3. User Editable Dependency Injections
   4. Generation Componentization (Smallest possible components)
7. Avoid Lock-In – Generated artifacts should be indistinguishable from those that would be written by hand by a developer following best practices. Developers should be able to walk away from the Generation approach at any time.
8. Technology Changes as Often as the Requirements - Provide a clean translation from conceptual design to implementation remaining as permissive as possible to long term syntactical changes in the implementation language, architectural approach, and runtime framework
9. Generate on Demand, Automate by Request - Give developers control over when and how the generation and reverse generation processes will run (Automatically or “On Demand”)
10. Ex Uno Plures (Out of One, Many) - Deliver as much functionality as desired with as few inputs as required

In my next few blogs I’ll begin to add detail to these concepts and dive into the Skyway implementation a bit, where we are, and where we are going. I’d love to hear more feedback from the community about what principles you think are important. I’d also like to know what things you currently spend time on that you would like to see automated or generated in the future.  In the interim, you can check out our open source project here.

UPDATE - The second installment in this series of blog posts has been published here.

Code generation has existed for a very long time.  It was originated by developers seeking to reduce the mundane, repetitive and boring aspects of application development, and today, just about every development platform and programming language can leverage code generation to some degree.  In this series of blog posts, I plan on reviewing two primary topics:

• The various levels of code generation that exist today for Spring-based applications
• The ways that code generation increases developer productivity

While there are a variety of code generation solutions related to JEE and Spring development, this series of blog posts will focus primarily on the functionality provided by Skyway Builder.

Before diving into the various levels of code generation that are available for Spring-based web applications, I think it’s worthwhile to briefly review code generation in the context of JEE application development.  The goal of this first blog post is to set the context for the rest of the series, and it isn’t intended to be a thorough review of the history of code generation for JAVA.

Code Generation and JEE Application Development

The software development industry has been tackling the complexity of software development for a very long time.  While the early implementations of enterprise JAVA (JEE) introduced a standard programming model for web-based applications, it suffered from complexity and a requirement on excessive amounts of JAVA code.  A JEE application consisted of both application-specific code (business logic) that was directly related to the functionality of the system being built, and also a lot of boilerplate code that was required by many of the JEE-related API’s.  In many cases, the application code and boilerplate code were commingled, making JEE development even more difficult.

Dissatisfied with the state of JEE application development, architects and developers embarked on making things simpler.  It was at this point that code generation really took off with JAVA.  While developers were starting to experiment with using code generation for the business logic, the low-hanging fruit of JEE complexity was clearly in the generation of the boilerplate code.  This is where technologies like XDoclet came into existence and thrived.

New Styles of Development Enabled by Code Generation

As the JAVA platform evolved, the JEE programming model also saw some major improvements.  A concerted effort was made to simplify application development, and many of the complexities of JEE were targeted.  While the platform already leveraged code generation in some places (i.e. JSP/Servlet), there were opportunities to expand the use of code generation to further simplify the JEE programming model.  Annotations were introduced in Java 5.0 to generate a lot of the boilerplate code automatically.  This declarative style of development shifted the burden of generating the boilerplate code; boilerplate code was generated by the compiler instead of the developer. In addition to providing many out-of-the-box annotations, Java 5.0 also provided an annotation framework for defining custom annotations.  This standardization enabled third-parties to build custom annotations to harness the power of code generation.

With boilerplate code being managed and generated in a standard way using JAVA annotations, a greater portion of the JAVA code that remained was actually related to the functionality of the system.  Additional reduction in the amount of boilerplate code was made possible by dependency injection, a mechanism for decoupling application components from lower-level infrastructure logic.  As opposed to an application component being responsible for provisioning the components and services that it’s dependent upon, with dependency injection the dependencies of an application component are passed to it.  While there are numerous benefits to dependency injection, a major benefit was the reduction in repetitive code required for provisioning dependent components.  This led to a new style of developing enterprise JAVA applications referred to as Plain Old Java Objects (POJO).  The POJO-based style of development made it easier to define and manage business logic because the business logic was less tied and less tangled in infrastructure code.

POJO-based development leveraging dependency injection and annotations is very powerful, however it wouldn’t be possible without implementations of each.  As is usually the case with JAVA, various implementations exist.  In contrast with the core services in JEE, there isn’t a JAVA specification or standard for dependency injection.  There also isn’t a preset list of possible annotations.  Therefore implementations can vary quite a bit in both conventions and functionality.  The most successful implementations are the ones that are part of a comprehensive application framework.  The Spring framework is one such framework, and it fully exploits the power of dependency injection and annotation-based development.  For this reason many believe it has become the defacto standard JAVA framework.

Generating Fully Functional Applications

With the emphasis on simplicity and advances in JEE application development, some JEE practitioners feel that we’ve reached the limit of the practical use of code generation.  It’s interesting that today’s criticisms and arguments regarding code generation are relatively the same as five or even ten years ago.  Yet code generation continues to creep into JAVA/JEE development at a faster and more ambitious pace, making application development easier.  Most recently several RAD platforms, including RAILS and GRAILS, have been further popularizing code generation through the use of scaffolding.  Scaffolding, which will be covered in detail in a later post, consists of generating full applications by applying standard application patterns from a minimal set of inputs provided by the developer.  Whether these scaffolded applications are used as-is or as the starting point for additional developer customization, scaffolding is very effective at jump-starting application development.

The Spectrum of Code Generation

Code generation is an enabler of many of the improvements and simplifications in JEE application development, and the application of code generation is very broad.  At one end of the spectrum code generation is emanating from the lower levels of the application stack. Improvements to the JAVA language, the use of new architectural patterns like dependency injection and the capabilities enabled by modern JAVA framework implementations (i.e. Spring Framework) are all rooted in code generation.  Cumulatively they have made application development easier by providing a foundation of code generation.

At the other end of the code generation spectrum there is scaffolding, the generation of fully functional applications through the automated instantiation of application patterns, like CRUD.  Scaffolding has highlighted the potential for code generation beyond just reducing boilerplate code, and it represents a more course-grained application of code generation.  As the formal specification of additional application patterns are derived, code generation technologies are prepared to automate the creation of systems based on those patterns.  Coincidentally this would be a significant milestone for industrialized software development.

Whether you are using code generation at a fine-grained level or a course-grained level, code generation offers sustainable benefits in both productivity and quality, and the benefits apply to both application development and maintenance.  We will continue to see refinement and innovation at both ends of the code generation spectrum.  Furthermore with the applicability of code generation becoming more mainstream, there is an opportunity to expand on the conventional use of code generation to achieve even greater benefits.  The essence of code generation is to achieve technical and functional objectives with minimal input and in as few steps as possible, and this can be applied to just about any aspect of application development.

In the next several blog posts I will be diving into the various aspects of code generation available for Spring MVC and Spring Web Flow applications using Skyway Builder.  I will cover bootstrapping, scaffolding, application artifact generation, artifact implementation generation, and model-driven development.  You will discover how you can leverage some or all of these code generation capabilities on your Spring-based application projects.  I will describe how Skyway Builder applies conventional code generation techniques, and we’ll explore some of the innovations in Skyway Builder to further exploit code generation.

Let me know your thoughts.  Does this seem like an accurate portrayal of code generation?  Do you have any specific questions you’d like answered in this series?

For those of you who missed this week’s UML to Spring webinar, the replay is now available here.  Just a few of the highlights included:

• IBM Rational Product Manager, Bill Smith, describing the IBM RSA core competencies: abstraction, automation, simplification and collaboration
• Skyway Software CTO, Jared Rodriguez, reviewing how Skyway Builder adds Spring MVC tooling, including a palette of Spring abstractions, to IBM RSA
• Jared bootstrapping a Spring project and deploying it to WebSphere in just seconds
• Both Bill and Jared answering a variety of questions posed by the webinar attendees

Check out the webinar replay here.  And, to learn more about accelerating Spring application development using RSA and Skyway Builder, visit http://www.skywaysoftware.com/products/uml/.

Last week at Spring One, Rod Johnson acknowledged in his keynote address what we here at Skyway Software have been saying for a long time: application frameworks combined with code generation technology are required to significantly boost Java developer productivity.  It is great to hear SpringSource finally espousing the benefits of code generation and automating the “low value” coding items that developers oftentimes spend days, to even weeks, on while working on their projects.  I have been touting these benefits for years, so it is great to see SpringSource finally recognizing the value.

Rod’s Ringing Endorsement of Code Generation was Much Needed

Roo is a great first start, but it has a long way to go to accomplish what we here at Skyway Software believe that enterprise java developers need in a code generator.  There are many things a code generator should do, and we use several basic ones as our guide:

• Simple and intuitive input for the generator
• Open and extensible generator
• Generated code that looks “hand coded”

Generator Input

Skyway Builder is built as a rich set of Eclipse tooling.  While Roo has you working from a command prompt to define the domain objects and controllers, Skyway Builder gives you a graphical view in the Eclipse navigator and within Eclipse editors to construct these artifacts, and more.  We leverage all of the great things in Eclipse that developers are accustomed to using for constructing the generator inputs. Read the rest of this entry »

Skyway Builder is designed to improve developer productivity by abstracting Spring MVC and Spring Web Flow development.  By using simple concepts (like Controller, Services, Operations, etc…) a developer gets best practice and SpringSource-certified projects while being shielded from the intricacies of Spring application development (api, annotations, and configuration files).  Furthermore, through the use of rich visual editors, a developer is guided through the definition of these components, without having to memorize configuration options. Read the rest of this entry »

Skyway Software is a sponsor of the IBM Rational Software Conference 2009!  Join us May 31 – June 4, 2009, at the Walt Disney World Swan and Dolphin Resort in Orlando, FL.  Conference attendees will discover real ways to drive measurable business value, while lowering the cost of software and systems delivery.

Come visit the Skyway Software team in the Ready for Rational Pavilion, Pedestal A.  We will be offering onsite demos and holding daily drawings for a copy of Skyway Builder Enterprise Edition (EE), the commercial version of our Spring DSL that integrates with Rational Software Architect to accelerate the delivery of Spring applications.

Skyway Software will also be co-presenting with IBM in the Modeling, Architecture and Construction (MAC) track:

Building Spring Applications Using Rational and the Skyway DSL (MAC16)
Thursday, June 4, 9:45 am - 10:45 am
Jared Rodriguez, Chief Technology Officer, Skyway Software
Andrew Berner, Lead Architect, ISV Technical Enablement and Strategy, IBM Rational

Abstract:

Over 50% of all enterprise Java applications being developed today are based on the Spring Framework. Skyway Builder, a Domain-Specific Language (DSL) for Spring, and its integration with Rational Software Architect enable a Spring application to be envisioned and modeled within Rational using UML and the Skyway DSL. That UML is then transformed into annotated Spring code and configuration files that are wired together and ready for deployment to WebSphere or other application servers.

We look forward to seeing you in Orlando!

In conjunction with the release of Skyway Builder 6.2, we’ve published an updated series of videos for generating a Spring MVC application using Skyway Builder.

All Skyway Builder videos can be found here, and here’s a list of the Spring MVC tutorial:

• Skyway Builder 6.2 - Spring MVC Tutorial Overview and Project shell creation
• Skyway Builder 6.2 - Spring MVC Tutorial Part 2 - Data layer
• Skyway Builder 6.2 - Spring MVC Tutorial Part 3 - Service layer
• Skyway Builder 6.2 - Spring MVC Tutorial Part 4A Web layer
• Skyway Builder 6.2 - Spring MVC Tutorial Part 4B Web layer

These videos cover the Spring MVC tutorial that can be found under Skyway Documentation.  There’s also a Spring Web Flow tutorial that produces the same application as the Spring MVC, but it uses Spring Web Flow instead.

Skyway Software announces the general availability (GA) of Skyway Builder Community Edition (CE) 6.2, an open source, code generator for the Spring Framework. Version 6.2 of Skyway Builder CE is available for immediate download.  Skyway Builder Enterprise Edition (EE) 6.2, the commercial edition of Skyway Builder, is also now GA and is available for test drive.

This major release of Skyway Builder includes:

• Improved Spring MVC scaffolding capabilities that allow users to generate a Spring-based, Java CRUD application in minutes
• Eclipse 3.4 (Ganymede) support
• Integration with IBM Rational Software Architect 7.5.1 to transform UML into working Spring applications
• Spring Web Flow support and visual flow editor
• Enhanced Groovy integration based on Spring-Groovy best practices
• New Skyway step types for automated file access and file transfer (FTP) capabilities
• Integrated support for inline Java code, including content assist
• Enhanced Spring MVC support and code generation
• New JPQL Native Query support
• Enhanced Model to Code view linking
• Enhanced Spring configuration options
• Enhanced code generation to support Spring best practices
• Improved documentation and tutorials
• Over 500 bug fixes and enhancements

Download CE or request a Test Drive of EE today!

It is very satisfying to develop Spring MVC and Spring Web Flow applications using Skyway Builder.  Using the Spring abstractions provided by Skyway Builder, large portions of your Spring application are generated.  Some of the available abstractions include controllers, models, services, operations, data types, and data stores.  When defining applications using these abstractions, it’s often desirable to switch to the generated code.  This is particularly true when you are starting to use Skyway Builder, and you aren’t really sure what Skyway Builder is generating for you automatically.  A great way to discover what’s generated is to examine the generated code.

While the generated code and configuration files reside exactly where you told Skyway Builder to generate them to, it can become a bit of a challenge to identify the source files in a folder that were generated by a particular abstraction.  Since an individual source file may have been derived from multiple abstractions, it can become even more difficult to identify the portions of source file that are related to a particular abstraction.

That’s where the new and improved Generated View comes in to play.  As you highlight an application element in the Skyway Navigator, the Generated View will show you all the code and configurations artifacts that were partially or fully generated by the definition of the highlighted element.

To stay in the loop on the upcoming 6.2 release, please follow us on Twitter or join the Skyway Community. As one of the many benefits of joining our community, you will automatically receive product announcements and updates.