Implementing SOA in the cloud

Implementing SOA in the cloud is cumbersome. It is because no one knows what the implementation and skills someone else has, which particular cloud is targeted and, finally, ‘SOA’ as a term has been largely abused in the industry.

According to SOA standards (from OASIS, OMG and The Open Group), SOA is architecture, first of all. This means that it allows an arbitrary implementation that may or may not utilize particular technologies, for example, Web services or REST. According to SOA Standard Navigation white paper, collectively authorized by OASIS, OMG and The Open Group in 2009, just a use of Web services or REST does not constitute a SOA. Moreover, one architecture may be realized in several different ways.

In SOA, the majority of skills situates in the areas of architecture and design rather than in development. Therefore, any assumption about skills in “SOA implementation” would be nothing more than a speculation. Let us suppose that we have an application that realizes important but complex business logic. We want to utilize this logic for new tasks and, simultaneously, we want to make it a service in SOA sense. Some people (too many, unfortunately) will attach a Web service interface to the application and announce they implemented SOA. Well, it is not true.

First, those people had to verify that the application can handle Web-like flow of requests (what if the application is not really multithreaded?). Then, even if the application is OK with multiple concurrent requests, the attaché Web service will create … the same application with a new Web service interface, nothing more, but this has nothing to do with service-orientation. The application is still not oriented on service and does not adhere to the principles of service orientation.

Alternatively, some people, knowing behavior and information models of the application, create another light-weight application, a real service, which would utilize the application as a resource. This is the service-oriented solution because we have a service in the SOA sense that provides required business capabilities via its resource. However, how all of these relate to cloud? The answer depends on the type of cloud, i.e. IaaS, SaaS, PaaS, etc.

IaaS (Infrastructure as a Service) is not really a service as well as renting is not. The client uses an infrastructure in either its own data center or in somebody’s else data center the same way. Virtualization of HW resources is not a service but a model of utilization. So, IaaS is about ownership of the infrastructure. Even IaaS elasticity does matter to the Client, it is invisible from the client side and the cost paid by the client for IaaS does not change in tact with an elastic expansion or shrinking of IaaS resources; the cost may depend on utilization of the resource regardless their elasticity.

SaaS and PaaS look more ‘services’ at a glance than IaaS. In reality, none of them is a service in the sense of an entity providing certain business functionality and real world effect (OASIS SOA RM & RAF) in line with principles of service orientation. The service, mentioned in the name, is in that someone else takes care of applications and platforms while the applications and, platforms may have no orientation on service at all.

If you prefer treating SaaS as a service, be aware that it is the most tough “service” you ever dealt with in your own SOA implementation. The reason for this conclusion is in ownership again. SaaS is an external service and all your influence on it is in the service contract. If your service contract does not specify access to certain public interface of provided SW application, it may legally deny your requests to this interface. You cannot tune/adjust/modify SaaS, which is a strange situation for IT people. Thus, your SOA implementation skills are applicable here in only three areas:

1. Semantic and ontology integration between SaaS and other systems of yours
2. Service contract, including accessibility, availability, security, recovery and SLA
3. Interaction monitoring and measuring agreed metrics

For PaaS, it is even worse. In addition to the concerns related to SaaS usability, PaaS usually enforces certain design, deployment and management tools that the client of the cloud has to use. This creates lock-in effect, which PaaS providers very much appreciate but you have to avoid by all means. I do not even mention business problems that multi-tenancy can cause to your organization.

Another concern, specific to PaaS and SOA skills is in that your service planned to be deployed on PaaS should avoid using any PaaS specific features. If you do use them, you lose control over your services and become dependent on the unsupervised PaaS resource (feature). However, PaaS tools will do their best to violate your service independence (this is a pure marketing issue).

So, to utilize your SOA implementation skills in cloud, you have to learn and apply a concept of ownership in the service-oriented ecosystem. This is new for technology but you can find all needed the information in the OASIS SOA Reference Architecture Foundation specification.