A Simple Gateway - Proxy Pattern

• Download source code - 40.3 KB

Introduction

Here’s an approach I've used a few times to consume similar APIs into an application. A gateway of sorts, if you will. I'll try and keep it as brief and simple as possible. Having a look at the sample code will help you along as well. I also assume that you know something about Reflection and Web services.

Why would you implement such a thing?

Well (hypothetically, of course), imagine you get a third party payment solution that only accepts Visa cards. OK, you've implemented the Visa payment provider. Now, some of your customers would want to pay with MasterCard. And, you'd suspect that someone down the track would like to use Amex as well.

You would be able to add every payment provider into your code as you need, but this will get messy very quickly. Whereas, loosely coupled API wrappers (proxy wrappers, in this example) in a “gateway” will allow you to add and remove payment providers as you please. Even add some business logic that will decide which provider is the cheapest for your users... So, if you'd implemented a “gateway” from the start, adding new payment providers through the duration of your application life is a breeze, well, a lot easier and cleaner at least.

Here’s a quick example of creating an API gateway. I've used two web services in this example, but libraries can be plugged-in in a similar way.

Design

Looking at the image above, I'll briefly go though the entities of the solution. I'll be focusing mainly on the Gateway and API 1 and 2 entities.

• Solution: This would typically be your application's business logic.
• Gateway: The connection between your application and the API wrappers.
• API 1 & 2: These are the wrappers around API Proxy 1 & 2.
• API Proxy: These represent our payment gateway providers. These are the services that we will consume.

The gateway

I am going to go through the gateway first and then the API wrappers, and after that, I'll explain how it all hooks up.

The interface is the part that really gets the gateway together. As shown in the image above, the Gateway and API wrappers both implement the interface. So, let's whack one together.

In my example, I created IGateway:

public interface IGateway
{
   bool ValidateUser(Userobj user);
   string GetUserAddress(Userobj user);
}

I'm using Reflection in the gateway to call the API wrappers. By implementing an interface, we'd know exactly what method to call, parameters to pass down, and what to expect in return.

In this example, I want to validate a user and get his address. Now that we have defined what we need, we can define our interface. Let's add it to the gateway.

public class Gateway: IGateway
{
    IGateway proxy;

    public Gateway(String dllNamePath)
    {
       LoadIGhostAssembly(dllNamePath);
    }

    void LoadIGhostAssembly(String dllNamePath)
    {
       Assembly asm = Assembly.LoadFrom(dllNamePath);
       Type[] typesInAssembly = asm.GetTypes();

       foreach(Type t in typesInAssembly)
       {
          if (t.GetInterface(typeof(IGateway).FullName) != null) 
          {
             proxy = (IGateway)Activator.CreateInstance(t);
          }                       
       }
    }
        
    //IGateway Members
    public bool ValidateUser(Userobj user)
    {
       return proxy.ValidateUser(user);
    }

    public string GetUserAddress(Userobj user)
    {
       try
       {
          return proxy.GetUserAddress(user);
       }
       catch { return "Facility doesn't exist"; }            
             
    }
}

LoadIGhostAssembly is where we get the correct API wrapper to call. My business logic will pass down the Visa or Mastercard library location, depending on which one you want to use. As shown in the diagram above, the API wrappers also implement the IGhost interface. We will instantiate the correct reference and create a direct mapping to the API wrapper's interface methods.

The API wrappers

I've created a new library and added a class that implements my interface. Now, I will consume my desired web service (called WebServiceMasterCard and WebServiceVisa in the sample code), and match it to my interface methods.

public class Proxy : Global.IGateway
{
   #region IGateway Members

   public bool ValidateUser(Global.Userobj user)
   {
      try
      {
      ProxyWebServiceVisa.localhost.Service1 apiProxy = 
        new ProxyWebServiceVisa.localhost.Service1();

         return apiProxy.CheckUser(user.UserID);
      }
      catch { return false; }
   }

   public string GetUserAddress(Global.Userobj user)
   {
      ProxyWebServiceVisa.localhost.Service1 apiProxy = 
        new ProxyWebServiceVisa.localhost.Service1();

      return apiProxy.UserAddress(user.UserID, user.FirstName, user.LastName);
   }

   #endregion
}

Repeat this for every payment provider you want to add to your gateway.

The glue

This is how I would call the gateway from my application:

UserGateway.Gateway gateway = 
    new UserGateway.Gateway("c:\\temp\\ProxyWebServiceMasterCard.dll");

gateway.ValidateUser(user)
gateway.GetUserAddress(user)

As you can see, I call the gateway and pass down the desired service I need. As long as all the API wrappers have implemented the proper interface, you can add as many as you wish, even take some out. I hardcoded the location of the library, but I usually add it to an XML, database or common directory, so the code wouldn't need to be recompiled every time I need to add a service to the gateway. Once you've specified the library you want to use, the gateway will create an instance of it by using Reflection, and with the method mapping, you can call any method you desire.

And presto, create as many API wrappers as you wish, as long as they implement your interface and your gateway will recognise them.

Update: This is also an example of the Proxy Pattern implementation, which I unknowingly implemented at the time of conception. Please look at Proxy Patterns for more details.