| home / programming / csharp / webservices / chap6 / 2 |    [previous] [next] |
|
|
Unlike well-known objects, client-activated objects can have state. A client-activated object is instantiated on the server when the client creates it, and not with every method call.
We can define properties in a client-activated object. The client can set values and get these values back, but we should be aware that every call across the network takes time. For performance reasons, it is better to pass more data with a single method call instead of doing multiple calls across the network.
For client-activated objects the server configuration file must set the tag
<activated> instead of <wellknown>. With the
<activated> tag, only the type attribute with the class and assembly name
must be defined. It is not necessary to define a URL for the remote object because it will be
instantiated by its type. For well-known objects, a URL is required, but client-activated objects
use the type for activation. The .NET Runtime automatically creates a unique URL to the remote object
instance for client-activated objects. The URL that we defined for well-known objects is not unique
for a single instance, but because a well-known instance is newly created with every method call a
unique URL is not required:
<configuration>
<system.runtime.remoting>
<application name="SimpleServer">
<service>
<activated type="Wrox.Samples.MyRemoteObject,
MyRemoteObject" />
</service>
<channels>
<channel ref="tcp server" port="9000" />
</channels>
</application>
</system.runtime.remoting>
</configuration>The client configuration file requires a similar change:
<configuration>
<system.runtime.remoting>
<application name="SimpleClient">
<client url="tcp://localhost:9000/SimpleServer">
<activated
type="Wrox.Samples.MyRemoteObject, MyRemoteObject" />
</client>
<channels>
<channel ref="tcp client" />
</channels>
</application>
</system.runtime.remoting>
</configuration>Using the same code for the server and the client that we used before with the old configuration
files, the constructor of the remote object is just called once for every calling of the
new operator. Calling methods doesn't create new objects.
As we have seen before with well-known objects, we can register client-activated objects
programmatically too. The server has to call RemotingConfiguration.RegisterActivatedServiceType(),
and the client RemotingConfiguration.RegisterActivatedClientType() if we want to create and
register the remote object programmatically. Similar to using the configuration file we have to set the
type of the remote object using this method.
With client-activated remote objects, it is possible to use a non-default constructor. This is
not possible with well-known objects because a new object is created with every method call. We'll
change the class MyRemoteObject in the file MyRemoteObject.cs to demonstrate
non-default constructors and keeping state with client-activated remote objects:
public class MyRemoteObject : System.MarshalByRefObject
{
public MyRemoteObject(int state)
{
Console.WriteLine("Constructor called");
this.state = state;
}
private int state;
public int State
{
get
{
return state;
}
set
{
state = value;
}
}
public string Hello()
{
Console.WriteLine("Hello called");
return "Hello, .NET Client!";
}
}Now, in SimpleClient.cs we can invoke the constructor using the new operator
as can be seen in this example:
RemotingConfiguration.Configure("SimpleClient.exe.config");
MyRemoteObject obj = new MyRemoteObject(333);
int x = obj.State;
Console.WriteLine(x);| home / programming / csharp / webservices / chap6 / 2 | [previous] [next] |
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: February 25, 2002
Revised: February 25, 2002
URL: http://webreference.com/programming/csharp/webservices/chap6/2/4.html
