Call GWT RPC service from Java client

[Greg Brown]

Hi all,

I would like to call a GWT RPC service from a Java client. I haven't
been able to find any concrete examples of how I might do this, but I
can think of 2 possible approaches:

1) Use the Java classes that GWT uses in hosted mode to communicate
with the service. This seems likely to work and would require minimal
effort. However, the GWT JARs are not highly modularized, and it is
not clear where the required classes live. As a result, my Java client
would need all of the GWT JARs in its classpath, which is not optimal.

2) Write a custom Java library to communicate with the service. This
would obviously require more development effort, but it would result
in a thinner client. However, I'm not sure how feasible it is, since I
haven't found any documentation on the actual wire protocol used by
GWT.

Has anyone else looked into this? Are there other, better
alternatives?

Thanks,
Greg

[Ian Petersen]

On Fri, Jun 6, 2008 at 5:52 PM, Greg Brown <gkb...@mac.com> wrote:
> 1) Use the Java classes that GWT uses in hosted mode to communicate
> with the service. This seems likely to work and would require minimal
> effort. However, the GWT JARs are not highly modularized, and it is
> not clear where the required classes live. As a result, my Java client
> would need all of the GWT JARs in its classpath, which is not optimal.

This is highly unlikely to work unless you plan on emulating a browser
in which to run the code. The client side RPC code uses lots of JSNI
to eke the maximum performance out of the browser.

> 2) Write a custom Java library to communicate with the service. This
> would obviously require more development effort, but it would result
> in a thinner client. However, I'm not sure how feasible it is, since I
> haven't found any documentation on the actual wire protocol used by
> GWT.

This is likely to be a big pain in all relevant body parts. The GWT
RPC protocol is deliberately opaque, I think. It was designed with
the goal of getting Java objects back and forth between a GWT client
and a Java server-side with minimum fuss and maximum performance. In
fact, the client-server wire format is different from the
server-client format in order to best take advantage of the
peculiarities of each situation.

Also, the RPC wire format is likely to change in 1.6 (I say, as
someone with no actual control over the feature list of any release)
because the current implementation is susceptible to slow script
warnings. Tracking a deliberately undocumented wire format is likely
to be a pain.

> Has anyone else looked into this? Are there other, better
> alternatives?

I'd suggest using some other method of serializing object graphs onto
the wire, and using a shim on the server side that deserializes the
request, calls into your service implementation (it is necessarily a
public method on an arbitrary class), and then serializes the result
back onto the wire in a format that is convenient for you. Since
you'd be talking JVM-to-JVM, I'd put money down saying that the
easiest way to serialize things would be using Java's built-in
serialization.

If that suggestion doesn't work because you want the Java client to
talk to the server using some sort of Foo-over-HTTP protocol, then I'd
still suggest writing your own shim but instead of using Java-native
serialization over sockets, or something, I'd use a RESTful interface
behind a set of URLs distinct from the URL through which you expose
your GWT service. I'd choose a RESTful interface because I believe
the hype that REST is the best way to scale Foo-over-HTTP
communication to "web scale". Feel free to choose your own value of
Foo.

Ian

[Greg Brown]

Hi Ian,

Thanks for the response. Some comments below.

> > 1) Use the Java classes that GWT uses in hosted mode to communicate
> > with the service.

> This is highly unlikely to work unless you plan on emulating a browser
> in which to run the code.  The client side RPC code uses lots of JSNI
> to eke the maximum performance out of the browser.

I'm speculating that the RPC client runs in Java when in hosted mode
and JS when in compiled mode. If that is correct, it is theoretically
possible to use the Java classes in my app. However, even if it does
work, it's heavy and therefore not ideal.

> > 2) Write a custom Java library to communicate with the service.
>

> This is likely to be a big pain in all relevant body parts.  The GWT

> RPC protocol is deliberately opaque, I think.  ...  In

> fact, the client-server wire format is different from the
> server-client format in order to best take advantage of the
> peculiarities of each situation.

This is interesting, and not really surprising, based on the
architecture of GWT in general.

> Also, the RPC wire format is likely to change in 1.6 ...

> because the current implementation is susceptible to slow script
> warnings.  Tracking a deliberately undocumented wire format is likely
> to be a pain.

Agreed.

Re: the suggestion to use Java serialization - as you guessed, I would
prefer to use a protocol that works over HTTP. REST is certainly a
viable alternative. However, I am currently working on a project that
may use GWT RPC and I am essentially trying to evaluate what that
means for future scalability. If the protocol is indeed closed (as it
seems to be), REST does seem like a better choice.

Thanks for your help,
Greg

[Antonio Leonforte]

Hi Greg,
I do have the same need you have (in my case I wanted a java client
for testing purposes), and I have already opened a thread on the same
topic.You might want to go through the answers I got in that case (no
easy or silver-bullet solution anyway).

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/62a0546892b5c706/f6de01781e788ee2?hl=en&lnk=gst&q=leonforte#f6de01781e788ee2

Hope this helps.
Antonio.