Sunny
7/27/2004 9:55:00 PM
Hi Sam,
SAO and CAO are NOT types of objects. These names have meaning only in
terms of using config file configuration or programmatically with
RegisterWellKnown..., I.e. when the remoting infrastructure takes care
about the creation of the object. CAOs are created on a client request,
I.e. the client decides when this object to be created.
SAO are 2 kinds:
1. Singlecall - they are created by the remoting infrastructure,
whenever a method call is received, and they live only for that method
call. On the next call a new object is created.
2. Singletons - when a method call is received, if there is no live
object, a new one is created. And every next method call (from any
client) will either hit the same object, or if its lifetime expires, a
new one will be created.
This all happens when you use RegisterWellKnown... or config file
registration.
Now, when you manually create and expose the objects, they are neither
SAOs, nor CAOs. I'll try to explain, making comparison with the SAO/CAO
naming, starting with SAO Singleton, as a base one for factory patterns
only serverside):
1.
FactoryObject myfactory = new MyFactory();
RemotingServices.Marshal(myfactory, "MyFactory.rem");
with this, now all clients hitting the url ".../MyFactory.rem" will hit
the same myfactory objects. I.e. it behaves like a SAO Singleton.
2.
class MyInternalSinglecall
{
public string DoSomething(string s)
{
return "Received: " + s;
}
}
class MySinglecallEntryPoint : MBR
{
public string DoSomething(string s)
{
MyInternalSingleton obj = new MyInternalSingleton();
return obj.DoSomething(s);
}
}
When a client hits the exposed MySinglecallEntryPoint object, it creates
always a new internal object to serve the request.
As you see, this example does not make any practical sense, but thats
exactly how Singlecalls are working, except that here your code is the
one which creates the working instance, and when using WellKnown... this
is done by the system itself.
3.
Standard factory pattern. Your factory method creates a new object,
which is returned to the calling client. This is like CAO done by
remothing. Just here your method is the one who creates the returned
object.
Now, look at this factory object:
class MyFactory : MBR
{
static ClientObject cao;
public ClientObject GetNewObject()
{
if (cao == null)
cao = new ClientObject();
return cao;
}
}
As you can see, even this is a factory, and it returns an object, it
returns always a reference to the same object to all clients. Is it SAO
or CAO?
Or if you move "static ClientObject cao;" somewhere else, in another
class, and other method expose it on an url with Marshal(cao)? Now every
client which hits that url will work with exactly the same object, which
is returned to every client hitting the factory method. Is it SAO or
CAO?
Conclusion: SAO and CAO are only a names for how the server objects are
created and how they are exposed to different clients. You can accept
this naming convention, and still you can provide your own
implementation for creating and exposing the objects to the clients.
All we use CAO as name for an object, which is exposed only to one
client, and is created because this client requested it. If this object
is created by the remoting system itself, or by our code (factory), it
doesn't matter. Important think is only the behaviour.
Same can be said for SAOs, they are accessible on a given url, and are
accessible for all clients.
I do not know how clear was all that :), so please if something is
confusing, ask.
Sunny