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.

Why make an advergame for Hyzonia?

Posted in Architecture, Business, Coding, Development, Internet by Homam Hosseini on August 14, 2009

We have been working on a few cool features of Hyzonia in the past weeks. Hyzonia is a next generation internet ad service. Like traditional ad services Hyzonia receives advertisements from advertisers and distribute them in websites. But the ad materials in Hyzonia are not in the form of traditional banner or text ads. The ads would be placed inside games, in a way that players would interact and engage with the promoted subjects. This kind of games is being called an advergame. I don’t want to dig into the marketing stuff, but it worths mentioning that one interesting feature of Hyzonia is that it makes it easier for advertisers to utilize the power of advergaming, for less, as Hyzonia is providing a rich set of ready-to-use advergames. Using Hyzonia customers do not need to pay big moneys to interactive software companies to make and host an advergame as part of their online campaign.

We already have built a number of  favorite games, but Hyzonia is extensible by nature, meaning that it is easy to create an advergame for Hyzonia or integrate an already built game into it. Like almost every big web business we know, we found it is crucial for Hyzonia to be extensible and customizable. Hence we spent the last few weeks on making final touches on the first version of our APIs, improving security and testing it all by making sample games.

It’s no myth that most succesful indie developers are game makers. If you have some good ideas, you may find your two-week project shining on the top lists in Xbox Live or Apple Store.

In comparison with those programs, in Hyzonia you will start earning from the moment your game is added in the system. It would be based on a revenue sharing model, so as long as your game is attractive for promoters there would be some campaigns active in some instances of your game and a revenue stream for you. On the other hand contrary to Miniclip or Pogo, Hyzonia is not a single game portal, your game eventually will be displayed in our publishers’ websites. Hyzonia is a service that provides the infrastructure needed for this communication among advertisers, publishers, and developers to happen.

Currently in addition of standard Web Service interfaces we are providing .NET libraries that encapsulate all the basic functionalities that an advergame in Hyzonia platform should support. One exciting news is that you don’t need to make everything from scratch using Hyzonia APIs, but the required functionalities of an advergame in Hyzonia have been designed in a way to make it possible to take virtually any game, wrap it inside a shell (we call Island) and have it added in Hyzonia. The .NET libraries that we are shipping as part of the API have all the functionalities needed by this shell.

Because of its service oriented architecture, Hyzonia advergames (Islands) could be anywhere in the internet. But currently we are only activating the games that have been hosted physically in our datacenters, although exactly like a banner ad (hosted let’s say by DoubleClick) they could be displayed on other websites.

Obviously not any game can be converted into an advergame. This is another issue that we are adderssing it in the guidelines that will be released alongside the APIs.

A thousand words: Hyzonia connects developers, advertisers and websites.

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.

Service Provider Pattern, Part I

Posted in Architecture, Coding by Homam Hosseini on May 20, 2009

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

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.