>-----Original Message-----
>Hi,
>
>1) a client can activate a remote object by using either :
> - new
> - Activator.GetObject
> - Activator.CreateInstance
> What are the differences/advantages/disadvantages
between the different
> approaches ?
>
>2) What is the difference between server-side activation
and client-side
> activation ?
>
>Any code samples very welcome.
>
>thanks
>
>chris
>
>
>.
>Christian,

"Mike Sheely" <honcho@microag.com> wrote in message
news:042001c35f4a$36edd240$a401280a@phx.gbl...
>
> >-----Original Message-----
> >Hi,
> >
> >1) a client can activate a remote object by using either :
> > - new
> > - Activator.GetObject
> > - Activator.CreateInstance
> > What are the differences/advantages/disadvantages
> between the different
> > approaches ?
> >
> >2) What is the difference between server-side activation
> and client-side
> > activation ?
> >
> >Any code samples very welcome.
> >
> >thanks
> >
> >chris
> >
> >
> >.
> >Christian,
> MSDN provides some excellent sample code (search
> for "Remoting Examples" at MSDN).
> Lets see if I can simplify this issue.
>
> There are two kinds of Server Activation Objects (SAOs);
> Singleton and SingleCall. We will call these "WellKnown"
> objects.
> A Singleton means that the server will allow only one
> instance of this type at any given time for all clients to
> use (share). Methods called by clients will all use this
> single instance (so we don't constantly have to be
> allocating new instances). The drawback is that this
> makes it a poor choice if you have data members (fields)
> in your class that have to be kept for multiple instances
> (because that just won't happen at the server).
> A SingleCall means that each time each client calls a
> class method, a short-lived instance is created to execute
> the method, and then the instance of the class dies. This
> is another poor choice if you have data members that you
> want to keep around.
>
> The other kind of Activation is Client Activation (CAO)
> objects. For this kind of activation, the host will
> create multiple instances of your Remotable classes for
> multiple clients (One client cannot use objects that
> belong to another client). The lifetimes of these objects
> are controled by a LeaseManager who will coordinate with
> the Client Application that is using them. The drawback
> here is that the machine where the host (server/listener)
> is running had better have a lot of RAM and CPU power
> depending on the expected load. These CAO instances are
> typically what you think of under normal programming.
> -----
> Let's say we are writing a program for a small airport
> that wants to keep track of 100 airplanes (the max number
> that it can park in its hangers and on its parkways). We
> would likely have a class named Airplane that we will
> allow 100 instances of, right? And each of those
> instances is unique ("hasA" airplane number assigned by
> the FAA that we want to keep as instance data for each
> airplane).
>
> You could write a normal program (no remoting) that would
> likely keep a collection with a maximum allowed number of
> 100 airplanes that can be on the ground at this small
> airport at any given time. Once the program works, you
> realize that you could market this to many small airports
> and that their "maximum number of airplance" would likely
> not be 100. So, you decide to provide your Airplane
> object to the world as a CAO Remote Object available over
> the internet and you provide it on a server capable of
> hosting 1,000,000 Airplanes before it runs out of RAM.
> And you start selling your Airport Program worldwide.
>
> Pretty soon your program has done well and many Airports
> are running "Christin's Special Airport Management"
> application that uses your server to create the instances
> of each airplane on their facility at any given time.
> These instances, along with their data members would exist
> in memory at your server (host machine). All is well,
> right? Perhaps, perhaps not. Each client (Airport app)
> has many instances of airplanes speciffically allocated
> for their Airport application to use, and everything seems
> fine. Until, suddenly one of those applications needs to
> allocate the 1,000,001st airplane, and your host
> application starts to fail (needing more RAM). As the
> host application at the server machine starts to crash and
> burn, all of your clients Airport applications are losing
> their knowledge of the airplanes currently on the ground
> at their facility, aren't they? I think you would
> suddenly need a good lawyer.
>
> This is a good example of a scalability problem.
> Everything is fine as long as the number of airplance
> stays small. And how would you be able to anticipate
> (forsee) that there might be a need for over a million
> airplances at any given time? This is why you have the
> choices between the different KindsOf Activation and also
> why you must decide where the state (data members) of each
> Airplane should be kept (at the client or at the server).
>
> Obviously this has been an absurd example. We would
> probably be using a database to store state information
> for each Airplane, not RAM memory at the server machine.
> But it should demonstrate the difference between the CAO
> objects and the SAO objects.
>
> IIS and ASP use SingleCall (SAO) for web pages, for
> example. A valid request for a page arrives at the
> server, the server generates that page, delivers it and
> then discards everything related to that page. The page
> exists on the client's browser. If the client changes
> something about that page (like changing a field in a
> form), it will have to make a new request for the server
> to handle. A whole new page must be generated and
> delivered. But those instances of the web page to deliver
> back to the client exist for a very short time, and are
> discarded as soon as they have been deivered.
>
> In Review:
> The two kinds of SAO <wellknown> objects are Singleton and
> SingleCall. Nethier provide a mechanism for storing state
> information about each object. The time spent allocating
> new instances for SingleCall might degrade performance
> under a heavy load (a million hits per second). A
> Singleton instance removes the need for that repeated
> memory allocation and forces all clients to use a single
> instance to provide the methods that the client
> applications can call.
>
> CAO <activated> objects will allow you to host each unique
> instance and its unique data members for each client. It
> might suffer from load problems depending on server
> resources.
>
> My recommendation:
> I keep the "stuff" that is important to me, close to me!
> As a soldier in Vietnam, it would not be a good thing to
> be out on patrol if my M-16 was in the armoury at our base
> camp, would it? That would be risky and foolish. I am
> the client and the base camp is the remote host
> application in this example. However, it might be OK if
> if left my spare pair of boots back in the base camp.
>
> In the same way you must decide where to keep state (data)
> for each instance you will use in your client