For server activated objects in remoting, we commonly tend to expose the server remote class to the client in order to build the proxy object in the client. I would say the main goal in remoting is to ensure that the code on the server does not have to be shipped to the client.
My article will explain how to hide the implementation of the server code using broker pattern.
The application contains the sample code for remoting using server activated objects and helps in understanding the broker pattern more. The application uses the TcpChannel with binary serialization.
My target audience are those who are aware of the basic remoting concepts :-)
"Hide the implementation details of the remote service invocation by encapsulating them into a layer other than the business component itself."
The client application (referred as ClientAPP) will invoke the methods from the BrokerInterface as though it is invoking any local interface. However, the methods inside the client interface trigger services to be performed on the remote application (referred as ServerAPP). This is transparent to the client because the remote service object implements the same interface.
The BrokerInterface is a necessary abstraction that makes distribution possible by providing the contract about the service to the client, which the server provides without exposing the implementation details on the client side. Isolation, simplicity and flexibility are the major benefits while using this pattern.
My application uses .NET remoting to retrieve the user details as a DataSet from the server. The following mechanism is used to implement this functionality:
MarshalByRefObject (assembly: RemoteComponents) public class UserManager : MarshalByRefObject,IUserManager
{
public DataSet listUserDetails()
{
//logic for retrieving user details
}
}
The UserManager is a remote enabled class providing a method named listUserDetails(), which returns the list of user details. The logic for retrieving the user details is written here.
ServerAPP) RemotingConfiguration.RegisterWellKnownServiceType(
typeof(UserManager),
"UserDetails",
WellKnownObjectMode.Singleton);
* The activation mode for UserManager is a singleton, so you will have only one instance of UserManager running on the server. If the user details is supposed to change based on any group, then the activation mode can be changed to SingleCall.
BrokerInterface). namespace BrokerInterface
{
public interface IUserManager
{
DataSet listUserDetails();
}
}
This is the code for the extracted IUserManager interface. The implementation for the method �listUserDetails� will be written in the UserManager class deployed in the server.
ClientAPP) location="tcp://localhost:4820/";
IUserManager mgr= (IUserManager)Activator.GetObject(typeof(IUserManager),
location + "UserDetails");
The client program calls the remoting framework method Activator.GetObject() to retrieve a proxy for the UserManager object on the server. The method specifies the location where the object is located along with the type that should be returned.
In this case, you should expect an IuserManager object at the following location: http://localhost:4820/UserDetails. After you have the instance, you can call methods on it as if it were in the same application domain.
userDS=mgr.listUserDetails();When using .NET remoting, you must pay careful attention to the deployment of the application into different assemblies. I repeat, the main goal is to ensure that the code on the server does not have to be shipped to the client.
Assemblies shipped to the client in this application:
Assemblies required in the server:
| You must Sign In to use this message board. | ||||||
|
||||||
|
||||||
|
||||||
