Homam's Mind

Wednesday, May 20, 2009

Service Provider Pattern, Part I

Read the Second and final part

Hyzonia is made of dozens of services running in many machines and app domains all over the internet. One problem we faced early in designing Hyzonia was the need to have different implementations for the a service and the ability to switch between the implementation as the need arises in the run time.

ASP.NET has already had a well-established Provider Pattern. But soon it turns out that it is not the best solution in our case. It seems ASP.NET Provider Pattern is not that developer friendly especially when you have dozens and increasing number of service definitions; because you have to code a new configuration class, create an abstract class, its implementation and a static helper class and it means you have to write the same methods in at least three places.

I wanted to let our developers to be able to add new services very fast. Here is a description of the provider pattern I came with.

Here I assume that services are stateless singleton objects, that is a true assumption in the context of Hyzonia and most of service oriented applications. That's also true about ASP.NET providers. The main reason lies in the SOA paradigm, as in service oriented architecture we think of an operation as something that when it is given its required input arguments it does all the job and returns a success or a failure message. When a client calls an operation it passed all the job to the service and basically it disconnects and waits until the operation returns. The operations that perform an a business object should perform a meaningful business process. It means that those operations must transfer a business object to consistent state.

It is guaranteed that by obeying such those rules you will have a clear separation between your service/business logic and the clients (that are the users of the services).

How to


For adding a new service you need to create the service definition that is an abstract class. Here as a rule we store the service definitions in a seperate assembly that could be shared among many app domains. For our pattern to work we need to add a static getter member to the abstract definitions, just like what you may do for creating a singleton object. Let's name it Instance, that is a getter-only property of the type of the abstract class itself. It's obvious that we are going to load, instantiate and return the concrete implementation here. Let's talk about it a bit later.

For an example, suppose that we are building a File Storage Service. There's no doubt that the main functionalists of such this service are Storing and Deleting the files. So here is the service definition:
public abstract class FileStorageService {
public static FileStorageService Instance {
get { // I told you, we talk about it later }
}
public abstract string Store(Byte[] bytes, string extension);
public abstract bool Delete(string url);
}

Suppose we have a FTP implementation the service: FTPFileStorageService:
public class FTPFileStorageService : FileStorageService {
//...
}

Now if we want to instantiate the FTPFileStorageSerivce in a host application, we need to modify the configuration file of the host app in a way to relate the service definition to our desired implementation. Here is the way we do it:
<service def="FileStorageService" impl="FTPFileStorageService"/>

Now let's back to where we left our discussion about the static Instance property in the service definition class. We need to somehow read the configuration file, find the active implementation, instantiate and return it here. Here is the code:
static FileStorageService _Instance;
public static FileStorageService Instance {
get {
if (_Instance == null)
{
var name = (typeof(FileStorageService)).FullName;

var myAppConfiguration =
(MyApp.Configuration.MyAppServiceConfigurationSection)
System.Configuration.ConfigurationManager
.GetSection("myAppConfig");

var services = myAppConfiguration.Services;

ServiceProviderSettings config = null;

foreach (var s in services)
{
var serviceConfig = (ServiceProviderSettings)s;
if (serviceConfig.Definition == name)
{
config = serviceConfig;
break;
}
}

if (config == null)
throw new Exception(@"A service mapping is
missed in the configuration file");

var type = Type.GetType(config.Implementation);
_Instance = (FileStorageService)Activator.CreateInstance(type);
}
return _Instance;
}
}

You may want to download a demo project here.

If you're new to .NET configuration you'll find the download a good demonstration for starting working with custom configuration classes.

In the second and the final part of this discussion you'll see how we convert a good idea to a working one. The most obvious issue with the code above is here
System.Configuration.ConfigurationManager.GetSection("myAppConfig")

where we are coupling the abstract class (the service definition) and the configuration of the host application. I'm advocating the idea that service definitions must be and are in nature independent of their host.

I will talk about such these issues and making the whole thing more developer friendly in the next part. We will also add more features and try to make it really like a pattern.

Read the Second and final part

1 comment:

Service Provider Pattern Part II « Abstract form said...

[...] is the obvious upgrade we are goging to make to the Service Provider Pattern Part I. I can find three distinct [...]