Click here to Skip to main content
Click here to Skip to main content

.NET Remoting Using Broker Pattern

, 23 Feb 2005
Rate this:
Please Sign up or sign in to vote.
.NET remoting using Broker pattern.

Sample Image

Introduction

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 Smile | :)

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."

Sample Image

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.

Functionality

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 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.

  • Creating the listener (assembly: 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.

  • Method declaration in broker interface (assembly: 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.

  • The client retrieves an instance of the broker interface (assembly: 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.

  • The client calls a method on that proxy interface object which invokes the server functionality.
    userDS=mgr.listUserDetails();

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:

  • ClientAPP
  • BrokerInterface

Assemblies required in the server:

  • ServerAPP
  • BrokerInterface
  • RemoteComponents

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Thoths
Web Developer
United States United States
"Variety is the spice of life", I always believe in this in whatever I do.
 
I started my IT career back in 99 as faculty. I love those moments, when I use to educate oracle for a group of account students. Perhaps the best moment in my IT life till day. Now currently doing my services for accenture, chennai facility.
 
I'm strong admirer of C# and C++.
 
I do blog at http://spaces.msn.com/members/thotatri

 

Comments and Discussions

 
GeneralGood one PinmemberAshish Basran15-Nov-06 9:14 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140721.1 | Last Updated 24 Feb 2005
Article Copyright 2005 by Thoths
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid