By Bastian Koller

Flexibility, interoperability or adaptability are just some of the well known buzzwords which come across when dealing with Grid or Cloud computing technologies. Even though these technologies are driven from different (end) user and provider groups, at a certain point they all face similar problems.

One of these is the limitation of existing  implementations with respect to their adaptability and extendibility in terms of the logic and capabilities they provide. Looking at the area of business relationships, a prominent example is the use of Service Level Agreements.

Current Cloud Infrastructure Services such as Amazon S3 or EC2 provide SLA capabilities, but in a very simple way.  They give its users the possibility to choose within a pre-defined set of service description the best fitting, but they provide no flexibility at all with respect to the (re-) definition of terms themselves or on how the agreement is reached. When you want to have a service, you can either take it with the pre-defined terms or leave it. There is no alternative.

Looking at current research activities, the aims are different. With the experience from handling Service Level Agreements within the Grid, it is obvious that this simple negotiation approach is needed, but it is not the “casus sui generis.”

Already heavily discussed, the list of potential ways (and by that protocols) how to reach an agreement is manifold and existing solutions are addressing a variety of them, but never all of them. Additionally the extendibility of these solutions is often not addressed adequately.

Imagine a Service Provider X which has installed an SLA Negotiation framework realizing negotiation protocol A (e.g.  Discrete Offer Protocol).  In parallel there is a potential Customer Y which is interested in X´s services, but has installed a framework, providing exclusively multi-phase SLA negotiation capabilities. By being restricted to their respective technologies (and inheriting their limitations), both entities would not be able to enter a business relationship, covering the delivery and usage of a service from X.

Generally speaking, this is only one case out of many.  Looking at the overall lifecycle of a service, it is not only about SLAs, it’s about Security, Workflow Management and many more aspects that might need this enhanced adaptability.

Lets make a mind experiment:

What may be a solution is the split of logic and base functionalities of components and structure the framework  as loosely coupled components, following the SOA paradigm. Coming back to the SLA Negotiation, an SLA Negotiator component providing capability A is in some parts similarly realized as a SLA Negotiator providing B. So why not taking out this base functionality (call it a fragment) and keep this as a stable basis for all further developments and enhance this with mechanisms to adapt this component during runtime with a logical bit.

So in our case, Service Provider X could adapt its negotiation component with logic B and by that enable interoperability with Customer Y. After successful negotiation, the provider could re-configure its component back to A.

Looking at this, there is a definitive need to perform research with respect to adaptability (and by that flexibility). If a solution like discussed in the mind experiment would exist, business relationship handling could be improved and the establishment of those relationships could be enabled, that were not possible before.

It will be a long way, but at the end, such a solution needs to be there or we won´t be able to benefit at a maximum from all the capabilities of the Cloud.

This entry was posted on Monday, January 18th, 2010 at 3:52 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.