Creating Extensible and Abstract Layer

Introduction

Abstraction and Extensibility is an important factor in modern day frameworks. If you are part of any framework team or developing a library that will be used by multiple divisions of your organization or community you will appreciate what I am talking about.

We don't want to develop a reusable framework library for a particular use case and later find that component not usable or not fitting in another scenario. When developing a framework/library that is targeted to be used by multiple divisions, there are many challenges involved. We should build what the applications would use in a normal scenario to fulfill their business requirement. On the other hand we cannot dictate them to use what we have developed as an out-of-box functionality. The gist is most of the teams should be able to use it as out-of-box feature, on a need basis due to dynamic/changing business requirement they should be able override, extend or plug their own functionality into the framework. When it comes to override the default functionality, we don't want to change the endpoints : i.e. interfaces. Changing interface leads to breaking the endpoints.

So we have two problems at hand :

We need to provide flexibility to change our default functionality (out-of-box feature).
At the same time, we don't want to break the interfaces so that we don't end up breaking the existing code.

This article gives an overview of how we can solve the above two issues and yet provide a robust extensible and abstract layer.

Extensible and Abstraction

Extensible framework allows the consumers to extend the default functionality provided and at the same time they don't break the existing code. Abstraction provides an opaque layer to the consumer who is not bothered about what's going on the other end of the world but still be able to accomplish the task that he wishes.

The Logical architecture

Following diagram depicts the high level logical view of the system.

Service Consumers

The consumers are the end users or external applications or requests originated from a web service etc. Consumers are the ones who are interested in access a service. They accomplish this by interacting with Service Fascade. The consumers will interact with the Service Fascade using Request-Response objects.

Service Fascade

The Service Fascade is the layer that shields the consumers from accessing the actual service directly. This layer acts as the entry point and routes the message to the actual service implementation that the consumer would like to call. The service router will intercept the message from the consumers, based on the Request, routes the call to the actual service.

Services

Services are at the granular level and perform the actual logic of a task or activity or a business logic etc.

Class Diagram

The following diagram shows the class diagram of the solution

The ServiceFacade, the individual Services implement the IService interface and they communicate in a common language using Request, Response objects. This helps the ServiceFacade to call the service and get the job done.

Pros and Cons

Pros

Following are the advantages of this methodology that I am aware of:

Consistent end point from the service provider and consumer point of view.
Extensible, the services can be used as is, default functionality can be overridden, and new services can be plugged in without affecting the Fascade and consumer.
Abstraction, the consumer is totally not aware of internal implementations of the Service Fascade, service, service execution etc.
Ability to perform authentication, authorization logic in a single place.
Ability to route messages to a different service based on pre-built logic, custom logic etc.
Ability to perform cross cut concerns like tracing, instrumentation etc in a single place instead of in all services and all over the framework.
Easy maintenance of the code.

Cons

Following are the pitfalls of this methodology that I am aware of:

Over a period of time the Service Fascade may become bulky handling too many services.

About the Sample Program

The sample program contains two C# projects:

ExtensibleAbstractLayer: class library project
ClientApp1: console client application

How it works

The console client application takes input as command line arguments.
Pass servicename and servicedata as arguments.
Servicename should be the name of the class (service).
Servicedata should be input that the service expects.
When"Base" is passed as servicename and"1" is passed as servicedata, the CustomerBase service will be created and GetCustomerName() method will be called with"1" as argument, the result will be"Robert".