Monday, 21 December 2009

The vote on the Service-Oriented Cloud Computing Infrastructure Project OpenGroup

I am seeing the topic of SOA to enable internal and external services to operate in Cloud infrastructures as a key topic particularly in the evolutions of SOA Design time artifacts (service contract, format protocols, portfolio) into Run time Service artifacts (API, Consumer/producer platform) that include the elastic environment specification and the specification form Security interoperability and a specification for dynamic binding and discovery among three key ones I can think of.

I have found in SOA projects that many where locked into a design time specification that was passed to developers who then figured out how to design and build the solution. Much of the web service or API design was either driven by a specific BPM style or Portlet style or more generally driven by a wrapper and service management focus. The production environment and network connectivity has typically been outside the span of a SOA project, typically putting non-functionals and production build and deployment into the area of existing infrastructure or new hardware investment to support a broad availability and utilization target. With active management and transaction level performance management in Service Management tools it is now possible to monitor and optimize individual web service calls and to fine tune network packets and database performance. This means that the goals of service oriented performance and QoS can potentially be modelled and delivered on a transaction by transaction basis.

The evolution of cloud based assets means the "up and down use" of application services can potentially reflect the real-time use of the IT services. The integration of SOA concepts with Cloud is a critical area to elaborate on how this can be done given the reality of the Cloud particularly in IaaS and PaaS is here already. An interesting area is the approach of Cloud vendors to adopt a RDF or own ontology to describe the metalanguage of the Cloud Infrastructure or to use more specific Hypervisor or API Oriented connection specifications.

One area I am hoping the SOA Cloud project will help is to understand how to design applications in an SOA style that could best use a Cloud Infrastructure Environment. My understanding for example in work I conducted with VMware last year on Vcloud and Vapps is that the direction is towards "infrastructure aware applications" as the deconstruction of application functionality is further redefined as types of logic and payload services that are virtualized and "call" cloud infrastructure resources as and when it needs it. Multiplicity functionality is a new concept that enables multiple SOA style services to run simultaneously to process multiple services and scenarios through a distributed cloud infrastructure.

A great example of this I have seen with INTEL Research work focusing on Mobile Cellphone Technology that moves high processing workloads onto a external cloud service provider and returns the result back to the mobile cellphone device. This in effect "virtualizes the CPU and memory power" of the mobile cellphone device to include the external cloud services. Suddenly the cloud makes possible to bring new services and power to a multitude of different devices.

I think the SOCC Infrastructure project will pull existing SOA artifacts and Cloud together and I hope will help define the extensions of SOA to embrace the powerful "infrastructure Services" enabled via cloud. While this area is still evolving in the Cloud Infrastructure and interoperability specification I think the design of a "Cloud contract" will be much enhanced by this project.