Hi Quake,
this is gonna be long, so please bear with me. :-)
Am 03.08.2006 um 02:52 schrieb Quake_Wang:
> We are switching our applications from 0.5.x to namspace branch
> now, found that there is a JSON-RPC Java backend implementation in
> SVN. I'm curious about the difference with JSON-RPC-JAVA ( http://
> oss.metaparadigm.com/jsonrpc/ ), in my opinion, it's more mature
> and feature rich, and no need to implement any interface such us
> RemoteService.
Maybe this is a misunderstanding. The RemoteService interface is just
a tagging interface (no methods to implement). It's intended to make
things easier, not more complicated: For a class to be available for
client calls, there's no need to register it anywhere like in JSON-
RPC-Java. Simply adding "implements RemoteService" to the class is
enough.
> We have use it in 0.5.x successfully, can we recommend it as a best
> practice in qooxdoo for java json rpc instead of reinvent wheel?
JSON-RPC-Java is nice (a colleague of mine is using it), and you're
free to stay with it for your server calls. But IMHO, it also has
some deficiencies that don't make it suitable as the standard RPC
mechanism in qooxdoo:
- The class hinting mechanism is not well suited to backends in
different languages. You would need something like "phpclass" in
addition to "javaclass", and even then, you couldn't transparently
use different backend implementations without changing the client
code. One design goal of the qooxdoo RPC was to not leak details of
the server implementation to the client.
- Related to the above point, the qooxdoo RPC supports passing
structures, but this works without any class hinting. For example,
let's say you have a server-side method like "void doSomething
(Address a)". You can call it like this from JavaScript:
myRPCInstance.callSync("doSomething", {street: "...", country: "..."});
The anonymous JavaScript object with the address properties is
automatically converted to an Address object on the server side. The
only requirement is that there is an Address class with a public
default constructor and with setters for all the properties
("setStreet()" etc.). You don't have to use class hinting or register
the Address class anywhere, and you can switch to a backend in
another language without changing the client code. (I just saw that
this also works with JSON-RPC-Java, although apparently not with
nested structures/Beans.)
You can also nest these JavaScript objects (which are then mapped to
nested Java beans). Similarly, when you return a Java object from a
method, it's automatically converted to a JavaScript object with all
properties accessible by Java getters mapped to JavaScript properties
(also nested if necessary).
- JSON-RPC-Java doesn't support dates (except maybe for a cumbersome
class-hinting based solution that doesn't translate transparently to
other backends).
- The qooxdoo RPC supports overloaded methods.
- JSON-RPC-Java uses a synchronous server call when you instantiate
the central JSONRpcClient class (in order to receive all the
available objects and methods from the server). Usually, synchronous
calls should be avoided because they block the browser for the time
of the call. This is not a big design flaw, just a weak point.
Of course, there are also advantages of JSON-RPC-Java over the
qooxdoo RPC:
- The automatic client stub generation is nice. "myclass.mymethod
(param)" looks better than "myservice.callSync('mymethod', param)".
Something like this could be added to the qooxdoo RPC, but it would
require some sort of registry that isn't currently there (and that
would make it more inconvenient to use on the server side).
- The class hinting mechanism can be handy for cases where you really
need it. However, it should be made more general to also support
cases where you need to pass constructor parameters (which are often
not available as setters).
- Opaque and Callable references are useful. I think it would be nice
to add them to the qooxdoo RPC.
I've not used JSON-RPC-Java much, so please correct me if any of my
statements about it are wrong.
Regards,
Andreas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
