bidirectional RPC

[AK]

Dear all,
I got interested in JSON-RPC because of its bidirectional
communication abilities.

For example, from http://en.wikipedia.org/wiki/JSON-RPC:
"In contrast to XML-RPC or SOAP, it allows for bidirectional
communication between the service and the client, treating each more
like peers and allowing peers to call one another or send
notifications to one another. It also allows multiple calls to be sent
to a peer which may be answered out of order."

Is this the basic functionality in implementations like http://jabsorb.org/,
or do I have to write my own client/server around the JSON-RPC
specifications to make use of bidirectional communication?

I cannot find any documentation, example or tutorial how to achieve
bidirectional communication beyond the simple callback mechanism. What
I need is a setup, such that all clients that are connected to one
server, are notified when any of the clients performs certain actions
on the server.
The only workaround I see at the moment, is that each client calls
some method notifyMe(myCallback,...) on the server. Whenever the
notification happened, each client would immediately call notifyMe
again, so that it has a callback channel open all the time. But this
is not at all like the above "the service and the client, treating
each more like peers and allowing peers to call one another"
description.

Can you outline a better possibility how to achieve bidirectional
communication in the scenario I have mentioned?

Regards,
AK

[Matt (MPCM)]

The 2.0 spec moved to dissolve this peers concept, but you can achieve
the same thing by having a doubling up on both traditional "peers",
where each acts as a server and client, though not over the same
immediate pipe I would imagine, but the transport would be up to you
anyway, so it could be.

I can't speak for jabsorb, but I'd check with them directly. In my
experience, many 1.0 implementations never had the bi-directional
concept working correctly. I wouldn't take wikipedia's description as
the fact of what json-rpc is (or was). I always read the 1.0 spec as
being a client and server, that act could act as peers. Not sets of
peers where the messages could go from A->B->C and back directly.

> I cannot find any documentation, example or tutorial how to achieve
> bidirectional communication beyond the simple callback mechanism. What
> I need is a setup, such that all clients that are connected to one
> server, are notified when any of the clients performs certain actions
> on the server.

What you are talking about is more like a central notification hub,
not many 'peered' relationships. I guess it depends if an event on one
client needs to trickle back to the central server, then out to
another client... a message broker and agents. An event based system
using json-rpc notifications does this very well, but you can also do
it without confirmed, but simple responses. Message passing, more than
rpc...

It depends on your transport (http or sockets)? Are your client's
browsers or smarter clients? JSON-RPC can help you do these types of
things, but you are correct that you need an implementation that would
support the long polling/open connections, and an API designed to
handle this message passing setup.

If you need one client to call functions on another, a meta-json-rpc
set of exposed methods on the central server that take json-rpc
messages a parameter to be passed to clients would also work. Depends
how smart/involved you want your central server I suppose. Also if it
is a spoke, or a wheel... server could just arrange initial contacts..

> Can you outline a better possibility how to achieve bidirectional
> communication in the scenario I have mentioned?

JSON-RPC doesn't have a set way to handle something like this, so you
may end up rolling your own. If you want to post more examples in this
conversation, I'm sure there are folks who could offer suggestions,
but I haven't seen many implementations doing this.

--
Matt (MPCM)

[Arthur Blake]

I think someone ought to update that wikipedia entry for clarity.  JSON-RPC as the way it's used in jabsorb is just a simple RPC call, initiated from the client to the server.  You cannot directly initiate a call from the server to the client (actually there is no way to do this at all with standard HTTP).  Only by using another technique, like polling/comet, etc., can you simulate a server connecting to the client in a browser/web server environment (but it's just a simulation-- the client still always has to make the initial connection.)  Jabsorb does also have a java client for both sync and async requests, so you can do true peer to peer json-rpc using that (but that's not in a browser environment) and in this case each peer would actually be a separate client and server both.  I hope that clears it up a little...

[Kris Zyp]

As others have said, JSON-RPC doesn't dictate how the communication
channels are established. For another example though, in Persevere,
bidirectional RPC is supported by making a comet connection to the
server, which allows the server to send RPCs to the client when a method
is executed that is marked as runAt: "client". However, this isn't used
much as it tightly coupled to a single client and particular client side
method. More common in Persevere is for clients to subscribe to objects
and their method calls, and then all the subscribed clients get
notification messages [1] from the server when a method gets called.
These notification messages exist outside of JSON-RPC (they aren't
JSON-RPC notifications) because they aren't RPCs; they provide
information on an event that took place rather than dictating what
method on the client gets called.
[1]
http://cometdaily.com/2008/09/02/rest-channels-http-channels-with-json-support/
Kris


> Regards,
> AK
> >
>

[Arthur Blake]

I've used similar techniques as Kris has outlined for pushing server message to the client over json-rpc.  And no doubt, there are frameworks that automate this sort of thing (I think DWR does as well, but I haven't used it), but like Kris said, that's not json-rpc... but it can be an infrastructure built on top of json-rpc.  Kris, maybe you could update and clarify the wikipedia page if you get a chance... I may later if I get time (but I like your prose a lot-- :)

[AK]

Thanks to all for your detailed explanations.
Apparently I was mislead by the outdated wikipedia description, and
JSONRPC is not the right tool for my purpose. Although this is now off-
topic, may I ask if you know a different RPC framework that is as easy
to use as JSONRPC and allows bidirectional communication?

All comet concepts (including persevere, i guess) keep one connection
open for the server->client path (either streaming or long polling),
and a second connection is required for the client->server path. This
is wasted resources. In principle, using pure sockets, messages can be
sent both ways on a single connection, once the child has connected to
the server (and this even works if the client's firewall blocks
incoming connections). Don't you know any RPC framework that builds
upon this principle? It could save me some work reinventing the wheel.
I just came across Ice (www.zeroc.com) - would that be appropriate, or
does it serve a different purpose?

To summarize, these are the requirements:
* easy to use bidirectional RPC
* example application: clients are notified of events (include other
clients' actions) on the server
* clients can't take server role, because they might block incoming
connections
* optimize resources and performance (e.g. short latencies, don't open
two connections where one is enough, maybe compress messages)

Regards,
AK

[Arthur Blake]

Are your clients web browsers?  If so, you are pretty much limited to one of those schemes.  Even if you use a java applet or some kind of flash or other plugin, you are limited to HTTP because of firewall issues and browser sandbox restrictions.  You might be able to do some particular shenanigans to get around those restrictions, but it all depends on the app and environment it needs to run in... but for maximum portability in all environments across the web, you'd probably have to stick to something on top of HTTP.  Note that even though from the HTTP layer, it appears that you are opening multiple connections just to send individual messages, in practice, only one socket is open and kept open for the duration, because of the HTTP keep-alive optimization.

[AK]

You are right, I should have mentioned that the reason for some of the
requirements is that I want to reserve the possibility to access the
service from a java applet running in a web browser. However the main
development will focus on a standalone java client, but the use case
from an applet is also very important.
The only limitations of applets running in a browser, that I know of,
are:
* the applet cannot listen to incoming requests (which are also
blocked by most firewalls)
* the applet can only connect to the host which delivered the applet,
but it can connect on any port
I don't see, why firewall issues (unless the firewall is very
paranoid) or browser sandbox restrictions could cause additional
problems. Can you add a few more details on that?

Regards,
AK

On Jul 28, 3:19 pm, Arthur Blake <arthur.bl...@gmail.com> wrote:
> Are your clients web browsers?  If so, you are pretty much limited to one of
> those schemes.  Even if you use a java applet or some kind of flash or other
> plugin, you are limited to HTTP because of firewall issues and browser
> sandbox restrictions.  You might be able to do some particular shenanigans
> to get around those restrictions, but it all depends on the app and
> environment it needs to run in... but for maximum portability in all
> environments across the web, you'd probably have to stick to something on
> top of HTTP.  Note that even though from the HTTP layer, it appears that you
> are opening multiple connections just to send individual messages, in
> practice, only one socket is open and kept open for the duration, because of
> the HTTP keep-alive optimization.
>

[Arthur Blake]

I think we're really starting to get off topic from json-rpc but if you are in control of the firewall and you can open up those ports it might be fine.

But you might find that outgoing firewalls that you are not in control of might block it.  I can't back that up with any stats or inside knowledge, but if I was a sys admin, I would block everything that isn't explicitly necessary, including outgoing connections. (in other words, I would be paranoid :)