Thursday, October 9, 2008

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/

Sunday, July 27, 2008

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.

Saturday, July 26, 2008

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.