Volunteers gave 5-minute “lightning talks” on five issues, which were then considered as the potential agenda items for discussion:
- Does SOA apply to Cloud service models?
- Vendor-neutral framework for registry/repository access to encourage object re-use
- Fine-grained policy-based authorization for exposing data in the Cloud
- Relation of SOA to Cloud Architecture
- Are all Cloud architectures SOA architectures?
The greatest interest was in the last two of these, and they were taken together as a single agenda item for the whole meeting: SOA and Cloud Architecture. The third topic, fine-grained policy-based authorization for exposing data in the Cloud, was considered to be more Cloud-related than SOA-related, and it was agreed to keep it back for the CloudCamp the following day. The other two topics, SOA and Cloud service models and vendor-neutral framework for registry/repository access, were considered by separate subgroups meeting in parallel.
The discussions were lively and raised several interesting points.
Cloud is a consumption and delivery model for SOA, but Cloud and SOA services are different. All Cloud services are SOA services, but not all SOA services are Cloud services, because Cloud services have additional requirements for Quality of Service (QoS) and delivery consumption. Cloud requires a different approach to QoS. Awareness of the run-time environment and elasticity are crucial for Cloud applications. Cloud architectures are service-oriented, but they need additional architectural building blocks, particularly for QoS. They may be particularly likely to use a REST-ful approach, but this is still service-oriented. Within a service-oriented architecture, the Cloud is transparent to the consumer. The service consumer ultimately should not care whether a service is in the Cloud.
The concept of vendor-neutral access to SOA registries and repositories is good, but it requires standard data models and protocols to be effective. The Open Group SOA ontology has proved a good basis for a modeling framework. Common methods for vendor-neutral access could help services in the Cloud connect to multiple registries and repositories.
The cloud service models – Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) – could be defined as services in the SOA sense, with each of them exposing capabilities through defined interfaces. This would require standards in three key areas: metrics/QoS, brokering/subletting, and service prioritization. Is The Open Group an appropriate forum for setting and defining Cloud customer and provider standards? It has a standards development capability. The key determining factor is the availability of member volunteers with the relevant expertise.