Remoting & CAO Question

[Z D]

Hello,

Is it true that I need to push the DLL for my entire class if I wish to use
CAO remoting???

Can't I just use an Interface to the class on the client side and
instantiate the object in a similar fashion to using SAO Singleton with an
interface? ie:

Dim MyPerson As IPerson
MyPerson = Activator.GetObject(GetType(IPerson), <RemotingURL>)


How can I do this using CAO in a similar fashion?

Thank's in advance,
-ZD

 

[Ken Kolda]

To do this with CAOs you create an SAO object factory that instantiates and
returns your CAOs. For example, say you have an object which will be
client-activated and for which you've defined an interface that will be in
your shared assembly:

public class MyCAO : MarshalByRefObject, IMyCAO
{
// ...
}

Then create an SAO factory as follows:

public class CAOFactory : MarshalByRefObject, ICAOFactory
{
// Function to create your CAO object
public IMyCAO CreateCAO()
{
return new MyCAO();
}
}

In your client, you use Activator.GetObject() to get the SAO class factory,
then invoke the CreateCAO() method to get your CAO object reference. For
example,

ICAOFactory factory = (ICAOFactory) Activator.GetObject(typeof(ICAOFactory),
"tcp://...");
IMyCAO cao = factory.CreateCAO();

Using this technique you don't need the CAO's class definition on the
client, just the interface definitions.

Ken

 

[Z D]

Hi Ken,

Thanks so much for your quick response.

This works? Wow! How does remoting know that the MyCAO object is a CAO?
Don't I have to define that somewhere?

If I setup the SAOFactory as SingleCall SAO then will the MyCAO object still
exist once the SAO call has completed?

I find this very unintuitive since there has never been an explicit
definition saying that MyCAO object is a CAO but I guess it makes sense.

Thank's so much!!
-ZD

 

[Ken Kolda]

This works? Wow! How does remoting know that the MyCAO object is a CAO?

Don't I have to define that somewhere?

The difference between an SAO and a CAO is the manner in which the client
obtains the proxy for the object. An SAO is an object for which the client
can generate its own proxy without additional info from the server. To do
this, the client must know the exact URL at which the remote object lives,
i.e. the object must be "well-known". When you call Activator.GetObject()
and pass a URL to it, you are creating an SAO reference since the client has
all the info it requires to communicate with the remote object.

The proxy for a CAO requires additional info from the server in order to
know how to communicate with the specific object instance. This info comes
in the form of an ObjRef passed from the server to the client which contains
the information such as the remote object's URI. If you didn't obtain your
reference to the remote object via a well-known address, then the only way
you'll be able to communicate with it is through an ObjRef, which means it's
a CAO.

The main hurdle to understaning this is realizing that SAO/CAO is not a
property of the class or even the object instance but a property of the
reference you hold to the object. For example, it's possible to hold both a
CAO reference and an SAO reference to the exact same object on the server.

If I setup the SAOFactory as SingleCall SAO then will the MyCAO object still
exist once the SAO call has completed?

Absolutely. The lifetime of the returned object has nothing to do with the
lifetime of the object that instantiated it. This is just as true with
remoting as it is in non-remoting contexts. The lifetime of the object (from
the perspective of the client) will be determined solely by its lifetime
lease. This is the same regardless of whether the object is a remoted as a
CAO or SAO.

Ken

 

[Z D]

Ken,

Thank you VERY much for your explanation & assistance on this matter.

I have tried out your suggestion and it's working perfectly!

Thanks very much
-ZD

 

[Guest]

Ken,

I have this structure to create CAOs (SAO hosts CAOs). My SAO has a
custom-built timing mechanism to control life-time of each CAO. When a CAO is
timed out, my SAO removes (or tries to remove) the CAO, meaning removing the
object and reference of the object that SAO keeps in its private
CAO_Collection. The problem is CAO is never removed regardless SAO has set
the object to null. Client application can still access and get full state of
the "removed" CAO. Why? Shouldn't the object go away or is it b/c client
still has the reference so the CAO is not garbage collected by .Net
framework? How can I completely remove the object so client will not have
access to the object anymore once removed?

On the other hand, is there a better way to control life-time of CAOs in
this structure than custom-built one?

Thanks.

 

[Ken Kolda]

See comments inline below...

Ken,

I have this structure to create CAOs (SAO hosts CAOs). My SAO has a
custom-built timing mechanism to control life-time of each CAO. When a CAO is
timed out, my SAO removes (or tries to remove) the CAO, meaning removing the
object and reference of the object that SAO keeps in its private
CAO_Collection. The problem is CAO is never removed regardless SAO has set
the object to null. Client application can still access and get full state of
the "removed" CAO. Why?

When you remote an object, the remoting framework actually holds it own
reference to the object instance -- it needs this so it can invoke methods
on the object in response to client requests. So, even if your code no
longer holds a reference, that doesn't allow the object to be garbage
collected no does it prevent the object from servicing clients.

Shouldn't the object go away or is it b/c client
still has the reference so the CAO is not garbage collected by .Net
framework?

No -- whether or not a client holds a reference to the object has no effect
on the lifetime of the remoted object. The lifetime of a remoted object is
determined only by its lease and any attached sponsors.

How can I completely remove the object so client will not have
access to the object anymore once removed?

To stop a remoted object from being accessed by clients, use
RemotingServices.Disconnect() -- this will tell the remoting framework to
drop its reference to the object (which will also mean it can be GC'ed if
your code releases all of its references).

On the other hand, is there a better way to control life-time of CAOs in
this structure than custom-built one?

The preferred method for controlling the lifetime of a CAO is to use a
client-side sponsor. When the client terminates, the sponsor will no longer
be able to renew the CAO's lifetime and it will eventually expire. For more
info on sponsors and lifetime, check out these pages on MSDN:

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconlifedeathinstances.asp

Ken