C# ПІДРУЧНИКИ / c# / MS Press - Msdn Training Programming Net Framework With C#

Activation and Proxies

*****************************ILLEGAL FOR NON-TRAINER USE******************************

The remoting framework supports server-side and client-side activation of remote objects.

Server-side activation means that when a client attempts to access the object, the object is instantiated on the server automatically. Client-side activation, on the other hand, means that the object is instantiated in response to a deliberate activation request from a client.

You can select the best activation model to control the instantiation and lifetime of a remote object.

Methods of Remote Object Activation

Before a client can use a remote object, the remote object must be activated, and the client must obtain a proxy to access the remote object.

You can activate a remote object by calling new or by calling the following methods of the Activator class:

!Activator.CreateInstance

Used to create an object instance

!Activator.GetObject

Generally used to connect to an object that is already running at a specified Uniform Resource Identifier

8Module 13: Remoting and XML Web Services

The Role of Proxies in Remote Object Interaction

When a client activates a remote object, the client obtains a proxy to the class instance on the server. Any interaction with a remote object occurs by reference through the proxy. The proxy object acts as a representative of the remote object and ensures that all calls that are made on the proxy are forwarded to the correct remote object instance. All methods that are called on the proxy are automatically forwarded to the remote class, and any results are returned to the client.

From the client’s perspective, this process is identical to the process of making a local call. Any exceptions that are thrown by the remote object are automatically returned to the client. Because those exceptions are returned to the client, the client can use try/catch blocks around sections of code to trap and handle exceptions.

Server-Side Activation

Server-side activation supports single call and singleton modes of activation.

Single Call Objects

A single call object services only one request. Single call objects are useful in scenarios in which:

!The overhead of creating an object is not significant.

!Objects are configured in a load-balanced fashion.

!State information is usually not needed between calls.

Because single call objects cannot hold state information between method calls, they are sometimes referred to as stateless objects.

Singleton Objects

A singleton object services multiple clients and multiple requests. Therefore, a singleton object can store state information between client invocations. Singleton objects are useful when you want to share data explicitly between clients and method invocations, and when the overhead of creating and maintaining objects is substantial.

Because singleton objects can maintain their state over a prolonged period of time, they are sometimes referred to as stateful objects.

Lease-Based Lifetime

*****************************ILLEGAL FOR NON-TRAINER USE******************************

You can control the lifetime of client-activated remote objects by using a leasing mechanism. When an object is first created, it is given a lease time. When the lease time of the object reaches zero, the object is disconnected from the remoting infrastructure. After the references to the object from within the object’s application domain have been freed, the object may be collected when the next garbage collection occurs.

You can extend the lease on an object by using a number of mechanisms. For more information about extending the lease on an object, see “Lease-Based Lifetime Concepts” in the .NET Framework Software Development Kit (SDK) documentation.

You can use leases to manage the lifetime of remote objects as an alternative to reference counting, which tends to be complex and inefficient over unreliable network connections.

A potential disadvantage of leasing is that the lifetime of a remote object may be extended for longer than is required. However, the advantages of reducing network traffic that is devoted to reference counting and the pinging of clients outweigh the disadvantage of the extended lifetimes of remote objects.

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Because calls to a remote object can cause other objects to be passed across a remoting boundary, you should understand how objects are marshaled in .NET Remoting.

Inside the remoting boundary of the caller, for example, inside a single application domain, objects are passed by reference, and primitive data types are passed by value. Application domains are hard boundaries. Applications running in different application domains share no information, no global variables, and no static fields on classes. As mentioned in Remoting in this module, .NET Remoting is used to communicate between objects in different application domains.

All objects that are instantiated remotely are returned by reference. When a client instantiates a remote object, it receives a proxy to the class instance on the server. All methods that are called on the proxy are automatically forwarded to the remote class, and any results are returned to the client.

The following examples show scenarios where objects are passed across remoting boundaries because of calls to remote objects:

! Object parameters in a method call, such as myObj in: public int myRemoteMethod (MyRemoteObject myObj)

!Object return values of method calls, such as MyRemoteObject instances in:

public MyRemoteObject myRemoteMethod(String myString)

!Objects that result from property or field access of a remote object, such as instances that are accessed in the myNestedObject field of myObj in:

myObj.myNestedObject

All objects in the .NET Framework fall into three general remoting categories: marshal-by-value, marshal-by-reference, and not-marshaled.

Marshal-By-Value Objects

Marshal-by-value objects include value types and classes that are serializable. A copy of such marshal-by-value objects is passed from one application domain to another.

You should use marshal-by-value objects when you need to move the complete state of the object with the execution to the target application domain for performance or processing purposes. In many scenarios, marshal-by-value objects reduce boundary crossing, such as network, process, and application domain roundtrips. Marshal-by-value objects have no distributed identity, and no proxy is ever created to reference them, as shown in the following example:

[Serializable] class Foo1A

{

//. . .

}

To participate in its own serialization when it is marshaled across application domain boundaries, an object can expose the ISerializable interface, as in the following example:

using System.Runtime.Serialization; //...

[Serializable]

class Foo1B : ISerializable

{

//. . .

}

Marshal-By-Reference Objects

References to marshal-by-reference objects are made when the object reference (ObjRef) is passed from one application to another. When the object reference arrives in the remote application, it is converted to a proxy back to the original object. The original object remains in the application domain in which it was created. A marshal-by-reference object’s class must derive from the

System.MarshalByRefObject class.

Use marshal-by-reference objects when an object’s state should remain in the application domain in which it was created and when only references to that object should be marshaled at the time that the object is remoted. For example, make a file object, whose internal representation contains a field that is an operating system handle, application domain-bound. In this case, the operating system handle would not be useful or appropriate in another application domain, process, or computer.

All operations on a marshal-by-reference object are appropriately indirected so that the common language runtime can intercept and forward them. This indirection applies to fields, properties, and methods of marshal-by-reference objects. For this reason, the performance overhead of marshal-by-reference objects is greater than the performance overhead of marshal-by-value objects.

*****************************ILLEGAL FOR NON-TRAINER USE******************************

All remote objects must be registered with the remoting framework before clients can access them. Object registration is usually performed by a hosting application that starts up, registers one or more channels with ChannelServices, registers one or more remote objects with RemotingServices, and then waits until it is terminated.

Note The registered channels and objects are available only while the process that registered them is alive. When the process terminates, all channels and objects that are registered by this process are automatically removed from the remoting services where they were registered.

The following information is required when you register a remote object with the remoting framework:

!The type name of the remote object

!The object Uniform Resource Identifier that clients will use to locate the object

!For server-side activation, the object mode that is required

• The object mode can be single call or singleton.

RemotingConfiguration.Configure("MyHello.exe.config");

RemotingConfiguration.Configure("MyHello.exe.config");

HelloServer obj = new HelloServer();

HelloServer obj = new HelloServer();

*****************************ILLEGAL FOR NON-TRAINER USE******************************

On the client side, a client registers the channel and activates the remote object.

Registering the Channel

A client must first register the channel by calling ChannelServices.RegisterChannel. As previously mentioned in Server Side in this module, the server must first have registered the selected channel.

The following code example shows how to register a TCP Channel:

ChannelServices.RegisterChannel(new TcpChannel());

Important You do not specify a port number when you register the client channel.

Activating Remote Objects

After the client registers the channel, it can then activate the remote object by using GetObject or the new operator. It is important to note that the object is not instantiated when either of these calls is made. Actually, no network calls are generated at all. The remoting framework obtains enough information from the metadata to create the proxy without connecting to the remote object. A network connection is only established when the client calls a method on the proxy.

When the call arrives at the server, the remoting framework extracts the Uniform Resource Identifier from the message, examines the remoting framework tables to locate the reference for the object that matches the Uniform Resource Identifier, and then instantiates the object if necessary, forwarding the method call to the object. If the object is registered as SingleCall, it is destroyed after the method call is completed. For each method that is called, a new instance of the object is created.