24.09.2004 21:03

.NET Remoting Technology Projection As usual, the communication framework is an implementation of the BROKER pattern [BMR+96]. This, as well as the CLIENT REQUEST HANDLER and SERVER REQUEST HANDLER, form an integral part of the .NET framework, and are also supported by the .NET runtime itself. Each remote object instance has a unique OBJECT ID. Using Visual Studio.NET s debugger, we can look into the state of a remote object instance and see the unique OBJECT ID, called _ObjURI. In case of our PatientManager, it looks like the following:

ABSOLUTE OBJECT REFERENCE. This reference contains several attributes:

among others, it contains the OBJECT ID shown above and the communication information in the form of one or more ChannelData objects. The URL is the same as the one we introduced before, which allows clients to access remote objects: tcp://172.20.2.13:6642 As we shall see later, a remote object can be accessed remotely through several different channels. Channels are communication paths that consist besides other things of a protocol and a serialization format. A channel is connected to a network endpoint with a specific configuration. In the case of TCP, this would be the IP address and the port, here 6642. Channels have to be configured when the server application is started.

are reported using subclasses of System.SystemExcepFor example, if the CLIENT REQUEST HANDLER is unable to contact the server application because of network problems, it throws a WebException or a SocketException (both extending SystemException) to the client, depending on whether a TCP or an HTTP channel is used to access the remote object. To distinguish application-specific exceptions from REMOTING ERRORS clearly, a convention says that application exceptions must not subclass SystemException: instead it is recommended that

24.09.2004 21:03

you use System.ApplicationException as a base class. An example of a user-defined exception follows:

using System; using System.Runtime.Serialization; namespace PatientManagementShared { [Serializable] public class InvalidPatientID: ApplicationException { public InvalidPatientID( String _message ) : base(_message) { } public InvalidPatientID(SerializationInfo info, StreamingContext context): base(info, context) {} } }

Note that the class has to provide a so-called deserialization constructor (the constructor with the SerializationInfo and StreamingContext parameters) and it has to be marked [Serializable], otherwise the marshaling will not work. The exception s body is empty, because we have no additional parameters compared to Exception.

.NET provides two fundamentally different options for activating remote objects: Remote objects can be activated by the server. In this case, a client can just contact a remote object and does not have to worry about its creation and destruction. Remote objects can be created and destroyed explicitly by a client. The lifecycle of these CLIENT-DEPENDENT INSTANCES is thus controlled by a specific client, and not by the server. This section considers alternatives for server-side activation, while the following section examines CLIENT-DEPENDENT INSTANCES more extensively.

24.09.2004 21:03

.NET Remoting Technology Projection .NET Remoting provides the following activation options for server activated objects. We will look at each of those in detail in the following sections: PER-REQUEST INSTANCES are created for each and every method invocation. STATIC INSTANCES can also be used, which have singleton semantics, meaning that there is always at most one instance in each .NET runtime. LAZY ACQUISITION results in a behavior similar to STATIC INSTANCES, but the instances are initialized on demand, whereas STATIC INSTANCES are instantiated manually, typically when the server application starts up. Per-request instances As we described in the pattern chapters, using PER-REQUEST INSTANCES requires remote objects to be stateless, because a new instance is created at each invocation. Developers have to be aware of this restriction, and ensure that remote objects are actually stateless there is nothing in .NET that prevents developers from making PER-REQUEST INSTANCES stateful, possibly resulting in unexpected program behavior. To implement a PER-REQUEST INSTANCE, all you have to do is to specify the SingleCall activation mode when you register the remote object with the Remoting framework. The code to do so in the server application is shown in the following fragment:

namespace PatientManagementServer { class Server { static void Main(string[] args) { RemotingSupport.setupServer(); RemotingConfiguration.RegisterWellKnownServiceType( typeof(PatientManager), "PatientManager", WellKnownObjectMode.SingleCall ); RemotingSupport.waitForKeyPress(); } } }

24.09.2004 21:03