passing objects

[nicole]

I am new to ICE and have a question.

i am currently returning an object (not a proxy) from a java server to a c#client. On the client side, i want the methods and members of the object I just retrieved to be called locally to the client (non-rmi). So i did this with this slice code:

class JMSQueueIce {
string queuename;
string getName() throws Util::JMSExceptionIce;
void setName( string name ) throws Util::JMSExceptionIce;
};
....
JMSQueueIce lookup( string destinationName) throws Util::JMSExceptionIce;

I had my generated abstract class, extended it in on both sides (c# for client, java for server), and registered them with object factories.

The problem is that on the server side, i want to associate another object (a non-ice, java jms queue object) with the one i'm returning to the client - in other words, i want to store it on the server-side only.

So my question first is:
1. how do you recommend I do this?

2. If your answer is "pass a proxy to this queue object back and forth" in order to facilliate the server-side storage, then how do i ensure that the getName() and setName() methods will be invoked locally when called from the client, instead of remotely? (i.e. i want that variable queuename to be sent across the wire as well)

[michi]

You may find this post of interest.

If your answer is "pass a proxy to this queue object back and forth" in order to facilliate the server-side storage, then how do i ensure that the getName() and setName() methods will be invoked locally when called from the client, instead of remotely? (i.e. i want that variable queuename to be sent across the wire as well)

If you invoke on a class instance via its Java reference, the call will be dispatched locally. If you invoke on a class instance via its proxy, the call will be dispatched remotely. So, you can choose the behavior you want.

Another way to (conceptully) pass a reference to Java (non-Ice) object is to have the server create the object and put it into a table. The server then passes the table index to the client, and the client can return the index to the server to indicate which object it is referring to.

The first option (using a proper Ice object and invoking on its proxy) is preferable, unless you really have no choice but to use option 2.

Cheers,

Michi.

[nicole]

The reason I am returning a proxy from the server to the client
(JMSQueueIce* lookup( string destinationName) ...) instead of just a regular class is to be able to associate a non-ice object with the ice object JMSQueueIceObject on the server to save the non-ice object (saving state). Is there a better way to enable this sort of caching?

Thanks!

[michi]

I'm not sure I fully understand what you are after...

As I said previously, if you want to allow the client to denote a non-Ice object in the server, one way to do it is to have the server associate some unique identifier (such as a table index) with the object and then have the client pass that identifier.

Cheers,

Michi.

[nicole]

How would I implement the table suggestion?

I was reading the former post you recommended, and have these questions:

- How do you denote an address space for a Prx? Isn't is always remote?
Or can you have some methods in the Prx (such as getName() ) be local and others be remote?

[matthew]

...
- How do you denote an address space for a Prx? Isn't is always remote?
Or can you have some methods in the Prx (such as getName() ) be local and others be remote?

A proxy has nothing to do with whether the referenced object is remote or local. A proxy refers a single Ice object (defined by the object identity and optionally addressing information). I re-read your posts and to be honest I have no idea what you really want to do... Perhaps you should restate your goals?