Join us on January 28th for a webinar that will introduce you to the new “MyEclipse for Spring” product from Genuitec and Skyway Software.  Targeted for production release in Q1 of 2010, MyEclipse for Spring is a set of accelerators for Spring development.

Get started with Spring, generate all of the architecture you need to get going, and then customize your projects – all in minutes, not days.

What does that really look like? We will be covering the following technical topics and concepts:

* Spring MVC Scaffolding: Quickly generate Spring MVC CRUD applications from database tables, POJOs and JPA entities
* Spring Project Bootstrapping: Automatically create Spring configuration files and add Java libraries and web resources
* Enhanced Spring Development Editors: Simplified configuration of Services, Controllers and Spring Web Flow

The Webinar will run for approximately one hour and include a QA session following the technical presentation.

When: January 28, 2010 at 11am Central/Noon Eastern Time (UTC -6)
Where: https://www2.gotomeeting.com/register/356610891

Participants will be given the option to participate in a free, early-access program.

Want a sneak peak?  Check out this preview video:

Last week, we announced that Skyway Builder has been modularized into five separate editions to better meet the specific needs of Java/Spring developers.  And, as part of that restructuring, our commercial edition pricing now starts at $99.

This week, I’m happy to announce that the commercial editions of Skyway Builder are now available for online purchase in our new Skyway Store.  Of course, those of you using the free, open source Skyway Builder Community Edition (CE) can continue to receive product updates just by downloading, but if you are looking for any of the features found in our commercial products, purchasing your subscription license is now easier than ever in the Skyway Store.

You can check out the Skyway Store here.

Gathering and validating user requirements is tedious, tough and thankless work for most IT organizations.  Requirements gathering typically takes a long time, especially in a large, complex organization.   And, unfortunately, even after spending a lot of effort on the task, most organizations still don’t get the requirements right up front.  This happens for a whole host of reasons and results in costly rework, frustrated users and unmet business needs.

I believe the primary reason application requirements are inaccurate and/or incomplete is because the process used to gather the requirements is in most organizations fundamentally flawed.

People, for the most part, are visual creatures.  This is best expressed by the common catch phrase “I’ll know it when I see it”.  Even if users actively participate in requirements gathering exercises and “sign off” on the requirements, they always reserve the right to object until they actually see a working system.

Unfortunately, most requirements gathering approaches today are heavy on the textual capture of user requirements – perhaps with some UI mock-ups done in HTML and process/application flows via Microsoft Visio.  This results in approaches that are very light on the actual validation of the requirements through use of software prototypes.

As a result, the first time many users actually see their requirements in the context of a working application is in the user acceptance testing phase of a project.  It’s at that point users typically say things like ”that’s not right” or “that’s not what I meant”.   At this point, users and developers alike get pretty frustrated, and the non virtuous (and expensive) cycle of rework begins to implement the “real” requirements of the users within the application.

I firmly believe that no application system should be implemented that has not been prototyped.   Most IT organizations resist prototyping for two reasons: 1) the rationale that building a prototype may take just as long as developing the application,  and 2) the premise that the prototype itself will end up being largely throw away.  So while a software prototype will improve the accuracy of the requirements, it does so at the cost of essentially developing a system twice.  With this trade off, most IT organizations opt for “good enough” requirements that they know will have to be fixed once the user sees the application during user acceptance testing.

Using software generation technology like Skyway Builder, IT organizations can change this dynamic and make prototyping economical.  Skyway Builder enables the building of prototypes in weeks rather than the months it would take to build them using conventional development tooling.  In addition, because of Skyway Builder’s advanced data and web service discovery capabilities, these prototypes will enable you to validate what data the planned application will use and how to best access it.

Once a user sees and interacts with the software prototype the “that’s not what I meant/need” type comments still will arise.  However, they will be raised much earlier in the development process and will be much less expensive and time consuming to handle.  After a series of iterations using the prototype, the user will sign off on the requirements documentation with a much higher confidence level that their requirements have been captured accurately and completely.

The other benefit of using a true development platform like Skyway Builder for software prototyping is that up to 50% of the actual system will be developed during the prototyping phase.  The prototype isn’t throw away; it’s essentially a scaled-down version of the planned application and as such can be used downstream in the formal development process.  This dramatically reduces the time and expense needed to build out the desired system, often resulting in project schedules, efforts and costs 30% shorter than those using conventional requirements gathering approaches and tooling.  And most importantly, the application will be delivered right the first time due to software requirements validated through use of prototyping up front.

As I discussed in an earlier post, automated software generation technologies can dramatically improve the productivity of developers.   The business value of these tools is only increased when you consider the impact they can have on the effectiveness of the requirements gathering and validation process — effectively making software prototyping economical and practical.

Skyway Builder, our code generation and scaffolding tool for Spring web applications, is now available in a variety of open source and commercial editions.  In conjunction with the release of Skyway Builder 6.3, the product has been modularized so that users can leverage the edition tailored to meet their Spring development needs.

Key features of each edition include:

• Community Edition: Spring MVC CRUD scaffolding, Spring Web Flow support, reverse engineering of DB Schemas
• Standard Edition: Commercial app server support, additional logic modeling steps, advanced web controls, Spring Security
• Web Services Edition: DWR support, JAX-WS support, Contract First/Last Web Services development
• Professional Edition: Configurable code generation via templates, configurable scaffolding via templates
• RSA Edition: RSA UML to Spring extensions, Spring to RSA UML extensions

Community Edition, the free, open source version of Skyway Builder, is available for download.  The commercial editions of Skyway Builder are available for evaluation.  See pricing and a comparison of features across the new editions here.

During a recent discussion at a large enterprise, I was amazed to learn how much terminology really matters when talking about something as politically charged as code generation seems to be in most development shops.

We started the session with our standard Skyway overview presentation in order to level set the group on our technology.  One of our key messages is that Skyway Builder is a “code generation framework for Java Spring“.

All of the influential architects and senior developers in the room essentially responded to the concept of code generation with “been there, done that, didn’t work, not doing it again”.  And, that was in the first 5 minutes of a planned 4 hour session.  Needless to say, we had our work cut out for us that day.  Given we had the time booked and no one bolted for the door, we persevered in the conversation.

In order to clarify and better understand what they were telling us, our first clarifying question was:

“When you hear us say ‘code generation framework for Java Spring’ what does that mean to you?”

Turns out, it meant – for virtually every one of the architects and senior developers in attendance – generation of the actual business logic of a particular service.   Ah, so now their skepticism was making better sense.  Code generation is one of those “loaded” technical terms that we “know” what it means to us, but it may mean something completely different to the people we talk to about it.

So the next thing we did – in order to create some clarity for the rest of the discussion - was to break down code generation into more manageable and discrete categories.  For simplicity, we suggested to the group there are really two major forms code generation that occur on every project:

• Scaffold Generation

• Logic Generation

We defined Scaffold Generation as generating the application code shells directly from stereotyped design diagrams that define the expected application architecture style.  The generated artifacts include the following:

• classes with method signatures only (i.e., no implementation in the method bodies)
• configuration files
• inter-class references

With scaffold generation, developers start with application shells, which were created exactly as defined by the architected design, and code the implementation logic within the method bodies of those architected shells.

With Logic Generation, the design diagrams not only contain architecture stereotypes for the class definitions (the stopping point for scaffold generation) – it also provides design elements for logic implementations and provides the full working application upon generation.

Once we laid out these definitions, you could see the tension in the room melt away.  We continued the discussion and discovered that with a major application being designed right then, there were likely going to be over 50 services that needed to be built based on current estimates.  After some probing and discussing, it was agreed that over 75,000 lines of code would need to be written, tested/debugged and maintained that fell into the category of scaffold code.

Virtually everyone in the room agreed that if that code could be generated directly from the UML-based design documents – and kept in sync throughout the life of the project – using automated scaffold generation technology, the savings could be in the 1 to 2 million dollar range for the project (based on cost estimates of $20/line of code for the project).   This really got people thinking about how they needed to further explore scaffold generation technologies for the project.

To be candid, this group did not warm up to the idea of Logic Generation as much as we might have liked when we discussed that topic.  They still believe it is more efficient to hand code the logic of each of the business services.  While we do not share this view, we understand it and agreed to table that discussion for another time.

The project has now agreed to do a production pilot to prove out the value of scaffold generation for their project over the next 30 days.

I took away a key lesson from the session that day.  Here at Skyway, we need to make sure we use clear language when speaking about software generation technologies with future audiences.  When we use distinct and clear terminology, even those skeptical about “logic generation” clearly see the value of “scaffold generation” for pretty much any Java Spring project of any reasonable size/complexity.  And, by focusing on scaffold generation first and making that successful, it can leave the door open to talking about logic modeling down the road, once success with scaffold generation has been realized.

We are pleased to announce that Skyway Software is a sponsor of SpringOne 2GX, SpringSource’s fifth annual developer conference for the global Spring community.  This year’s conference is being held at the Roosevelt Hotel in New Orleans from October 19-22, 2009.  Read the press release here.

Joining us in the Skyway booth will be Todd Dunnevant, the Lead of IBM’s Architecture Management Community of Practice.  Todd and the members of the Skyway team will be demoing Skyway Builder’s integration with IBM Rational Software Architect, including:

• Spring profile for IBM Rational Software Architect
• UML support for Spring stereotypes
• UML <-> Spring DSL transformations
• Template-driven generation of Spring MVC applications

And, of course, we’ll also be highlighting some of the new features in Skyway Builder 6.3, including:

• Enhanced Spring MVC CRUD scaffolding
• Service, DWR, Web Flow and Web Service support for RIA development
• Spring development accelerators
• 100% configurable and customizable code generation

Stop by the Skyway Software table to meet the Skyway/IBM team and register for a chance to win a free iPhone.

See you New Orleans!

Earlier this summer, our “Spring Roo, Skyway Builder and Code Generation” blog post caught a lot of attention and created a great dialog between Skyway CTO and Founder, Jared Rodriguez, and Spring Roo Project Lead, Ben Alex.  As a follow-on to that post, we were contacted by InfoQ writer, Srini Penchikala, to continue that discussion in his article “The Role of Code Generation in Java Application Development“.  For additional perspectives from both Ben and the Skyway team on the impact that code generation has had on Java application development, checkout Srini’s article here.

And, not all of our responses made it into the article — the full set of questions and answers is below.

Read the rest of this entry »

In a recent feature preview, I discussed the configurable code generation feature (see Skyway Builder 6.3 Preview – #4 Configurable Spring Code Generation).  I thought it would be helpful to follow-up that post with an example of how this feature was used in a recent development scenario to adapt the Spring/Java code generation to the standards of a specific project.  This project had some coding standards related to Java that deviated from the default conventions in Skyway Builder, and one of the specific standards that was different was related to the file name and package name of Java interfaces.  This is a classic debate among application developers, and I was amused to find several passionate online debates regarding this topic.  (For your amusement, here’s a one, and another one and  one more for the heck of it).

The Skyway Builder conventions regarding the name and location of Java interfaces is that the interface name is not prefixed and the interface is located in the same package as the implementation classes.  In the majority of cases, this is usually a pretty safe convention; however, in the case of the enterprise development project I’m referring to, the conventions weren’t appropriate.  The project team had agreed at the beginning of the project that the interfaces would be prefixed with the letter “I” and all interfaces would be located in a sub-package called “interfaces”.

While the developers and architects on the project didn’t have a strong opinion one way or another, they all agreed that there should only be one standard, and it should be enforced across the entire project.  It was not acceptable to have different standards for hand-coded versus generated code.  Since the development project had started prior to the discovery of the Skyway Builder accelerators and code generation for Spring, there was already a significant amount of code that had been hand-coded using the agreed-upon development standards.

The solution was to leverage the customization options in Skyway Builder.  From the Code Generation tab in the Spring DSL editor, you can see all the code generation conventions used by Skyway Builder.  If you are using Skyway Builder Enterprise Edition (EE), additional conventions are listed that relate to EE code generation features.  The following screenshot highlights the code generation conventions for interfaces.  As you can see, they are broken out by service, components, and DAOs.

Modifying the conventions will alter the code generation.  While the conventions can be customized on an artifact-by-artifact basis, updates to the conventions in the Spring DSL editor will apply to all artifacts (unless, of course, those artifacts have been individually customized).  The solution was to prefix the filename (2nd column) with an “I”, and add “.interfaces” to the end of the package name (3rd column).

While some might regard this to be a pretty trivial example, I will argue that it’s trivial only because the Skyway Builder code generation engine can be so easily adapted.  Furthermore, depending on the level of code generation leveraged by a development team, it’s conceivable that a team can decide on their development standards towards the end of the development project.  Now that’s a radical thought! All they would need to do is reconfigure the project  according to their project standards and regenerate the project.  This also provides you a glimpse into the power of using Skyway’s Spring DSL.  Application components that are defined using the Spring DSL can be repurposed for different projects.  Even if the projects don’t share the same standards, an application developer can simply reconfigure (the code generation) and regenerate.

At the core of Skyway Builder is the Skyway Generation Framework, our Eclipse-based engine that provides extensible code generation and scaffolding capabilities. The Skyway Generation Framework takes XML models (specifically EMF) as input and produces files, or artifacts. Recently, in addition to our standard code generation and scaffolding, we have seen a growing number of Java architects using the Skyway Generation Framework to create a custom generation platform based on their company’s technical requirements.

Mentioned as #2 in Jack’s “Top 10 Principles of Code Generation” blog post, extensibility is key.  We believe that a good code generation system must be extendible, configurable, and customizable at every level. The goal of this series of blog posts is to provide a deeper review of Skyway’s extension architecture and describe our capabilities for customizing the code generation process.

Skyway Generation Framework

The Skyway Generation Framework can be used to generate any type of textual file. The generation process can be triggered explicitly through a Java API or configured to automatically execute when a model changes through an Eclipse builder. Currently, the generation engine runs inside the Eclipse IDE, but plans are underway to allow headless execution.

The framework centers on artifact sets, which are composed of artifact definitions, emitters and invalidators. Since artifact sets are linked to Eclipse facets, they can easily be applied or removed from a modeling project, which allows developers to generate different versions of code from the same application model.

An artifact definition describes an artifact and consists of a template, a generator, a beautifier and a merger.

• The template is the blueprint for the artifact.
• The generator uses the template to create the artifact. Since the generators are pluggable, the framework is not coupled to any specific template technology. JET and Velocity are commonly used and different technologies can be commingled; you can use JET for some artifacts and Velocity for others.
• A beautifier cleans up the generated file. By using a beautifier, the template author does not have to worry about things like indentation. Stock beautifiers are available for Java and XML files.
• The merger controls what happens when a generated file must be merged with another version of the same file. A merger allows a user to modify a generated file without having those changes overwritten if the file is re-generated. JMerger, from EMF, is used for Java source files, but other mergers can be written and plugged in. JMerger is controlled by a rules file and Skyway Builder’s stock artifact sets define an artifact for this rules file, so it is generated into each project. Since this file is exposed and easily accessible, the Java merging rules can be adjusted on a case by case basis.

All of Skyway’s templates are developed using JET. The org.skyway.integration.java plugin provides many custom JET tags, in addition to the basic tags provided by the JET framework. These tags encapsulate reusable snippets of Java code. For example, the ThrowsListTag is used whenever a Java throws clause is emitted and a PackageTag is used whenever a Java package statement is emitted. The Skyway JET tag library can be used independently of the Generation Framework, even if you aren’t extending Skyway JET templates.

Our JET tags make heavy use of emitters, which are small pieces of code that know how to emit commonly used strings. Emitters are not coupled to JET, which allows you to leverage them in other template frameworks or inside non-generation code. And of course, emitters are pluggable and can be overridden.

The scope of what gets generated is controlled through invalidators. An invalidator is a way to mark one model dirty when another type of model changes. For example, you may want to re-generate all of your data objects when your database settings change. There are stock invalidators available for common scenarios, such as marking the project dirty.

Extending the Framework

The Skyway Generation Framework is very extensible and can be customized a number of different ways using Java. When attempting to architect a new generation framework, most users start with an existing artifact set that they need to modify in some way, allowing them to leverage existing templates and save a lot of time. For example, users wanting to generate Spring-based web applications could start with one of Skyway’s artifact sets (productized in our open source and commercial versions of Skyway Builder) and then customize the Skyway templates to meet their own specific needs.

For users choosing to modify an existing artifact set, there are 4 common ways to do it within Skyway Builder:

• Adding, removing or overriding an artifact definition
• Adding or overriding an emitter
• Adding or overriding an invalidator
• Scaffolding

My next few blog posts will go into each one of these 4 approaches in more detail.

It is also possible, however, to create a completely new artifact set and couple it with your own facet. If you choose to create your own artifact set from scratch, you would create your own Eclipse facet and link it to the new artifact definitions that you create. You could choose to use the existing Skyway application model (in EMF), or you could create your own backing model. If you use our application model, you could continue to leverage our user interface, and even if you choose to create your own artifact set, you can still benefit from many existing Skyway components for generation, merging and beautification.

Summary

Look for more blog posts on Skyway’s extension architecture and our capabilities for customizing the code generation process over the next few weeks. In the interim, you can check out and download the Skyway Builder open-source project 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. Read the rest of this entry »