Functions Required in the Cloud PaaS Layer to Support SOA

Link: http://organizational-economics.blogspot.com/2011/10/functions-required-in-cloud-paas-layer.html

The Platform as a Service (PaaS)

Whether a Private or Public Cloud is built internally, or contracted for, to support SOA, its the “Platform as a Service (PaaS)” layer will be required to have certain functions essential for the support of SOA-based Composite Applications/Services.

The PaaS Layer is “the second” layer of the US National Institute of Standards and Technology’s (NIST) Cloud Computing Architecture. It is the middle layer of the architecture, between the Software as a Service (SaaS) and Infrastructure as a Service (IaaS). In fact, the PaaS is the first complete actual layer (as opposed to virtual) of the Cloud Computing Architecture. The only actual functions supported by the SaaS are the user interface functions, which will include the security interface(s) (see my post SOA, the User Interface Service Components, Apps, and Validation before Registering).

The PaaS contains all of the functions needed to run the applications (Services), as well as the actual repository containing the code for the application–for Services, the Service Components. For a SOA-based set of applications, there are two functions that they require in the PaaS. First, is the Service Component Registry. The Service Component Registry is a virtual catalog of the location of Service Components. It enables the orchestration and choreography processes to find the Service Components, which create Composite Applications.

Second, the PaaS must have Orchestration and/or Choreography Engines with associate Rules Engine and Rules Repository. I have discuss the difference between orchestration and choreography in my post “SOA Orchestration and Choreography Comparison“. These functions (engines) are based in the PaaS. The rules engine and rules repository enable and supports automated business rules,which, in turn, enables and supports the organization’s policies and standards.

Private versus Public SOA Cloud Architecture

As commonly used, a private cloud is a system within one ownership domain; while a public cloud is a system that crosses ownership domains. In the language of SOA, private cloud is an Enterprise SOA, while a public cloud is an Internet SOA. As I discussed in the post on orchestration and choreography, Enterprise SOA uses orchestration (mainly) to execute its composite applications, while Internet SOS always uses choreography. However, I suspect that most Enterprise SOAs will include both orchestration and choreography, as they will use Service Components outside their ownership domain for occasional ad hoc composite applications; for such things as research and risk reduction.

Another key difference between Private and Public SOA Architectures is that an Enterprise (private) SOA will use an application layer communications system called an Enterprise Service Bus (ESB) to enable the Service Components of the Composite Application to communicate. On the other hand, the Internet (public) SOA will use the Internet to enable the Service Components to communicate. For the Cloud Architecture this means that the PaaS of the private cloud will include ESB functionality, while the public cloud will use the interconnectivity of the Internet provided by the IaaS for these functions.