[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Remoting & CAO Question

unknown

10/28/2004 3:03:00 PM

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


4 Answers

Ken Kolda

10/28/2004 3:17:00 PM

0

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" <nospam@nospam.com> wrote in message
news:Of2Go%23PvEHA.3728@TK2MSFTNGP12.phx.gbl...
> 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
>
>

unknown

10/28/2004 3:34:00 PM

0

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" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:%23M5AaFQvEHA.1204@TK2MSFTNGP10.phx.gbl...
> 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" <nospam@nospam.com> wrote in message
> news:Of2Go%23PvEHA.3728@TK2MSFTNGP12.phx.gbl...
>> 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

10/28/2004 4:16:00 PM

0

> 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

unknown

10/28/2004 4:53:00 PM

0

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


"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:%23nlt8lQvEHA.3272@TK2MSFTNGP12.phx.gbl...
>> 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
>
>
>