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.

UPDATE – Mike Weaver’s first installment in a series of posts on Skyway’s extension architecture has been published 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.