OASIS, the XML open standards body, is quickly establishing a very powerful leadership role in the Cloud standards arena as well.

This includes standards like TOSCA, for Cloud orchestration and therefore a foundation for Cloud Service Brokering, KMIP for unifying enterprise encryption Key Management across these multiple Cloud providers, and SAML for federated Cloud Identity, also for joining up disparate Clouds.

Also new to this mix is ‘CAMP‘ – Cloud Application Management for Platforms, which will focus on developing standards at the PaaS layer.

With participation from key Cloud players such as Rackspace, Redhat and Oracle, this will put in place open standards for portability at the layer app developers are working, so it will provide a huge foundation for advancing the industry.

Another brewing standards group is ‘PACR’, which will identify how all of these different individual efforts can be united into one overall program for Government Cloud Computing – Read more here in the launch mode announcement.

A good explanation of both is the intersection between the two, highlighted by this material from the Canadian Government in the development of their GC Community Cloud program, where they describe relevant PaaS considerations such as:

“In addition to the IaaS and PaaS services, shared applications will also be provided as part of a Software as a Service (SaaS) set of offerings. Examples include a shared eMail service or a shared Collaboration service. These applications will reside within the same shared domain as the shared PaaS set of services. This will enable SaaS applications to leverage the shared PaaS services to the greatest extent possible (ie. for SaaS applications to be hosted on the PaaS services.”

This is part of a broader ‘GC Community Cloud’ program which defines an overall multi-tenant ‘Federal Cloud’ architecture, to encompass Shared Corporate Applications -

A multi-tenant application environment for their breadth of enterprise applications, like Oracle, SAP and Microsoft, used for their core business processes like PAY, and also their common IT requirements, like email and collaboration.

As described they are starting to see these as PaaS layer items, setting them up for SaaS delivery scenarios for these major applications too.

“It should be noted that any applications offered as Software as a Service (SaaS), as further defined in Section 2.5, would leverage the shared PaaS services and therefore would be “collocated” within the same shared domain.

This will allow SaaS applications to leverage PaaS services to the greatest extend possible, thereby helping to reduce their cost. A shared-instance architecture (depicted in Figure 18) is contrasted with the virtualized multi-instance architecture depicted in Figure 21 below. In the latter approach several clients share a single server, but with a virtual server (i.e. virtual machine) dedicated to each. In this fashion, each client has their own instance of both the operating system (OS) and platform software (e.g. web server software, application server software, database server software).”

By “collocating within the same shared domain” the SaaS application is therefore private to the organization rather than being a public web service. With this organization being government this means it could be any number of collaborating agencies who do want to access the Software as as Service model, but in a more controlled manner.