gwt rpc vs json
Brian
shoving json across the wire is straightforward.
What's the compelling case to use gwt rpc? Remember, I haven't even
looked at the docs. I'm not trying to bash anything here, just
wondering why it's worth it to setup gwt rpc vs just moving json
around. My backend server is tomcat.
mikeds...@gmail.com
communication between the GWT Client and a Java based Server. GWT-RPC
on the server is pure java and allows for easy hooks into Hibernate
and other Java based server technologies. If your server isn't Java
based, then JSON is the best way to go...
Lothar Kimmeringer
> The strength of GWT-RPC is that it allows for near seamless
> communication between the GWT Client and a Java based Server. GWT-RPC
> on the server is pure java and allows for easy hooks into Hibernate
> and other Java based server technologies.
I was going to answer more or less the same, so I build my answer
on top of yours ;-)
The "sexiness" comes with the implementation of RMI with the
specifics of being forced to perform asynchronous requests.
So the only thing you have to do is call a method that is
defined in an interface, leading to the call of the correspon-
ding method being implemented in the servlet.
How the parameters passed to the method are marshalled/un-
marshalled is done by the RPC-framework, the same is valid
for the data being returned by the method.
It makes testing the implemented methods in the servlet
easier as well (as long as you don't access the request-
and/or response-instance directly) by allowing you to
call an explicit method instead of firing up a HTTP-
server, create an HTTP-request and send that to the
server or use httpunit for establishing a virtual Servlet-
environment to pass in the request that way.
> If your server isn't Java
> based, then JSON is the best way to go...
ACK
Regards, Lothar
gregor
In addition:
1) GWT RPC is heavily optimized for serializing java objects between
client and RPC remote servlets so it will almost certainly be faster
than your JSON equivalents
2) All the serialization/deserialization work is done automatically
for you so your return objects are handed to you on a plate ready to
go. If you are passing complex object graphs (including Collections
etc) over the wire this a big advantage.
If you have a Java back end it's a no brainer really.
regards
gregor
On Oct 29, 2:08 pm, "mikedshaf...@gmail.com" <mikedshaf...@gmail.com>
wrote:
Ian Petersen
perhaps more obscure ones:
- The RPC wire format is about as compact as you can get because it's
_not_ self-describing. This is a plus if you're shuffling lots of
data around, but I don't know how to define "lots" for you.
- There's plans to make the deserialization of RPC responses
"asynchronous" so you don't tie up the browser thread reading large
responses. You'd have to do the same thing manually with large JSON
responses.
- Using RPC is a nice way of abstracting the transmission details and
saying "I don't care" about the wire format of your requests and
responses. This means client-server interface management is reduced
to managing the evolution of a Java interface, rather than worrying
about whether or not the client and server are in sync. It also means
that some mismatches between client and server can be caught by the
compiler.
- It _might_ be easier to re-use an RPC server-side than a JSON
server-side because the RPC-specific details are already pretty well
isolated from the business logic.
Ian
Brian
Is the gwt-rpc format described, so I could write a non-gwt app (say,
a mac desktop gadget) that hits my server using the same api as the
gwt-rpc browser app? Note, I don't actually care right now what the
format is, just that the protocol is described, and is easy to impl in
a non-gwt-rpc-browser app (like it is with json ;-)
Brian
because I have bugs in my json api from time to time, but it's very
handy to fire up ethereal/wireshark and check what's happening on the
wire. But I hear ya, it'd "be nice" if I didn't have to care, I just
do.
Is the wireformat plaintext? Is it published?
Thanks everone for the info. Guess I got my answers, and I should
start hitting the api docs on gwt-rpc if I start going down this road.
Jason Essington
look at overlay types in GWT. It is much simpler (and faster) than
mucking about with the JSON parser.
-jason
On Oct 29, 2008, at 8:31 AM, Brian wrote:
> Sounds pretty good. Seems like I spend half my time typing:
> int n = (int) jsonNum.isNumber().doubleValue();
> String s = jsonStr.isString().stringValue();
Jason Essington
going to the server will look different than coming from the server.
There also isn't really a published spec for the RPC wire format as it
tends to change from version to version of GWT.
In GWT, this is not an issue because the GWT compiler generates the
code required to convert to and from the wire format, so the wire
format could be wildly different from one version to another with no
change in your source code.
Does this mean that you can't create a non-gwt client? no ... but it
certainly does make your job a little more difficult.
-jason
walden
In over a year and a half of using GWT RPC, I've never had a failure
that had anything to do with mismatched wire formats.
I hear your concern. What's the saying? "Once bitten; twice shy." I
think there's a scar there that, given time, can heal completely,
though.
Walden
>
> - Show quoted text -
Ian Petersen
> Sounds good.
> Is the gwt-rpc format described, so I could write a non-gwt app (say,
> a mac desktop gadget) that hits my server using the same api as the
> format is, just that the protocol is described, and is easy to impl in
> a non-gwt-rpc-browser app (like it is with json ;-)
I think Jason and Walden gave pretty good answers, but I thought I'd
give a little more detail.
The GWT RPC format is intentionally opaque JSON. This makes it
somewhere between difficult and impossible to add a non-GWT agent to
the RPC discussion. There isn't really a nice work-around for
creating a non-Java server-side implementation but, because your
RemoteServiceServlet implementation just has to implement your
synchronous RPC interface, it's quite possible for non-GWT clients to
talk to the same server-side business logic, just without using the
RPC protocol.
The easiest way to implement RPC on the server is like this:
public interface HelloWorld extends RemoteService {
String sayHi(String name);
}
public class HelloWorldServlet extends RemoteServiceServlet implements
HelloWorld {
public String sayHi(String name) {
return "Hello, " + name;
}
}
In a GWT client, you'd use it like this:
// you need to maintain an Async interface in parallel to the service definition
public interface HelloWorldAsync {
void sayHi(String name, AsyncCallback<String> callback);
}
HelloWorldAsync service = (HelloWorldAsync) GWT.create(HelloWorld.class);
service.sayHi(new AsyncCallback<String>() {
public void onFailure(Throwable caught) {
// handle server-side errors and networking errors
}
public void onSuccess(String response) {
Window.alert("Server says: " + response);
}
});
So, from a GWT perspective, it's _really_ easy. The point I'm trying
to make here, though, is that the server side is just an
implementation of an interface. It's possible (using the class named
RPC) to implement that interface on one class and answer HTTP POST
request in a different class (the above example does everything in one
class by subclassing RemoteServiceServlet). Separating the business
logic from the HTTP request-handling means that you can re-use the
business logic to support non-GWT clients in whatever fashion you
like, including standard Java RMI, and RESTful webservices.
On Wed, Oct 29, 2008 at 10:45 AM, Brian <hib...@gmail.com> wrote:
> I care heavily about the wireformat of my requests. Maybe that's
> because I have bugs in my json api from time to time, but it's very
> handy to fire up ethereal/wireshark and check what's happening on the
> wire. But I hear ya, it'd "be nice" if I didn't have to care, I just
> do.
> Is the wireformat plaintext? Is it published?
> Thanks everone for the info. Guess I got my answers, and I should
> start hitting the api docs on gwt-rpc if I start going down this road.
The wire format is plain text. It's actually JSON. It's just
unreadable JSON because the assumption is that both the producing and
consuming code is auto-generated and can make all kinds of assumptions
about the structure of the text.
I've explained the wire format in copious detail in previous posts to
either this list or the GWT-Contributors list. If you're interested
in the gory details, you could search for those old posts. Just be
aware that I was explaining the format as it was used in GWT 1.4. The
RPC guts have changed very slightly since then to support a few
features in custom field serializers. Also, I think GWT 1.5 has
redefined or stopped using some of the flags that were available in
the old format. In other words, the spirit of the format is still the
same, but there might be some differences in the details now.
Ian
Brian
the protocol, as I support form post and json get's using the same api
(essentially...) It's interesting that the wireformat is json. I was
sorta hoping it was some super tight binary format that would tempt me
to switch (I'm not sure it would, latency is so much worse than
throughput). Turning on gzip compression on the http server basically
makes my json into binary anyway though...
I'm sticking with json until I no longer need access by non-gwt
clients. Those overlay types mentioned previously are -very
tempting-. I need to look into that, as overlaying a class on my raw
json from requestbuilder would nice -- especially if I don't have to
wear out letters on my keyboard typing isNumber().doubleValue() ever
again (note to self: write a function)
On Oct 29, 3:20 pm, "Ian Petersen" <ispet...@gmail.com> wrote:
Damon Lundin
application just switched from using JSON to RPC as the payload for
the initial data set embedded in the original HTML sent from the
server on the first request. We've also been slowly converting our
JSON HTTP requests to RPC calls. Using RPC is vastly easier since you
have an entire Serialization layer you can throw away.
However, it does have drawbacks. If you have massive amounts of data,
contrary to what gregor said above, the RPC calls will be
significantly slower on the client. With JSON, the client does an
eval on the data and its ready to go. That is very fast. With RPC,
the GWT RPC deserialization code has the parse the data, walk over it,
and construct the relevant objects. There is no way that will ever be
as fast as eval.
That said, the difference is insignificant for most of our RPC calls
and for the larger ones (where the amount of data makes for a slow
client anyway) we decided that the drop in performance was more than
worth the simplicity in our code. There is one upside to this -
there's a project in the works that will modify the RPC payload format
so that it uses directly eval-able Javascript code so that
deserialization mechanism doesn't have to actively parse the payload
but can just eval the results into existence. That would immediately
speed all RPC calls up for everyone.
It also has the added benefit of automatically ensuring that your data
model matches on the client and server. We've been in the situation
where our data model was different on both side with JSON essentially
translating between the two. This has made it difficult to write code
that can run on either the server or the client and use the same model.