GWT Weblets and On-The-Fly Compiling

GWT has been out for a while now and has proven to be a good platform for building web applications. One of the keys to GWT's success is the way it translates java into javascript and provides developers with an all java environment to work in.

But there is a limitation (what doesn't). Translating java into javascript is cool, but this can be a problem for dynamic environments. Unlike JSPs for example, GWT can't be compiled on the fly by Tomcat. Basically you always have to distribute the javascript. This is perfectly fine for distributing monolithic applications but this is not acceptable for dynamic and "pluggable" environments where you want to distribute only the java byte code jars (and client source in the case of GWT).

What GWT needs is a plugin model, maybe something similar to the way java servlets work but to have them be client centric. An example of this is a project called SOAFaces. It allows for the packaging of GWT applications into plugin modules called Weblets. These are pure GWT components that can be deployed and linked dynamically in a server environment and accessed by the client. A Weblet has a simple GWT API and a simple packaging specification for putting the Weblets into a JAR that can be distributed to any container that supports Weblets.

It is then the responsibility of the Container to compile the GWT component into javascript (sort of like how a j2ee container can compile a JSP page into java byte code).

Well as you may have guessed, the SOAFaces framework facilitates this capability. In general it would be good for the GWT community to start thinking about components and how to package, share, and deploy them in dynamic environments.

For an example of something that already supports the SOAFaces specification check out the product JobServer. JobServer supports the concept of hot deploying of Weblets and compiling GWT on the fly. JobServer provides and integrated job scheduling environment and support for Mule and SOA.

Bundles of Joy

Bundles are popular again! Well, maybe not again, but there is a lot of talk about bundles and in general how to bring a better modularity and a plugin system to Java. OSGi has been a driving force, and the future is looking brighter again for Java to have a component strategy (holding breath).

Enter SOAFaces. I do not claim that SOAFaces supports the OSGi specification (it does not - at least not yet), but SOAFaces provides what we believe to be an extensible way of building Java components for both web clients (yes AJAX and all that cool RIA stuff) and for server components (SOA hype and beyond).

The concept is called an SFB (SoaFaces Bundle). The SOAFaces specification provides a modular way of packaging server and client side code into a single "bundle" that can then be deployed into a web container (or any other container) and run. It is self contained in that it "can" contain all the JARs it needs while being able to work with other SFBs in a container. This is what an SFB is more or less. Well what does it do? Of course it can do anything you like, within reason of course :)

SFBs have three parts to them. The first is a GUI API (called Weblets) that supports the Google Web Toolkit (GWT) for building cool AJAX web applications and components. The second is a SOA API that allows the GWT client to communicate with the web server and ESBs using a very simple API (as simple as GWT will allow) where you do not have to write all that nasty RPC plumbing code. With this SOA API (people seem to get bent out of shape when I use the term SOA API - but tough) you can have the GWT client make SOA requests to Mule and other non mule services endpoints (and again no RPC code to write - sorry if I am repeating myself). And you can do this by passing either JSON or POJO objects back and forth.

The third leg of an SFB (BTW all the legs are optional), is the workflow part. Yes you can use SFBs to build workflows as well! I am sure by now some of you are saying these guys are crazy, but no it is actually simple and fits as the third leg of the puzzle (did I say optional) quite easily. SFB tasklets, as they are affectionately called, allow for building modular workflows. Tasklets can be composed together to form chains and can even easily pass properties to each other so they can work together with no prior knowledge of each other. And their configuration can all be GUI driven if your SOAFaces container can handle it.

Anyway, there is a bit more, but I will not bore you with rest (assuming you stuck around this long). If you would like to hear more check out the SOAFaces project on:

http://code.google.com/p/soafaces/

There is some sample code, javadocs...etc and a WAR file that you can try out for yourself. BTW, you can also use SOAFaces without using the full SFB component concept, so that means you can use the API to make SOA requests in plain old GWT applications and deploy the SOA part of the SOAFaces to any old GWT and web server application you have that needs a SOA jolt (sorry for saying SOA so many times).

Also, if you want to see SOAFaces, in their full glory, running in a commercial product check out JobServer by Grand Logic. Cool product (does scheduling, mule integration and other fun stuff) but I am a little biased so I will stop here.