Service-Oriented Architecture 

Find the complete course at the Si Network Platform → tinyurl.com/yc...
Service Oriented Architecture or SOA for short, is an approach to distributed systems architecture that employs loosely coupled services, standard interfaces and protocols to deliver seamless cross-platform integration. It is used to integrate widely divergent components by providing them with a common interface and set of protocols for them to communicate through what is called a service bus. In this video we discuss the use of SOA as a new architecture paradigm ideally suited to the design of complex systems.
As we have discussed in previous sections the structure and make up to complex engineered systems is fundamentally different to that of our traditional engineered systems which are homogenous, well bounded, monolithic and relatively static, our complex systems are in contrary, heterogeneous, dynamics, unbounded and composed of autonomous elements.
Modelling and designing these new complex engineered systems requires intern a alternative paradigm in systems architecture, our new architecture will need to be able to deal with the key features to complex engineered systems that we discussed in previous sections.
Firstly it will need to be focus on services over the properties of components. It will also need to be focused upon interpretability and cross platform functionality to deal with a high level of diversity between components. So as to deal with the autonomy of the components it will need to be flexible, distributed and what we call loosely coupled. Lastly It will also need to employ a high level of abstraction to be able to deal with the overwhelming complex of these systems.
Over the past few decades a new systems architecture paradigm has emerged within I.T. called Service Orientated Architecture. It is a response to having to build software adapted to distributed and heterogeneous environments that the internet has made more prevalent and thus is an architecture paradigm that fits the design of complex systems well.
Service orientated architecture, S.O.A. or SOA for short, is an approach to distributed systems architecture that employs loosely coupled services, standard interfaces and protocols to deliver seamless cross platform integration. It is used to integrate widely divergent components by providing them with a common interface and set of protocols for them to communicate through what is called a service bus. Because SOA originally comes form software development lets take an example from I.T.
Imagine I want to build a new web application that allows people to pay their parking tickets online. Well I 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 login, user authentication and so one. Or I could simply avail of Google’s map service, a payment gateway service from Paypal and a user login service from Facebook, my job then would be to integrate these diverse service by creating some common process that guides the user though the use of these different services to deliver the desired functionality,
Thus instead of building a system that was based around 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.
Now lets take an example outside of I.T. to illustrate its more generic relevance. Imagine I am a coffee shop owner, my interest is in providing customers with food and beverage in a pleasant environment, in order to do this I need to bring many different things together, from coffee beens to equipment to employees and so on. I need to design some common platform for all these things to interoperate and deliver the final service. But lets 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.
So 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.
Learn about the Systems Innovation Network on our social media:
→ Twitter: bit.ly/2JuNmXX
→ LinkedIn: bit.ly/2YCP2U6