SOA can be defined as an architecture which goal is to achieve decoupling among interacting software agents [1].
From the SOA point of view, systems expose their functionalities as a set of services, typically as a set of Web services. It does not matter which technology platform the system sits on or what development language used [2].
Services are small and discrete units of software that provide a specific functionality that promotes reusability. SOA applies a loose-coupling design principle, which means that each service is an isolated entity with limited dependencies on other shared resources such as databases, legacy applications or APIs. It helps provide an abstraction layer between producers and consumers which promotes flexibility in changing service implementations without impacting consumers [3].
In addition, how does SOA achieves it?
By defining a small set of simple interfaces, encoded with generic semantics that must be universally available for all providers and consumers.
With descriptive messages constrained by an extensible schema delivered through the interfaces, where should be no or little system behaviour prescribed by them. As the scheme provides the necessary vocabulary limitation in the structure of messages, accepting extensible schemas allows the flexibility to change versions of the services without or little impact on consumers.
Each message a consumer sends must contain all necessary information for the provider to process it. This constraint makes a service provider more scalable because the provider does not have to store state information between requests and treat each request as generic. This constraint improves also visibility, because by inspecting one single request, it is possible to figure out its intention. There are no intermediate states to worry about, so recovery from partial failure is also relatively easy. This makes a service more reliable.
Figure 1. SOA
The requests must be idempotent, i.e., even if a request is sent again, it must have the same impact on the producers [1].
Even if we follow all these constraints, implementing SOA is not easy:
- It is difficult to implement asynchronous communication between applications [3].
- It is challenging to implement high data transfers [3].
- Has numerous security vulnerabilities due to process-sharing applications and systems [3].
- Involves complex transaction management in interactions between logically separate systems [3].
On the plus side:
- Provides a natural way to modularize complex systems by integrating services independently of platform and technology [3].
- Promotes loose coupling, helping the interface with legacy systems [3].
- It increases efficiency by allowing applications to be reused, thus reducing cost and development time [3].
- Improves flexibility and scalability because multiple services can be easily developed from the integration of existing applications [3].
- Allows a reduction of costs associated with maintenance [3].
- Enables standards-based interoperability between systems. Provides location independence to access data via any channel such as smartphones, tablets, or laptops [3].
- Allows an incremental approach to be taken, which helps meet customer demands faster by adding new services in response to specific business needs [3].
A SOA implementation addresses the integration problems and brings many advantages, as the ability to build applications faster and more easily, easier maintenance, extensibility and as promotes reusability it lowers the costs.
Ricardo Santos
EAI Consultant and IoT Evangelist at Polarising
References
- Service-Oriented Architecture, http://www.xml.com/pub/a/ws/2003/09/30/soa.html
- Lam, W.: Enterprise Architecture and Integration: Methods, Implementation and Technologies. Idea Group Inc (2007).
- Service-Oriented Architecture and Legacy Systems, http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems
