Monday, August 10, 2009


Continued from TableMgr - List Spreadsheets

GWT is an ingenious way of allowing browser behaviour to be coded in Java source code, which the GWT compiler then compiles into Javascript.

GWT could allow the programmer to escape from Java into writing Javascript using the Java native method declaration. As far as GWT is concerned, Javascript is the native code of the browser - even though to the operating system, that is far from the truth.

Bear in mind not to confuse the Java source code for the browser with the Java source code running on the web application server. The Java source code for the browser is compiled into Javascript, whereas the Java source code on the server is compiled into Java bytecode. Of course, the server code need not be coded in Java, as long as it provides the GET-able URLs that a GWT client page requests.

GWT RPC allows a page to request for content from its server using the established HTTP channel. The GWT Java source (before compilation to Javascript) mimics a remote procedure call. However, the RPC is actually translated into normal HTTP requests/responses. Perhaps, just as many protocols ride on HTTP, we could call this RPC over HTTP. XYZ over HTTP is a common strategy programmers use to allow information to mimic web pages, to circumvent restrictions placed by internet traffic policing devices on non-HTTP communication.

Second Level Domain Same Origin Policy (SLD-SOP)
Bear in mind that the standard browser restricts its pages to only be able to request for, and to include, content from within the same second-level domain (SLD) as the server that provided that page to the browser. Top level domains (and top-level and a half) are such as .com, .org, .net, or So, domain names such as,, are second level domains. While, would be a third-level domain. Therefore, GWT RPC would work only within the confines of an SLD.

Note that SLD-SOP also requires the port number to be the same, such that is not on the same SLD as A particular browser brand may be lax and allows different port numbers within the same SLD consideration, but that would not be compliant to standard SLD restrictions.

GWT client-side code
The Java source of the GWT client intending to conduct RPC with its server must provide its own service declaration interface,
  • which has a @RemoteServiceRelativePath directive to tell the GWT compiler the URL that would service its RPC request.
  • which declares the remote service method to tell the GWT RPC class the datatype of the request argument and the expected return datatype. Surely, you need to pass arguments when you call a procedure and expect an object to to be returned. The datatype of the argument and the return signature and all their recursive members must implement the serializable interface (of course, or expect a nonserializable run-time error when the RPC process attempts to serialize those data).
  • where the remote service method is to be invoked on the client-side GWT code to trigger the RPC.
  • where the name of remote service method corresponds to the name of the remote method/procedure that GWT RPC would pass to the server to invoke to service this call.
  • which must implement the interface, which is an empty, marker interface.
The service declaration interface is a bridging interface between the client and the server as it is used by both the client and server sides. It is to be implemented and invoked by the GWT class used for performing the RPC on the client side as well as implemented and invoked by the servicing servlet on the server side.

The GWT client source code must also provide an async-response request interface for the GWT compiler. This interface should declare a method with two arguments
  • the serializable datatype declared in the service declaration interface, to tell the GWT compiler constructing this whole setup the datatype of the request argument and the datatype of the object to be returned by the RPC service.
  • the call-back method of the client that would asynchronously handle the server response. The call-back method must implement the interface.

The server-side code
The URL on the server-side targeted by the GWT RPC client must, of course, be able to recognise the request parameters. How else would it be best but for the servlet to implement service declaration interface provided by the client. For a server that implements JEE standards - that is obvious. However, if the responder on the server is not written in Java - it would have to mimic the serialization of Java datatype declared in that interface. Since this is not a hitch hiker's guide to PHP, Python or Perl, etc, non-JEE responders are beyond the scope of discussion.

Remember that the service declaration interface defined the remote service method which your server is "supposed to" use to service the RPC request. You could write your own RPC request handler servlet by ignoring the service declaration interface as well as the remote service method name it declares but service the request any old how. Your handler servlet would still need to deserialize the RPC request parameters.

If you are coding server-side in Java, GWT provides the server-side request handler as well, RemoteServiceServlet, to
  • call the method as requested by the GWT client. The method must implement service declaration interface which you have declared for the client.
  • deserialize the data, that came with the request, back into a Java object, and pass the object to the requested method.
  • serialize the return type of the method to be sent back to the GWT client.
Which is a lot of work not to write your server side in Java.

Naturally, your handler servlet would need to be mapped to the URL on which the GWT client has sent a GET request, as registered in the @RemoteServiceRelativePath directive of service declaration interface.

To use the GWT framework, your servlet needs to extend

Continue next Passing Parameters in GWT RPC (Client-side)

No comments:

Post a Comment