Service Oriented Architecture

In the previous lesson, we discussed the monolithic architecture and its limitations. We also discussed why it may not be a good choice for enterprise application development. To overcome those issues, we need to take modular approach and separate the components.

According to Wikipedia,

Service-Oriented Architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. Its principles are independent of vendors and other technologies. In Service Oriented Architecture, a number of services communicate with each other, in one of two ways: through passing data or through two or more services coordinating an activity.

https://en.wikipedia.org/wiki/Service-oriented_architecture#Event-driven_architectures

What are Services?

A service is a piece of code, program or software that provides functionality to it’s requester(client). To provide the functionality, a service may interact directly with the database or talk to another service. Services are requested/consumed by clients via network using mobile, desktop, tablet or any other device. Services are exposed over the HTTP transport protocol as a general practice. However, the HTTP protocol is not a limiting factor, and a protocol can be picked as deemed fit for the scenario.

There are two major roles within Service-oriented Architecture:

  1. Service provider: The service provider is the maintainer of the service and the organization that makes available one or more services for others to use. To advertise services, the provider can publish them in a registry, together with a service contract that specifies the nature of the service, how to use it, the requirements for the service, and the fees charged.
  2. Service consumer: The service consumer can locate the service metadata in the registry and develop the required client components to bind and use the service.

SOA is a modular architecture. It is developed as a collection of services. A typical Service Oriented Architecture looks like below where the services are modular and made available to consumers via an Enterprise Service Bus(ESB). ESB connects all the services together over a bus-like infrastructure and acts as a communication center.

Advantages of SOA

  1. Reusability: Multiple clients can consume the service. This can also be simultaneously consumed by other services. For example, AccountingService is consumed by web and mobile clients. AccountingService can now also be used by the Reporting Dashboard UI.
  2. Stateless: Services do not persist in any state between requests from the client. This means that the service doesn’t know or care that the subsequent request has come from the client that has/hasn’t made the previous request.
  3. Platform independent: SOA allows making a complex application by combining services picked from different sources, independent of the platform.
  4. Scalability: A system can be scaled up, and the SOA can be individually clustered with the appropriate load balancing.
  5. Upgradeability: It is very easy to roll out new functionalities or introduce new versions of the existing functionality. The system doesn’t stop you from keeping multiple versions of the same business functionality.

Limitations of SOA

  1. High overhead: A validation of input parameters of services is done whenever services interact this decreases performance as it increases load and response time.
  2. High investment: A huge initial investment is required for SOA.
  3. Complex service management: When services interact they exchange messages to tasks. the number of messages may go in millions. It becomes a cumbersome task to handle a large number of messages.

In this lesson, we covered Services, Service Oriented Architecture, it’s advantages and limitations. In the next lesson, let’s dive into microservices architecture.

This lesson is part of the course Microservices with C#, .NET Core and Azure. Use navigation on the right.