GWT Going Mobile and Beyond

At Google IO 2013, Google made it clear what the future of GWT is. The future is quite bright for GWT given the roadmap that Google and community have rolled out. The next major release will include full support for Java 7 & 8 and support for mobile browsers with a new set of mobile optimized widgets. Google is also opening up the process for how GWT will be developed and governed moving forward. It will now be community driven which is great news for the future of open source GWT.

There is no perfect framework for building web apps, but GWT is one of the best if you want a highly structured Java environment and high productivity with a larger team and a potentially large code base. The fact that GWT is based on Java gives it great tooling out of the box and a well understood design methodology and patterns for building client and server code that Java developers are already accustomed to. You have clearly understood concepts like MVP for building rich and complex apps and all the power of Java to build and organize your code. Something most javascript frameworks don't have.

I am a fan of many of the popular javascript frameworks out there for building web apps. jQuery, backbone.js, underscore.js, require.js, knockout.js and AngularJS (just to mention a few) are nice frameworks and give you a lot of expressiveness as a javascript/web developer to build pretty cool stuff from large single page apps to multi-page oriented apps. The problem is this begins to breakdown as the apps and code base get bigger and as the team gets bigger. Have you ever tried to reverse engineer code in javascript or pickup someone else's code? Sure if you have javascript guru's on your team, you are probably in good shape, but javascript programming by its nature is loosely structured and leaves a lot to the developer to define (which can be good and bad depending on your perspective). But on larger teams and with less experienced developers, this can be a challenge.

Again, there are dozens of javascript/html5 type frameworks out there (and new ones coming out each year) and what you choose really depends on how adventurous you want to be with web development. GWT gives you a highly structured environment and programming language to build browser based apps. And now with GWT being community driven and with much clearer support for GWT by Google, the future looks quite bright for GWT and Java developers. I am looking forward to building GWT apps for mobile as I think this is one area (along with gwt-phonegap) that GWT will excel in.

Also checkout soafaces, a cool GWT powered open source framework that allows you to build component based GWT web apps. It includes cool features like an on-the-fly GWT compiler (kind of like JSP to Servlet compiling), so your GWT apps can be dynamically compiled to javascript by the hosting container. SOAFaces also makes it easy to bundle and organize your GWT apps into components and optionally communicate with SOA and Mule type endpoint services.

soafaces Powers up Hadoop

soafaces has always been a very flexible open source toolkit for building GWT clients and server components. Now with the release of v2.6.0, soafaces enables easier integration and management with third party systems like Hadoop by adding key features needed to manage remotely running processes.

Running and tracking Hadoop jobs takes a little extra effort in order to seamlessly integrate with a remote Hadoop environment. With release 2.6.0, it is now easier to compose, launch, and track Hadoop jobs remotely. This brings the full power of JobServer and soafaces to hadoop users. Hadoop users now can schedule their jobs and track them all the way through execution using a set of web based interfaces that provide role/user management, security and audit trail reporting among many other features.

One very nice feature with using soafaces and JobServer, is that you can chain multiple Hadoop jobs together and send the results of one Hadoop job into the input of another Hadoop job. You can transfer files and content in out and out of HDFS and orchestrate and chain of Hadoop jobs to complete a Hadoop workflow.

Release 2.6.0 includes some key new features like application and runtime scope cookies that let a Tasklet manage state between job runs enabling better coordination with third party systems like Hadoop.

This release also includes two built in soafaces components that let you report on your Hadoop environment and launch and track any Hadoop job. These components are bundled with the other BeanSoup components that come as part of the sample components with soafaces.

With these components, you can build and customize your own GWT GUI interfaces for each Hadoop job you have. soafaces provides a standard component/Tasklet you can you use out of the box to run your custom Hadoop jobs. And you can tailor the code with your own custom logic to provide specialized GWT reporting for each unique Hadoop job, for example.

To get started using soafaces, download JobServer and start managing your Big Data from the comfort of your JobServer Workbench.

GWT UniversalClient - "Look Mom no RPC!"

GWT has enabled a more OO style programming again within the web application world (yea there are some that will say that is bad for the web). For fans of Swing type component frameworks and other similar GUI frameworks, GWT is a great welcome.

But with this style of programming, you go back to sepearting the client from the server more clearly. This is both good and bad. The good is that you can do a lot more things with the client now (AJAX stuff) but the bad is that you have a demarcation line between where the client code ends and server side code starts which requires developers to write and stub out RPC classes and interfaces. With server side web progamming everything is sort of mixed together so developers don't worry about where the resource is because most of the time the code is running on the server to begin work.

Anyway, with GWT you got to write RPC code. Not the hardest thing in the world to do, but it can be a bit of a pain. Well here comes SOAFaces framework to the rescue with its UnverisalClient. The UniversalClient is a bit like the MuleClient you find in the Mule ESB project. It can talk to just about any servier side method or services and pass and return arguments when invoking said services. The UniveralClient allows GWT developers to write their client code and call out to remote services with out much less hassle. The UniversalClient interface can invoke just about any standard Java POJO method or Mule/ESB service and return the results without writing a line of GWT RPC code. If the ESB web service already exist then just call it and if you want to create your own simply attach an annotation to any service side POJO and now it is available to be called from your GWT client (again no RPC or marshelling to deal with). And it is your choice wether to pass and return JOSN or POJO objects back and forth.

Here is an code example of what a simple GWT client would look like that uses the UniversalClient API to invoke a very simple service on the server side. This is of course a simple example but you can also use the UniversalClient to invoke Mule endpoints as well.

public class UCDemo implements EntryPoint {

  private static final String UNIVERSAL_CLIENT_SERVLET = "/mywebapp/SOAFacesRPCServlet";
  private UniversalClient _oClient;

  private Button button;

  /**
   * Simple entry point and use call to UniversalClient.
   */
  public void onModuleLoad() {
    button = new Button("Click To Execute Service Call");

    DockPanel dockPanel = new DockPanel();
    dockPanel.add(button, DockPanel.WEST);
    RootPanel.get().add(dockPanel);

    button.addClickListener(new ClickListener() {
      public void onClick(Widget btn) {

        //Format endpoint is: soafaces://<fully qualified class name>/<annotation method name>
        String stEndpoint1 = "soafaces://com.acme.service.HelloWorldService/helloThereEndpoint";
        if (btn.equals(button)) {

          //Create the UniversalClient Async Callback
          UniversalClientPOJOCallback oMulePOJOCallback = new UniversalClientPOJOCallback() {

            public void onUniversalClientSuccess(Object result) {
              //Serivces returns a String
              String returnVal = (String) result;
              Window.alert("Wow this was a success! Return value: " + returnVal);
            }

            public void onFailure(Throwable ex) {
              Window.alert("Error during UniversalClient call: " + ex.getMessage());
            }
          };

          //Simply use the UniversalClient send method to call the remote service
          //This service endpoint takes no arguments and returns a String
          getUniversalClient().send(stEndpoint1, oMuleJSONCallback);
        }
      }
    });
  }
      
  private UniversalClient getUniversalClient() {
    if(_oClient == null) {
      _oClient = UniversalClientFactory.getInstance().getUniversalClient(UNIVERSAL_CLIENT_SERVLET);
    }
    return _oClient;
  }
}

Here is what the server side code looks like. This is the service endpoint referenced by the client above. As you can see very simple. Just a POJO with an annotation marker. This allows the UnviversalClient to invoke this service and return the results.

public class HelloWorldService {

  @ServiceEndpoint(name="helloThereEndpoint")
  public String helloThere() {
    return "You got it";
  }
}

Javadocs for UniversalClient:

http://www.grandlogic.com/downloads_content/soafaces-javadoc/index.html

If you would like see more, download the sample WAR that demostrates the UniversalClient in action:

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

This link will give you details on building your own GWT client using the UniversalClient interface:

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

You can read more about the SOAFaces and the UniversalClient open sources project here:

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

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.