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…

A few months ago I did a series of posts related to GWT, and in the posts I covered the creation of a Google Web Toolkit (GWT) application that uses Javascript/JSON services provide by the new Direct Web Remoting (DWR) generation feature [Video] of Skyway Builder 6.3.  The feedback to the DWR feature has been excellent.  Since Skyway Builder takes care of generating all the DWR configuration, AJAX developers are able to focus their efforts on development of the front-end.  While the DWR generation feature was the star of the series, writing the blog posts really sparked my interest in GWT.  As I investigated GWT further and experimented with other GWT development projects, I decided that I needed to revisit the integration between the GWT front-end and Spring-based back-end application.  With the help of others I came up with an implementation that I think is better than the DWR approach.  I also found that the implementation could be expedited using code generation, and I built a GWT extension to Skyway Builder that handles most of the work.  In the next few blog posts I will describe the GWT-Spring integration strategy and the implementation of the experimental Skyway Builder extension for GWT development.  At the end of the series I will provide a download link for the GWT extension for Skyway Builder.

Before I dive into the new GWT-Spring integration strategy let me point out that the Javascript/JSON approach described in the original posts is still perfectly valid.  I have talked to other GWT developers, and there is nothing wrong with the original approach.  As a matter fact using Javascript/JSON is highly recommended for scenarios where the back-end is not Java based.  However if you happened to be using Java back-end (like I do), GWT provides an RPC mechanism using Java servlets.  The primary benefit of GWT RPC is that the developer doesn’t need to worry about serialization/deserialization of data, and the GWT compiler has the opportunity to optimize the client-side RPC logic.

Let me take a moment to describe my ideal development scenario in regards to GWT and my Spring back-end.  Web applications are typically organized into layers, and the most common layers are web, service, domain and DAO.  If I’m developing an HTML application (traditional or light AJAX), then the web layer consists of my JSP pages and controllers, which call the application logic contained in the service layer.  I consider a GWT client to be an alternative to JSP pages and controllers in the web layer, and the GWT client should be able to leverage the same application logic in the service layer.  In the GWT/DWR blog post series the Spring DSL Services were DWR-enabled, making the respective Spring @Services accessible to clients via javascript and JSON.  I expect the GWT RPC mechanism to be structured in the same manner, and ideally the Spring @Services will be accessible as GWT RPC services.

While GWT RPC provides an RPC mechanism, there was still some work to be done to get it to talk to my Spring Services.  Not wanting to reinvent the wheel, I did some investigating on how others solved this problem, and I found the Spring4GWT project.  What Spring4GWT basically does is to make it easy to expose Spring @Services as GWT RPC services.  The @Services generated by the Spring DSL are already in excellent shape to use with Spring4GWT.  There were only two additional requirements to use Spring4GWT.  First of all I needed to register the Spring4GWT servlet for handling GWT RPC requests, and I also needed to modify the service interface to support GWT callbacks (AsyncCallback).  While these requirements are easy enough to do manually, the GWT extension for Skyway Builder will handle this (plus a few other things) automatically for you.  Automating this allows me to just focus on the services themselves, without being bothered by keeping the interfaces and Junit tests in sync.

What’s really cool about this is that when I combine the capabilities of the GWT extension with the Spring scaffolding capabilities of Skyway Builder, I can go from a database table (or set of tables) or domain object(s) to a fully implemented Service layer with GWT RPC support in less than a minute.  Furthermore if I enable the DWR and JAX-WS checkboxes, I have a scaffolded service layer that’s accessible using Java, Spring DI, GWT RPC, DWR and JAX-WS in less than 2 minutes.  However I digress.

My perspective may be uncommon, but I always look at development from the perspective of code generation.  While generating GWT RPC ready back-end Spring applications definitely accelerates GWT development, I found many other opportunities for GWT code generation that can further accelerate GWT development.  In this series of blog posts I will describe and share one of the additional GWT code generation functions, and this function is applicable to all GWT development….not just GWT development that’s using Spring back-ends.

While exploring GWT development I have been studying up a bit on  best practices on GWT development.  There’s an excellent presentation (Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App) by Ray Ryan from Google that was very educational.  It’s a very worthwhile presentation, and I encourage all GWT developers to watch it at least once.  One of the recommendations of the presentation was to use an event bus.  Event buses are very interesting.  While it take a little bit more time to get it set up intially, I find event buses save a lot of time in the long run…and makes development much easier by decoupling GWT artifacts.  I adopted an EventBus implementation call GWT-EB.  While it worked very well, I found that creating events was a bit tedious.  Except for the event payload (the data that travels with the event), the implementation of events is mostly boilerplate code.  This seemed to me like a great opportunity for code generation.  So I added a code generation function to the GWT extension for Skyway Builder to generate the GWT Events.  With the GWT extension, creating events is now just a matter of giving it a name and specifying the payload (if applicable).  The GWT extension for Skyway Builder will generate the GWT events.

In the next few blog posts I will describe the development, installation and use of the GWT extension for Skyway Builder.  In addition to providing some GWT code generation that can be immediately used for GWT application development, it will serve as a good case study for extending the code generation features of Skyway Builder.

Stay tuned.

Update: Part 2 can be found here.