Join us for a free webinar on Tuesday, August 31, 2010 at 11:00 AM – 12:00 PM CDT

This webinar deep dives into the new Adobe Flex and Google Web Toolkit (GWT) scaffolding options that are available in MyEclipse for Spring 8.6. We’ll cover the following:

– How does it work? See how to quickly generate working GWT and Flex applications from existing DB tables, Java Beans and JPA entities in a matter of minutes.
– What gets generated? One of the biggest learning curves is understanding what gets generated – we’ll do a deep dive into the generated artifacts to help users understand what exactly comes out of MyEclipse for Spring.
– How does it compare to other GWT/Flex scaffolding technologies?

Reserve your seat at https://www2.gotomeeting.com/register/691323002

Register for this webinar if you want to see how MyEclipse for Spring (ME4S) is delivering unprecedented Rich Internet Application scaffolding options to the Spring Community.

For developers who are looking to learn new technologies like Flex or GWT, MyEclipse for Spring 8.6 allows them to quickly create their own contextual examples that they can then reference while getting up to speed on the new technology. Meanwhile, developers who are experts in these technologies can stop worrying about the boilerplate code, and let MyEclipse for Spring take care of all the mundane, repetitive tasks.

Bonus Offer: All webinar registrants will receive a 30% discount off of MyEclipse for Spring – just for registering! Visit https://www2.gotomeeting.com/register/691323002 to register and get your coupon code today!

When we hear the term application modernization, the immediate image that comes to mind involves modernizing twenty-five year old critical business applications written in COBOL. While this is still true and represents the bulk of work in this field, there are other growing areas of application modernization that businesses undertake. These include migrating more recent heavy-weight legacy applications based on technologies like JEE and Oracle Forms to the newer light-weight Spring Framework. Another emerging modernization area involves moving from older web user interface technologies like JSP to newer more robust technologies like Spring Web Flow, Adobe Flex, and Google Web Toolkit (GWT). Modernization also involves updating the web layer to support mobile devices like the iPhone. Regardless of the application modernization area, MyEclipse for Spring provides tooling to support a rapid migration strategy.

Modernizing Existing Legacy Systems

COBOL Systems

Interestingly, reading through the plethora of online technology sites, it’s easy to get the impression that today’s information systems are almost all web applications using Java or .Net on the back-end. The reality, of course, is that the bulk of critical business applications remain in the world of COBOL – and there are no signs those systems are going to change dramatically in the near term. What is changing with an elevated sense of urgency, however, is the recognition that businesses need to define an application modernization plan that preserves and renovates their critical business processes while at the same time reducing the operating and maintenance cost of their aging existing systems.

From a high level perspective, the plan involves starting with an “as is” analysis of the current system – e.g., understand the complexity, structure, business rules, nature, and intended use of what is typically a loosely understood and largely undocumented system. The next major step involves defining the path for the “to be” system. In most cases, the modernization migration path involves a practical incremental approach. In this incremental approach, we start by defining, publishing, and using key business functionality from the existing system through web services. Then, we develop individual functional areas with Java/Spring and migrate the application in functional blocks in a timeframe that the business and technical teams can handle.

Oracle Forms Systems

The process for migrating from an Oracle Forms system to a Spring Framework system will be similar to the COBOL legacy system migration strategy. However, the migration effort should be easier due to a probability that the system software will be understood for the most part and has documentation. The functional areas may be a little tricky to separate as Oracle Forms relies heavily on PL-SQL for implementing business and validation logic. For Oracle Forms, the web services will usually be thin wrappers that call the PL-SQL stored procedures.

JEE Systems

The process for migrating from a JEE system to a Spring Framework system will be similar to the COBOL legacy system migration strategy. However, the migration effort should be easier due to a probability that the system is understood for the most part and has documentation. Also, the developers will already understand Java.

Using MyEclipse for Spring in the Migration Plan

MyEclipse for Spring provides tooling to accelerate the “to be” migration strategy – for both scaffolding the web layer and using the web services to access the existing legacy system, as well as, developing the functional areas for migration to Java/Spring solution.

Incremental Migration – Using Web Services

After web services are defined and exposed, we use the WSDL import capability of MyEclipse for Spring to quickly generate the Spring and JAX-WS infrastructure to support calling the web services. Once the web service infrastructure is generated, we use the MyEclipse for Spring scaffold capability to quickly scaffold any of a variety of web layer implementations (e.g., Spring MVC, Spring Web Flow, Adobe Flex, GWT, and iPhone) for any of the Java Beans created during the WSDL import process.

Incremental Migration – Developing Spring Services

Another feature of the WSDL import process is the generation of “contract-first” Java package shells. When the WSDL import process completes, we have code shells for Spring Services and JUnit test classes that would be implemented and tested by Java developers. MyEclipse for Spring also includes code assistants to help developers create and maintain Spring annotations for their Spring Services. Once the code is completed and the business is ready, only one line of code needs to change to switch from using the web service provided by the existing legacy system to the new Spring Service.

Modernizing the User Interface

For the desktop

This area of modernization has become more popular as we see robust RIA solutions mature in the marketplace (e.g., Adobe Flex, Spring Web Flow, Google Web Toolkit, etc.). MyEclipse for Spring simplifies this modernization process through its scaffolding capabilities. Starting from a variety of sources including data schemas, JPA entities, and Java Beans, developers scaffold the web layer with the new user interface technology. From there, developers use the scaffold as either a starting point for building the complete user interface against the back-end or as a reference implementation template for coding the user interface with the chosen technology.

MyEclipse for Spring Scaffolding Wizard

For mobile devices

Similar to its help for desktop web applications, MyEclipse for Spring simplifies modernization process for the iPhone through its scaffolding capabilities and for other mobile devices with small changes to context files and style sheets. Again, developers use the scaffold as either a starting point for building the complete user interface against the back-end or as a reference implementation template for coding the user interface with the chosen technology

iPhone Scaffolding with MyEclipse for Spring

Try it Yourself

MyEclipse for Spring is available for a free, 30-day trial. Accelerate your application modernization process by downloading from http://www.myeclipseide.com/module-htmlpages-display-pid-4.html.

One of the masterminds behind the GWT+Spring scaffolding support in MyEclipse for Spring wrote this article that describes the design philosophy and the GWT application architecture. The article includes some great sample Java/GWT code and a great explanation of how all the pieces fit together. As it turns out, it’s not magic after all.

Read the full article at http://www.dzone.com/links/r/gwt_and_spring_its_not_magic_after_all.html

And, if you want to see our GWT scaffolding in action, join us on August 31st for a free webinar.

One of the new web client scaffolding options in MyEclipse for Spring 8.6 (ME4S) is Adobe Flex.  If I had to summarize the capability in one sentence it would go something like:  ME4S 8.6 generates ready-to-run Spring-Flex BlazeDS Hibernate applications using the RemoteObject to communicate with Spring Services that support create, read, update and delete operations for related objects.

Of course, there is so much more… to read about in the full blog post at http://www.genuitec.com/blog/?p=1467

Genuitec, LLC, a founding and strategic member of the Eclipse Foundation, and Skyway Software, an expert Spring development solutions company and SpringSource Certified Solution Partner, today announced the production release of a new environment, MyEclipse for Spring.  The jointly-developed product delivers a set of advanced accelerators for Spring development, including scaffolding, project bootstrapping and enhanced development editors.

“Our goal was to give millions of valued users a full-featured, intuitive Spring development solution,” said Todd Williams, vice president of technology for Genuitec.  “With the production release of MyEclipse for Spring, we feel that we have achieved that goal.  Developers who are using Spring-based tools to create Web applications now have access to some of the industry’s most advanced development accelerators.”

Read the full press release here.  Download the free 30-day trial of MyEclipse for Spring here.

During the MyEclipse for Spring webinar (replay is here), we received a lot of great questions from the webinar participants.  Although we attempted to respond directly to all of the questions raised during the webinar, unfortunately, we ran out of time and couldn’t respond to all of them.  In this blog post, I would like to address some of the questions that we didn’t get to answer and share some of the questions/answers that I think would be interesting to Spring developers.

Read the full list of questions and answers here.

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:

Update 7/9/2010 – MyEclipse for Spring 8.6 now generates full ready-to-run GWT applications based on MVP and UI Binder in minutes.  Just point the scaffolding wizard at your database tables, Java beans, or JPA Entities.  You can learn more about it from the Generating Enterprise Class GWT applications for Spring post that I wrote on Genuitec blog.  Or, you can keep reading my original post…

This blog post is the last post of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In part three I describe the actual implementation of the Spring DSL extension, and in this post I will describe how to download, install, and use the extension.

The GWT extension for Skyway Builder is implemented as an Eclipse plugin.  As such it needs to be installed as an Eclipse plugin.  In the future I may create an update site, but for now you can download the plugin (com.skyway.experimental.integration.gwt_1.0.0.jar) and copy it into the plugin folder for Eclipse.  Just as a reminder this plugin is dependent on having Eclipse 3.4.2 plus Skyway Builder 6.3 (Standard Edition).  If you don’t have Skyway Builder Standard Edition, you can get a copy from here.

When you restart Eclipe the GWT extension for Skyway Builder is ready to go.  For any Spring DSL Services or Components that you have defined in any projects, Skyway Builder will start generating slightly updated or new artifacts (see post two for details).

Here’s an important consideration.  This experimental plugin was designed to toggle the generation of GWT artifacts (using the Code Generation tab), and by default the generation is turned on.  This means that it will affect all Services.  If you have any existing projects that you don’t want to be affected by the GWT extension, you will need to disable the generation of the GWT artifacts by unchecking the GWT entries from the Code Generation tab of the Spring DSL.

A better solution is to add an attribute to the definition of the service that will allow me to specify the Service should be GWT enabled.  That’s exactly the approach taken by the DWR and JAX-WS features in Skyway Builder.  When you check “Publish DWR” or “Publish Web Service” checkboxes, the service will be generated accordingly.  Perhaps I’ll tackle that in a future version of the plugin.

Here’s an example of using the new plugins.  I followed the instructions from a previous blog post (GWT and Spring: Setup of development environment and Create GWT project).  The only difference is that this time I’m using GWT 2.0 instead of GWT 1.7, and I also added the spring4gwt library to my project.  Before I start doing any code generation with Skyway Builder, I want to quickly configure the Spring DSL to generate the correctly generate the new artifacts.

The Code Generation tab of the Spring DSL is used to define the code generation defaults for the project.  You will notice there are some new code generation entries that are contributed by the new plugin.  The first step is to disable “Service Interface” generation.  I recommend sorting the table by Categories in order to see all the Service entries grouped together.  The next step is to configure the “Service Interface“, “GWT Service Interface“, and “GWT Service Async” entries with a different package.  By default they are set to ${model.package}, which means that the artifact will be generated to a java package corresponding to the model package of the Service.  However for GWT we want the interfaces generated into their own package, so we are appending “.interfaces” to the end of the package.  I won’t go into all the details why this needs to be done for GWT, but suffice it to say that it’s a GWT best practice to isolate client-side and server-side Java code so that the GWT compiler will only compiling relevant Java code (source path) to javascript.

To see the GWT extension for Skyway Builder in operation, you can create Spring DSL services by hand or you can quickly scaffold a Spring MVC application.  For this blog post I scaffolded from a domain object.  See step 9 from GWT and Spring (Part 2) – Scaffold Spring back-end for GWT Application for a quick explanation on how to scaffold a Spring MVC application with Skyway Builder.

In my example you can see that the ContactService (in Spring DSL) generated the implementation class, service interface, and asynchronous callback interface (for GWT).  As you add new operations to the service, all the artifacts are regenerated to reflect the changes.

As far as events are concerned, you can just create a model package whose corresponding java package will be listed as a source path in GWT application, which will result in it being compiled into javascript.

This concludes my series.  My hope is that I provided an easy to understand introduction on how to extend Skyway Builder and an extension that may be usefull to GWT developers using Spring as their backend.  If you have any questions or would like me to elaborate on something, please drop me a comment here.

What’s next with this plugin? I’m glad you asked.  I would like to expand the support for GWT development in Skyway Builder.  I had started experimenting with some GWT UI scaffolding, and I’m making some good progress.  However given the new UI Binder feature in GWT 2.0, I will need to re-examine this.  If you have any ideas for enhanced GWT suppport, please let me know.

Happy New Year!!!

Update 7/9/2010 – MyEclipse for Spring 8.6 now generates full ready-to-run GWT applications based on MVP and UI Binder in minutes. Just point the scaffolding wizard at your database tables, Java beans, or JPA Entities. You can learn more about it from the Generating Enterprise Class GWT applications for Spring post that I wrote on Genuitec blog. Or, you can keep reading my original post…

This blog post is the continuation of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT, including the automated  access of Spring @Services for GWT RPC.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In this post I will describe the implementation of the Spring DSL extension in more detail.

If you don’t so much care how the GWT extension for Skyway Builder is implemented and just want to start using the extension, then you will probably just want to skip to part 4 where I will describe how to download, install, and use the extension.

Since the general steps for extending in Skyway Builder are already described on Modifying Artifact Generation in the Skyway Wiki, in the post I’m going to focus specifically on how these steps were applied to create the GWT extension.

Following the setup instructions, first of all I created a Jet Transformation project called com.skyway.experimental.integration.gwt.  I accepted all the defaults in the wizard.  Next I added required dependencies.

I’m going to use JET to implement my code generation templates.  JET templates resemble JSP in many ways, making it very easy to follow the implementation of the templates.  JET supports the concept of tags and tag libraries (just like JSP).  The JET tag library is very rich in generation functionality, but you can also use custom or 3rd party tag libraries (just like JSP).  Skyway Builder contributes a set of JET tag libraries for simplifying many of the recurring generation requirements of Spring applications.  A full reference of the Skyway JET tag library can be found here.  In regards to the GWT extension, the  Skyway JET tag library need to be added as extension.

The next step is to add the artifact definitions for the new artifacts that are going to be generated and register the template overrides for the pre-existing artifact definitions.

This diagram shows the extension entries required to accomplish the functions described in post 2, which includes:

• adding a new Service artifact definition for the GWT callback interface
• adding a new Service artifact definition for the service interface (the decision to create new artifact definition instead of overriding existing template will be described in part 4)
• overriding the JET template for generating the web deployment descriptor (web.xml)
• overriding the JET template for generating the Spring context file for the service layer
• adding a new Component artifact definition for generated GWT events

I won’t review each JET template, but the the project contains five new templates.

Here’s a summary of each template:

• generated-service-context.jet – This template is a copy of the base template and includes additional logic to direct Spring to do a component scan of all annotated Spring components.  By default the component scan is done from the web context file, but GWT front-ends talk will directly to the service layer (and bypass the web layer).  Therefore the component scan needs to be done from service layer, otherwise the dependencies of the Service layer won’t be resolved by Spring.
• gwtEvent.jet – This new template generates a GWT event Java class from a Spring DSL component.  The component name is used as the event name, and the component variables are use for generating the event payload.
• gwtServiceAsync.jet - This template is a new template that generates the GWT callback interface, which is a requirement for using GWT RPC.
• gwtServiceInterface.jet - This template is a copy of the base template and includes additional logic to emit an @RemoteServiceRelativePath annotation for each service operation.
• web.xml.jet – This template is a copy of the base template and includes additional logic to register the spring4gwt servlet and servlet mappings.

That’s it for the plugin.  The next step is to export the plugin (Export –> Deployable plug-ins and fragments).  The resulting plugin (jar file) can be installed into an Eclipse instance with Skyway Builder 6.3.  I’ll cover that in more detail in the next post (part four).

Update 7/9/2010 – MyEclipse for Spring 8.6 now generates full ready-to-run GWT applications based on MVP and UI Binder in minutes. Just point the scaffolding wizard at your database tables, Java beans, or JPA Entities. You can learn more about it from the Generating Enterprise Class GWT applications for Spring post that I wrote on Genuitec blog. Or, you can keep reading my original post…

In the previous post I introduced a new GWT extension for Skyway Builder that automatically makes Spring @Services accessible as GWT RPC services and accelerates the development of GWT events that can be used with a GWT event bus.  This blog post will provide a high-level description of the implementation of the extension, and in the next blog post I will dive into the implementation details .

I’m not going to spend a lot of time explaining how spring4gwt works.  Please refer to the project site for detailed description of spring4gwt.  There are essentially five steps for making Spring @Services accessible as GWT RPC Services using spring4gwt.

Implementation requirements for producing GWT RPC services from Spring Services:

1. Copy Spring4GWT library into project
2. Modify web application context file (web.xml) – add spring4gwt servlet and servlet mapping
3. Create a a GWT callback interface for the Spring @Service – each service operation should be reflected in callback interface
4. Modify the service interface – add import statements for GWT remote service; add @RemoteServiceRelativePath annotation; extend Remote Service
5. Modify service context file (Spring) - since GWT clients replace JSP and controllers, the component scan that is typically located in the web context file needs to be moved to the service context file, otherwise the Spring framework won’t be able to find other components that the service might be reliant upon.

Except for the new GWT callback interface, all the relevant artifacts are already generated by the Spring DSL.  The GWT extension will just need to customize the generation of these artifacts to support GWT RPC using spring4gwt.  The callback interface, on the other hand, is a new artifact, and the Spring DSL will need to be extended to generate it.

Here’s what you need to know about the Spring DSL.  The Spring DSL defines 10 abstractions, which include Project, Controller, Component, Service, Domain Object, Data Access Object, Operation, Named Query, Exception and Action.  Each Spring DSL abstraction will generate primary and secondary artifacts, and the generated artifacts are typically Java code or XML configuration files, although you really can generate anything that can be emitted with JET.

During the course of application development using the Spring DSL a developer will define instances of  Spring DSL artifacts, and Skyway Builder will generate the primary and secondary artifacts according to the configuration of the Spring DSL artifacts.

For the GWT RPC functions the two relevent Spring DSL abstractions are: Project and Service.  According to the Spring DSL there are 6 artifact definitions for a Service, and the following diagram shows the most relevant ones -plus- the new artifact definition (GWT Interface).

For the Service interface the GWT extension will override the default code generation template that’s provided by Skyway Builder, and the new template will emit code required in the service interface (see requirement #3).  For the GWT callback interface (requirement #4) the GWT extension will extend the definition of a Service by adding a new artifact definition and contributing a new code generation template.

Now that requirements 3 and 4 are out of the way, let’s proceed to requirements 2 and 5.  These requirements will be handled in a very similar manner.  The web.xml and Spring context files are generated by the Spring DSL Project abstraction.  There are a lot of artifacts generated from a Project, so the following diagram only shows the most relevant ones.

The GWT extension will override the code generation templates for web.xml and service context file.  The new templates will add the additional configurations needed to support GWT RPC.

In the grand scheme of things this exercise was pretty trivial because all the required steps are handled by the GWT extension by just overriding an existing template or contributing a new artifact definition to an existing Spring DSL element.  It’s worth noting that this is just the tip of iceberg when it comes to extending the Spring DSL.  If needed you could extend Spring DSL element to capture more metadata, which presumably would be used to drive the code generation.  You could also create entirely new Spring DSL elements with their own meta-data and code generation templates.

The implementation overview of the GWT RPC function is complete, and now we will proceed to the GWT Events function.  For this function I needed to decide whether or not I should create an entirely new Spring DSL element for Events or whether I could use a pre-existing Spring element.  For the sake of simplicity I decided to use the existing Spring DSL Component element because it already captures all the metadata that I need for generating Events.  Components have a name, which I’ll use as the event name, and components have variables, which I’ll use for defining the event payload.  Here’s the definition of a Component -plus- the new GWT event.

The process for adding support for generating GWT events from a Component is nearly identical to the process of generating the callback interface from a Service.  The GWT extension defines a new artifact definition for Spring DSL Components, and a new code generation template will be used to produce GWT events.

As you can see it was relatively simple to customize the Spring DSL, and the basic recipe described in this post can be applied to countless development scenarios.

If you are familiar with Skyway Template Projects, you may be wondering how this process is different than Skyway Template Projects.  Both let you customize the code generation templates, so why was an Spring DSL extension used instead of a Skyway Template Project.  While Spring DSL extensions and Skyway Template Projects share some functionality, you can do a lot more with the Spring DSL extensions. I already pointed out that this recipe is just the tip of the iceberg when it comes to extending the Spring DSL.  While Template Projects let you customize the templates, they don’t let you add new artifact definitions (which was one of the requirements of the GWT integration), extend the Spring DSL with additional metadata, or define entirely new Spring DSL abstractions.  If you are only interested in overriding pre-existing code generation templates for pre-existing Spring DSL abstrations, then the Skyway Template Project is your best bet.  However Skyway Template Projects weren’t adequate for the GWT-RPC or GWT events requirements.

In the next post I will describe the implementation of the extension in more detail.