Abstract form

Mutually Dependent Systems

Posted in Architecture, Development, Modeling by Homam Hosseini on March 11, 2010

In this post I am discussing a problem that I have faced several times in the past year. Simplicity is always a goal in design as it saves resources during development and maintenance. But it’s not always clear which design is simpler. Sometimes a seemingly complex design turns out to be simpler to develop, maintain and extend.

In a master-slave architecture, assume S1 is the master. It produces one or more tasks form a given job and transfers them to S2 (the slave); S2 does the tasks and return the results back to S1. S2, the slave, depends on S1, the master.

If the next time that S1 assigns a task to S2 it uses the information that exists in the result of a previous task that had been assigned to S2 then S1 also depends on S2 and we have a mutually dependent couple.

In our terminology the systems are mutually dependent if and only if S1 uses the information it gained as a result of a previous task that it had already assigned to S2. It doesn’t matter if S2 has completed the previous task or not, but it should have reported something to S1 that is useful for S1 for a next assignment of a task to S2.

If S1 is only using the fact that S2 is busy or free then we don’t call it a mutual dependency. S1 must use the information that is generated by processing a task at S2. For example a MapReduce system is not a mutually dependent system.

Why is it important? You should have already guessed that S2 is the name of a class of slave systems that work with S1. There could be many instances of S2. Let’s define a homogenous mutually dependent system as a system that in which all slaves of S1 are in the same class.

Two slaves are of the same class if they share a common interface for communicating with S1.

Now assume that S3 is also a slave for S1. S3 is in a different class other than S2 if either its input or its output interface is different from S2’s.

When designing mutual dependent systems we have to always decide whether to keep the mutual dependencies or to break them by introducing new nodes. It’s mainly a decision over complexity. The other factor that may affect your decision is the swiftness of the system. Introducing a new node will usually reduce the responsiveness.

Breaking the mutual dependency by using S4 node. Note that S3 is another class and uses a different interface to communicate with S4.

For instance a new node must not be added if S1 waits for S2 to return. Generally you should try to keep the number of nodes as small as possible if the operations are not asynchronous.

Homogenous mutual dependency is OK (when the systems are simple and synchronous) but things get much dirtier as we introduce new classes to the system. On the other hand if extensibility is a goal you should try to avoid mutual dependencies.

For a conclusion, use mutual dependent systems in live systems, when a rapid response is required, and try to avoid them by introducing middle nodes if you have many classes of slaves or if extensibility is a goal.

Advertisements

Service Provider Pattern Part II

Posted in Architecture, Coding, Development by Homam Hosseini on May 29, 2009

Read the first part

At first I found it is generally a good advice to store the configuration in a static, read-only property somewhere. And there’s no better place other than the configuraiton class itself:

static MyServicesConfigurationSection _Value;
public static MyServicesConfigurationSection GetValue()
{
   if (_Value == null)
   {
     _Value = (MyServicesConfigurationSection)
        System.Configuration.ConfigurationManager.GetSection("myServices");
   }
   return _Value;
}

Here we assume that we always define the matching element to be “myServices” in the configuration file. It makes sense because it makes it easier for us to find the element in different configuration files. We can always access the value using:

var config = Configuration.MyServicesConfigurationSection.GetValue();

Modularizing is the obvious upgrade we are goging to make to the Service Provider Pattern Part I. I can find three distinct components:

Service-Provider-Pattern-Ar 

  • Service Provider Pattern contains all the logic required by the pattern to work. You alway reference it everywhere you want to use the pattern.
  • Service Definitions is where we define our services.
  • Implementation of the Services contains  concrete classes and implementations of (some of) the services that have been defined in Service Definitions module. In a real application you may end up with many Implementation components each containing the implementation of a one or few number of services.

As before the configuration file of the Host Application maps the definitions (abstract services) to implementations (concrete services).

It’s clear that using this architecture we can have host applications that are hosting different implementations of the services.

Configuring the Services

Till now the only purpose of the configuration file was to store the mapping between the definitions and the implementations. But we can use it in order to actually configure the services. For an example it’s very likely that the FTPFileStorageService that we defined in the previous part, needs a FTP account credential to work. In this case the <add> element (that maps FileStorageService to FTPFileStorageService) may look like:

<add def="MyServiceDefinitions.FileStorageService"
     impl="MyServiceImplementations.FTPFileStorageService,
                                      MyServiceImplementations"
     host="ftp://ftp.wingooli.com" username="wingooloi"
                                         password="password" />

Both the abstract service definition and the concrete implementation can implement IServiceBase interface:

public interface IServiceBase
{
    void Initialize(Configuration.ServiceProviderSettings settings);
}

This interface just has one method, Initialize, that takes a ServiceProviderSettings (the <add> element). We can read the additional attributes of the <add> element using a code like this:

settings.Properties["host"]

The logics in the Service Provider Pattern component automatically call the Initialize method if this interface has been implemented in the definition the  implementation of the service.

Here is the design:

Service-Provider-Pattern

Now our Service Provider Pattern has nothing less than ASP.NET Provider Pattern but it is easier to implement.

Using all these modules we can reduce the code needed to instantiate a service (this code snippet should be placed in the abstract service definition class):

static FileStorageService _Instance;
static object _InstanceLocker = new object();
public static FileStorageService Instance
{
 get {
    if (_Instance == null) {
      lock (_InstanceLocker) {
        _Instance =  ServiceModel.ServicesHelper
                       .GetServiceInterface<FileStorageService>();
      }
    }
    return _Instance;
  }
}

Because it is a repeatable pattern and to make it all more developer friendly, I created a C# code snippet that generates a similar code automatically.

You can download the whole things here.

Dig and Win Islands

Posted in Architecture, Dig and Win by Homam Hosseini on December 8, 2008

One of the most exciting features of Dig and Win is its Islands. Anyone who have ever heard of virtual worlds is familiar with islands concept. The most prominent ones are SecondLife Islands. In general islands are parts of a virtual world (or universe) which are independent to some extend and have some kinds of authority.

In my opinion and in Dig and Win architecture, virtual islands are something more than pieces of lands (codes) surrounded by water (universal infrastructure). Dig and Win Islands are more like “island universes“, the term first used by Kant in describing some kinds of nebulae. These are independent and somewhat isolated ‘complete universes’ living on their own, but are being governed by invariant universal laws.

The formal definition reads:

An Island is an instance of Original Dig and Win running own its own, independent of other parts of the Multi-Island Universe.

At a large scale point of view, Islands are terminals of the Multi-Island Universe and act as interfaces between players and the universe itself.

So what is this “Original Dig and Win” is the immediate question that arises. I am not going to discuss it into the details, but for an analogy Original Dig and Win is like the legacy Win32 codes of Windows server. There are a lot of codes written to wrap these codes into more manageable modules. An Island is not totally made of legacy code, but its core is.

As the name suggests Original Dig and Win is something old, it has not been intended for this code to be part of a virtual world. The way we moved from this stand-alone application to a virtual world is an example of how it is possible to integrate individual software applications in very large networks, such as a virtual world. The key in it most ridiculous way is simple: see the isolated software application as a black box and wrap it into interfaces that facilitate its network communications. If you’re my boss, don’t expect me to incorporate every smaller can into a larger one seamlessly.

I generally enjoyed the efforts, as it showed me how it is possible to extend a business while keeping almost all the old aspects unchanged.

I can’t close my first post about Dig and Win Islands without at least, quoting one of their most significant features:

Islands are independent entities. An Island must be able to live on its own, even if its connections to the universe fail.