Service Oriented Architecture
Service Oriented Architecture (SOA) is an approach to distributed systems architecture that employs loosely coupled services, standard interfaces, and protocols to deliver seamless cross-platform integration.1 It is used to integrate widely divergent components by providing them with a common interface and set of protocols through which they can communicate within what is called a service bus. Over the past few decades, service-oriented architecture has arisen as a new systems architecture paradigm within I.T. as a response to having to build software systems adapted to distributed and heterogeneous environments that the Internet has made more prevalent.
There are many definitions for SOA, but essentially it is an architectural approach to creating systems built from autonomous services that are aggregated through a network. SOA supports the integration of various services through defined protocols and procedures to enable the construction of composite functions that draw from many different components to achieve their goals. It requires the unbundling of monolithic systems and the conversion of the individual components into services that are then made available to be reconfigured for different applications.
Imagine one wanted to build a new web application that allows people to pay their parking tickets online. One could spend years developing a subsystem that functions as a street map, and then another subsystem for dealing with the payments, and yet other for log-in, user authentication and so on. Or I could simply avail of Google’s map service, a payment gateway service from PayPal, and a user log-in service from Facebook. My job then would be to integrate these diverse services by creating some common processes that guide the user through the use of these different services to deliver the desired functionality. Thus, instead of building a system that was based on all my different internal components within my well-bounded piece of software, my new application would instead be built with an architecture that is orientated around services, a service orientated architecture.
Imagine I am a coffee shop owner. My interest is providing customers with food and beverage in a pleasant environment. In order to do so, I need to bring many different things together, from coffee beans and equipment to employees and so on. I need to design a common platform for all these things to interoperate and deliver the final service. But let’s think about this system within the more formal language of SOA. Firstly, each component in the system is providing a service, whether it is the employee pouring the coffee or the chairs on which people sit. We as designers of the system are not interested in the internal functioning of these components because we don’t need that information. We abstract it away by encapsulating it. Only the provider of the service needs to know the internal logic of the component. To us, they are simply services.
Encapsulation & Service Autonomy
When it comes to a customer paying with credit card, they simply swipe their card and input the PIN number. No one in the shop understands how the transaction is actually completed. Only the financial service provider has that information. For the rest of us, it is abstracted away through encapsulation. We may also note that the financial service provider has almost complete control over the logic they encapsulate, at least during the system’s run-time, as is the case for many other components in the system. This is called service autonomy.
Protocols & Discoverability
What we do need to know though, is what function the component serves and how to interact with it. We call this an interface. When one of our new employees picks up a packet of coffee, she knows what it is and how to use it because it has a label. We may also note the big yellow sign above the bin in the corner encouraging customers to dispose of their waste. This is called service discoverability. Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. We might say our bin is broadcasting the availability of its service. Although I have employed a multicultural team of staff, there is an agreement that everyone will speak English when interacting with other staff on the shop floor. This is called a standardized service contract. Services adhere to a communications agreement as defined collectively by one or more service description documents.
As part of my business, I have a network of suppliers and maintenance people. If I need more personnel, I call the recruitment agency and I will have a new employee starting next week. If the shop needs painting, I can call my decorator. If I need more tables, I can buy them. All of these different services are what is called loosely coupled to the system. This means these different modules can join or leave, couple or decouple from the system as need be, thus maintaining their independence. This loose coupling allows for the dynamic provisioning or de-provisioning of resources to maintain an effective systems load balancing mechanism.
Lastly, once my little business is up and running, generating revenue, I might want to start another one or maybe another ten. But this time in, say, the restaurant business or maybe a confectionery. The great thing I notice is that I don’t have to start from scratch each time. I can just extend my insurance contract, order more tables, use the same bank account and so on. This is called service reusability or composability. Because the services are independent of any particular process I compile them into, that is to say, any of the stores I set up, they can be endlessly reused, composed and recomposed into new configurations.
The real value from SOA arrives when we scale things up to the world of complex systems, to the architecture of large enterprises, designing urban environments or even whole economies. Because of its abstraction, the same architecture can underpin our design on the micro level as well as the macro level. We have a set of heterogeneous components. These components might be people of different cultures in a society. They might be different modes of transportation within a city, or they might be different devices connecting to an internet of things platform. We create a generic language that can be used to describe all the components in the system and their service. We create interfaces for the components that translate their local language or functionality into the global language. We give them a descriptor to describe the components functionality, availability, terms, conditions and various other parameters to its coupling and service provision. We create a service bus that integrates these functional components into an entire system, and we create an interface for the end user to interact with the services they need.