By Stefan Wesner

The Service Oriented Knowledge Utility (SOKU) vision expressed in the 3rd version of the Next Generation Grid expert group report anticipated a future where the layered architecture model is replaced by an aggregation of “capabilities” to deliver a complex service. These “capabilities”, called Service Oriented Knowledge Utilities, are expected to be self-describing, discoverable, and provided by different providers. These “capabilities” can be combined and the capabilities mix can be changed as needed. The original text says: “The primary difference to earlier approaches is a switch from a prescribed layered view to a multi-dimensional mesh of concepts, applying the same mechanisms along each dimension across the traditional layers.“ See here for more on this. While the opinion that a layered model has to be considered harmful and is not the perfect solution is not new and the very strict ISO/OSI layered model is often implemented in a more relaxed fashion layered architectures are still dominating the solutions in Service Grids.

Nevertheless abstracting architectures of many Service Grid solutions can be summarized on a high level as shown in the figure below.

The Network is assumed to be only a transport mechanism, the Service Grid middleware layer is the focus of investigation and covers several components responsible for realizing some core function. They are combined to a set of services for realizing infrastructure services such as Service Discovery or packages to realize consumer or provider services such as SLA Management. All these service are combined to applications e.g. by the means of a workflow.

So what is wrong with this solution?

The layered model is trying to split the responsibilities quite strictly in order to allow the design and implementation of the different layers independent from each other. The communication is done via well defined APIs and allow a replacement of them. While this is beneficial from a viewpoint of design and implementation of functionality this leads to a duplication of functionality across the layers and lead consequently to more static solutions. The figure below shows how a non-layered approach could be realized to build a more complex service.

In this view a set of capabilities such as identity, transport, content, access to resources (e.g. computing, storage, …) is combined in a service mix by a virtual aggregated service provider to deliver a service to the consumer. The aggregation is realized with the help of a set of supporting services such as service discovery etc. During the collaboration between this provider and the consumer the service mix can be changed as needed such as new resource providers can be added, new transport mechanisms are added or exchanged and so on. So again what is the difference? Instead of having different identities on the different layers to get access to network, service etc you use a single identity for all “levels”. While the capabilities are of quite different nature (visualized by the different shapes on the left side and the different colors) they support in a similar way (unified shapes on the right side) the aggregation.

So why are layered models still dominating? In order to realize the solution presented above one need a complete virtualisation of services from the different levels, need standardized Aggregation APIs and need capabilities realized as building blocks expecting to be used across the “layers”. Research on this has just started as “Infrastructure as a Service” or clouds are mostly still limited to storage and computing. But without having other core services such as Network Infrastructure as a Service, Identity validation as a Service and so on this vision cannot be realized. A further problem is that while “Everything as a Service” would be there all these services must follow a standardized API and usage model. Activities on this have started in the Cloud Interoperability Forum (CCIF) but still limited to computing and storage resources.

So I think the layered model will not stay forever but for making the SOKU vision a reality enabling a dynamic service mix across the “layers” it will take a bit longer than 2010 as originally anticipated in the NGG3 report. Mostly as the virtualisation concept is still used in a too limited way and need to be extended to a broader context, the possibilities for making services really self-described must become more powerful and commercial virtualisation offers are using non compatible APIs and methods. I think the SOKU vision is still very valid even if has been invented ways before Clouds and Infrastructure as a Service had been there. Looking forward to dynamic world of non layered architectures…