Yesterday, I wrote the article "About Remoting", I feel that some problems have not been clear. Later, I saw some documents and books, and I finished it, even if I continued.
In fact, I found that the main problems are still concentrated on the client activation mode. I want to talk about the difference between the client activation mode and the server-side activation mode in the code implementation. These two modes are not very different in the server listener. The article in front has been very clear, mainly the client program. In order to make the concept unfamiliar confusion, I will mention the client activation mode, with activated; server activation mode, with WellkNown.
First, from the method provided by VS:
Wellknown mode: Activator.getObject () method. Its return value is an object instance of the specified type in the method parameter.
ServerRemoteObject.iserverObject ServerObj
=
(ServerRemoteObject.iserverObject) Activator.GetObject (
Typeof
(ServerRemoteObject.IgRverObject),
"
TCP: // localhost: 8080 / serviceMessage
"
);
ActiVated mode: There are two methods: 1, static method: removeConfiguration.registerActiVatedClientType (). This method returns the value of Void, which only registers the remote object in the client. The specific instantiation also needs to call the constructor of the object class.
RemotingConfiguration.registerActiVatedClientType
Typeof
(ServerRemoteObject.ServerObject),
"
TCP: // localhost: 8080 / serviceMessage
"
); ServerRemoteObject.serverObject ServerObj
=
New
ServerRemoteObject.serverObject ();
2, Activator.createInstance () method. This method creates method parameters specify class objects. It is different from the front portObject () that it is to call constructor on the client, and getObject () is just a subject, and the creation instance is done at the server side. The CreateInstance () method has a lot of overload, I am focused on two commonly used. 1) Public static object createInstance (Type Type, Object [] args, object [] ActivationAttributes); Parameter Description: TYPE: The type of object to be created. Args: Array with parameters, sequence, and types of parameters to call constructor. If Args is an empty array or a space reference (Nothing in Visual Basic), the call does not have a constructor for any parameters (default constructor). ActivationAttributes: An array that contains one or more properties that can participate in activation. The parameter args here is an Object [] array type. It can pass parameters in the constructor to create objects. From here, you can get a conclusion that the remote object class passed by the WellkNown activation mode can only use the default constructor; and the ActiVated mode can customize the constructor.
The ActivationAttributes parameter is usually used in this method to transfer the URL of the server. Suppose our remote object class ServerObject has a constructor:
ServerObject
Stringpname,
String
Psex,
int
Page)
{Name = PNAME; SEX = PSEX; AGE = Page;}
Then the implementation code is:
Object
[] Attrs
=
{New Urlattribute ("TCP: // localhost: 8080 / serviceMessage")}
;
Object
[] OBJS
=
New
Object
[
3
]; OBJS [
0
]
=
"
Wayfarer
"
Objs [
1
]
=
"
Male
"
Objs [
2
]
=
Twist
ServerRemoteObject.ServerObject
=
Activator.createInstance
Typeof
(ServerRemoteObject.serverObject), OBJS, ATTRS;
It can be seen that the OBJS [] array is passed is the parameter of the constructor.
2, Public Static ObjectHandle CreateInstance (String asmblyName, String TypeName, Object [] ActivationAttribute;
Parameter Description:
askMBLYNAME
Will find named
TypeName's name of the assembly name. in case
AssemblyName is an empty reference (Visual Basic
Nothing, search for the assembly being executed.
Typename
The name of the preferred type.
ActivationAttributes
An array of attributes that can participate in activation.
The parameter statement is at a glance. Note that this method returns the value of the objectHandle, so the code is different from ::
Object
[] Attrs
=
{New Urlattribute ("TCP: // localhost: 8080 / eChomessage")}
ObjectHandle Handle
=
Activator.createInstance
"
ServerRemoteObject
"
,
"
ServerRemoteObject.ServerObject
"
ATTRS); ServerRemoteObject.serverObject Obj
=
(ServerRemoteObject.serverObject) Handle.unwrap ();
Then, this method is actually called the default constructor. ObjectHandle.Unwrap () method is to return to the packaged object.
Note: To use Urlattribute, you will need to add: use system.Runtime.Remoting.actiVation;
Through these code comparisons, we can also get unfortunate conclusions: For Activated activation mode, whether using a static method or using the CREATEINSTANCE () method, you must instantiate the object in the client call constructor. In this way, the remote object we provide at the client will not only provide only an interface, and there is no type of implementation. In the WellkNown mode, instantiation is done at the server side at the client only with getObject (). So the client we only provide an interface is enough. So for Activated mode, we must provide two identical remote objects DLLs on the server and client, which is really frustrating. Is there any other way to achieve it? In view of its implementation principle, the answer is obviously negative. I have read the article on MSDN, the only feasible solution is to use the factory methods mentioned above. It is to be noted that this method is a method of simulating ActiVated mode using WellkNown mode.
The foregoing says that the server-side remote object provides two interfaces. An interface is the interface of the remote object to be transmitted, one is the factory interface. There must also be a factory class to implement a factory interface, providing a method of creating a remote object instance.
public
Interface
IServerObject
{Person getPersonInfo (String Name, String SEX, INT AGE);
public
Interface
IServerObjFactory
{IServerObject CreateInstance ();
public
Class
ServerObject: MarshalByrefObject, iServerObject
{Public Person getPersonInInfo (String name, string sex, int agent) {Person Person = new person (); person.name = name; person.sex = sex; person.age = age; return.age;}
public
Class
ServerobjFactory: MarshalByrefObject, iServerobjFactory
{Public iServerObject createInstance () {return new serverObject ();}}
And the client, only the interface is available.
public
Interface
IServerObject
{Person getPersonInfo (String Name, String SEX, INT AGE);
public
Interface
IServerObjFactory
{IServerObject CreateInstance ();
Then we activate the mode in the server side with WellkNown,
//
Pass the object;
RemotingConfiguration.registerWellkNownServiceType
Typeof
(ServerRemoteObject.serverobjFactory),
"
ServiceMessage
"
WellknownObjectMode.singlecall; note that the SERVEROBJECT class object is not registered, but the ServerObjFactory class object.
Client:
ServerRemoteObject.iserverObjfactory ServerFactory
=
(ServerRemoteObject.iserverobjfactory) activator.getObject (
Typeof
(ServerRemoteObject.iserverObjFactory),
"
TCP: // localhost: 8080 / serviceMessage
"
ServerRemoteObject.iserverObject ServerObj
=
ServerFactory.createInstance ();
First use getObject () to return to the factory interface, then use the interface object to call the factory's method createInstance () to create the iServerObject object.
Maybe someone will be wondering, here is Wellknown mode, why is it actiVated mode? This is the case, in essence, it is a WellkNown mode. However, since we use the factory to create an instance, it feels that it is a specific remote object instance in the client. Therefore, I said this is a method of calendering.
Ok, write here, I think it is clear. But Remoting's implementation is far more than this, and there are many advanced complex things we have not used. For example, custom channels, custom MarshalByReferenceObject derived class, lifecycle management, custom agent. I can't figure out these things. If you understand, I hope to write something.
