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
Broker Pattern – Initial View
"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.
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:
- The server implements the broker interface and
public class UserManager : MarshalByRefObject,IUserManager
public DataSet listUserDetails()
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.
- Creating the listener (assembly:
* 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
- Method declaration in broker interface (assembly:
public interface IUserManager
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.
- The client retrieves an instance of the broker interface (assembly:
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.
- The client calls a method on that proxy interface object which invokes the server functionality.
Points of Interest
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: