Efficient (and simple?) forwarding of ice invocations

sylvain

Hi,

I have to face the following situation. Let's say I have 3 processes "A","B" and "C", all 3 using Ice (very successfuly I must say).

"A" is a pure server: it provides implementation for interface "I" .

"B" is a client of "A": it makes remote invocation of methods of interface "I" using a proxy got from "A"

"B" is also a server implementing another interface "J".

"C" is a pure client of "B" for interface "J". "C" cannot connect to "A".

Now I would like "C" to be able to invoque methods of inteface "I" running on "A" anyway.

My idea is to:
1) code a second implementation of interface "I", running on "B" that just call the implementation running on "A", so that just "forward" the invocations (and the replies).
2) add a method to interface "J" that just return a proxy for an interface "I" (the proxy of course point to the implementation running on "B").

This works, but this is quite inelegant, and of course not very efficient since parameters are copied and demarshalized-remarshalized 2 times instead of one. Also, any change to interface "I" must be reflected 2 times and and this could be error-prone.

So I was wondering whether there exist an elegant solution to this problem, that doesn't involve too much high level things like implementing interface Ice::Router, and so on.

For instance: is it possible that every invocations of any methods of interface "I" on "B" trigger a single functions with the "not yet demarshalized data" as parameters that I can automatically redirect on a proxy of "I" bound to the implemention in "A"?

I hope I was clear enough, and that this question makes sens. In the manual there is something about "dispatching blob" but I did not understand for the moment whether this is not really overkill for me.

Thank you very much in advance for your replies.

Sylvain

mes

Hi,

The simplest and most efficient way to do it is to provide C with a proxy for I and let it communicate directly with server A. This is the strategy I would recommend, assuming there are no network restrictions that would prevent C from communicating with A.

If C is unable to establish a connection to A, then one solution is to have B forward requests on behalf of C. You can do this efficiently with the Blobject interface, and I wrote a newsletter article on this subject in issue #11.

Hope that helps,
- Mark

sylvain

thank you

Hi Mes,

Just a quick post to tell you that reading issue #11 of Connection completely answered my question. I have been able to implement the kind of architecture I had to, using ice_invoke and Blobject.

Thank you very much for you efficient reply, then.

Now I have to deal with what to do if the "registry" (in my case the process "B") fall abruptly. I am currently implementing some kind of timed loop in the client process that repeatidely ping the registry. If the ping fail then the loop switch to anoter one that repeatidely try to establish a connection and to register its objects, and so on.

If you have time for making a better suggestion... (I am trying to avoid that the registry has to tell something to the client)

Thanks again.
Sylvain