Using gwt-rpc-plus with RESTful services

21 views
Skip to first unread message

Philippe Laflamme

unread,
May 11, 2010, 10:04:55 AM5/11/10
to DotSpots Open Source
Hi all,

I've been playing with gwt-rpc-plus for a few days now and I'm at a
point where I need some clarifications. Please forgive any stupid
question! I'm wondering whether my use-case is a valid one for gwt-rpc-
plus.

I'd like to use thrift IDL to define data-transfer-objects that will
go on the wire between my GWT client and my RESTful services
(implemented with JAX-RS).

I'd like to have a server-side model and a client-side model generated
by my tools (in this case gwt-rpc-plus and thrift). Also, I want the
client-side model to be generated as JavaScript overlays.

Using gwt-rpc-plus, I've got to the point where I have usable client
and server DTO. I'm trying to send the server constructed DTO to the
client using the proper protocol, but I can't seem to get that to
work.

On the server, I expected to do something like (thrift-0.2.0):

TProtocol protocol = new TJSONProtocol(new
TIOStreamTransport(outpustream));
MyDto dto = new MyDto(some, parameters);
dto.write(protocol);

This doesn't work because the generated client-side objects are not
compatible with TJSONProtocol (nor with the TSimpleJSONProtocol). The
jsonrpc package contains a something that looks like a TProtocol, but
it's not. Seems like that changed in r90.

So my question is how do I serialize my server-side DTO without going
through the server-side gwt-rpc-plus mechanism? Is my use-case valid?

Thanks,
Philippe

Matt Mastracci

unread,
May 11, 2010, 10:44:26 AM5/11/10
to dotspots-o...@googlegroups.com
Hi Philippe,

The code originally used some of the Thrift JSON protocols for communication with the client, but I had to scrap that at some point in favour of our own protocols. The JSON we use is much more compact and compatible with GWT overlay types, making it much more performant. Unfortunately the tricks we use to make it smaller and more performant mean that we need the objects reading from our data stream to tell us what type they expect, something we can't do with standard Thrift protocols.

Since we're not entirely Thrift compatible, there's no Thrift protocol we can offer to allow the serialization code outside of the RPC framework. We have an alternate set of protocols (com.dotspots.rpcplus.jsonrpc.thrift.TJSONProtocolReader|Writer) that serve the same function as TProtocol. TJSONProtocolWriter runs on top of a standard Thrift TProtocol, while TJSONProtocolReader runs on top of a JSONTokenizer. You can use these classes directly in concert with the object readers and writers generated in the service file:

http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plus/example/gen-json-server/com/dotspots/rpcplus/example/torturetest/TortureTestApiJson.java

All of the code for serializing and deserializing the objects is laid out in the generated json-server file. In fact, we use those methods as part of one of the unit tests to test round-tripping through the RPC layer, though we currently have to use reflection to make them accessible. You should be able to use code similar to the following to achieve what you're looking for:

http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plus/test/server-test/com/dotspots/rpcplus/test/server/TestJSONNativeProtocol.java

Let me know if you need further explanation,

Matt.
Matt Mastracci

Founder/CTO @dotspots (http://dotspots.com)
@mmastrac



Reply all
Reply to author
Forward
0 new messages