Pathfinder Development » Thinking of alternatives to GWT-RPC

Thinking of alternatives to GWT-RPC

Ivan Moscoso, Wednesday, November 28, 2007 @ 8:42 am

What would alternatives to GWT-RPC look like?, it would be interesting to see these come about, and I think it would be worthwhile to do some experimentation in this area.

I believe rather than tweaking what's there, we can see radically different approaches go different directions, either by building on top of GWT-RPC, or providing a drop-in replacement.

A few issues to consider: while we are working in a richer client-side environment, we still define and build our server-side interfaces in the same fashion as before: Remote interface, implementation, and server-side configuration. GWT requires an additional client-side (i.e. 'Async') interface, target definition & invocation code (casting the GWT-generated proxy to the async type), editing the module file definition for the service, making sure any data objects implement GWT's 'isSerializable' interface, and the server-side component extending GWT's RemoteServiceServlet.

The client/server contracts are generally the same-- "save this", "retrieve this",
"search for this", etc. So a a little bit of convention might go a long way
between what the client is likely to send and what the server generally
provides. Might this reduce the list above? How about putting the async behavior where it belongs on the GWT components rather than using the 'onSuccess/onFailure' callback mechanism? It would make the code clearer, and would probably be much more testable.

And then there's testing-- conventional wisdom suggests having a separate, 'mock' version of the server-side component when running in hosted mode. GWT provide a way of detecting 'hosted' mode from 'non-hosted' mode, effectively allowing your code to switch between server-side implementations.

Frameworks such as the GWT Server Library aid in the server-side configuration pain, allowing you to write POJO services while using Spring configuration to wire into GWT-RPC. But the net effect hasn't changed-- there's still all that configuration and, I put forth, intrusive code required even to get us there.

As Java developers, our pain points are generally high when it comes to this sort of thing-- and the tired and true aphorism generally surfaces: "well, I've seen worse..." Let's not settle our technology choices just for that reason alone.

Now, I know there's nothing in GWT that requires you to use GWT-RPC. Because any solution would require JS bindings for any Java code, it is not a trivial problem to solve, but not out of the question either. Alternatives could happy live side by side with GWT-RPC. Will an alternative surface? Can this be made better by using another paradigm?

Topics: Ajax Development

agile ajax

Comments: 8 so far

It would be interesting to see a REST implementation.

Comment by Ryan Dewsbury, Wednesday, November 28, 2007 @ 10:05 am
Good point- I have something like that in mind as well.

Comment by Ivan Moscoso, Wednesday, November 28, 2007 @ 6:09 pm
GWT wants to abstract away the web. REST embraces the web. As such, I wouldn’t hold your breath for a REST interface coming out of Mountain View.
I think something like Enunciate [ Comment by Justin Makeig, Wednesday, November 28, 2007 @ 7:03 pm
I believe that Jester (http://jesterjs.org) coupled with JAX-RS (or even Rails) on the server side might be a nice way to go.

Comment by Jon Crosby, Thursday, November 29, 2007 @ 10:45 am
“GWT wants to abstract away the web. REST embraces the web. As such, I wouldn’t hold your breath for a REST interface coming out of Mountain View.”

@Justin: We must be doing a bad job of explaining the full philosophy of GWT. We are most definitely *not* trying to abstract away the web; we’re just trying to add leverage to make better apps possible. That’s why GWT has the JavaScript Native Interface (JSNI), JSON, and XML libraries in addition to GWT-RPC. Widgets are styled with CSS.

If you have the time, please check out the GWT mission statement in “Making GWT Better” (http://code.google.com/webtoolkit/makinggwtbetter.html) to hear the full story. All that said, if we can be doing more to simplify interop or enhance the web user experience, please say so on the GWT contributor fourm.

Comment by Bruce Johnson, Saturday, December 1, 2007 @ 9:25 am
I was just thinking about this problem and trying to find out if someone else had looked into it.

I’ve implmented what I think is my ideal client/server communication on another project (non-web). It involved locating all the code and data for the transaction in a single object.

It is implemented something like this:

public MyXferObject extends MyXferObjectBase {
private int x;
private int y;
private int result;

public MyXferObject(int px, int py) {
x=px;
y=py;
}

public arrivedServer() {
result = x + y; // Long complicated operation
}

public arrivedClient() {
aLabel.setText(”The result was:”+result);
}
}

This has a few advantages and some pretty serious problems.

As for the advantages, it keeps everything needed for a given client/server transaction in one file. The shared data makes coding trivial, and there is no need to futz around with specialized interfaces or async callbacks, there are just two methods to override and that’s it–the arrivedServer is executed when the object arrives at the server, and the arrivedClient is executed by what is currently called the callback.

This also makes the calling as simple as “(new MyXferObject(1, 2)).send()” if we assume that the parent class implements a .send method to kick things off.

The disadvantages:
References to classes that exist only on the client or server will not compile on the “other side”.

Twoi possible solutions to this are:
- Pre-compiling to split the class into something that resembles the current RPC mechanism, or
- Using annotations to prevent the errors by specifying methods that shouldn’t compile on one side or the other.

There is also a perceived problem that you are “Mixing” client and server code in the same object, but since the concept is one that actually bridges the client and server, I think it’s completely appropriate.

Besides, the real advantage comes when the client and server portions are implemented separately. One abstract class implements the arrivedServer method–sy it does some generic database I/O, on some data fields. This could later be extended, overriding the “arrivedClient” method and possibly the constructor to set up the data, which should lead to quite a bit more reuse.

What I mean by “more reuse” is that this approach completely isolates and removes the RPC portion of the problem allowing a mid-level portion to be added on top of the communications without re-implementing it every time. I don’t know an easy way to do that with the existing RPC mechanism.

I am kind of working on this right now, and I’m just not familiar with the GWT compiler or annotations so I’m not sure where to start with the first problem I listed, but I’ll keep hacking at it.

Oh, also if this sits on top of the existing RPC mechanism there is the problem that I’ll always be passing a generic object around which the docs said was inefficient. Using a pre-compiler should solve that too.

Comment by BIll K, Sunday, January 27, 2008 @ 7:17 am
Better late than never, check out my blog on this topic, it basically goes along with some comments here. Feel free to leave comments, I plan to follow up directly in regards to them!

http://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc.html

Comment by Carl Scott, Monday, April 28, 2008 @ 10:30 pm
Better late than never:
is there a possibilty to use RMI in GWT? can’t get my RPC server running!

Comment by Austria, Wednesday, August 6, 2008 @ 3:10 am