Service-oriented architecture

Service-oriented architecture (SOA) means that you structure your application by decomposing it into multiple services (most commonly as HTTP services) that can be classified as different types like subsystems or tiers.

So by definition : 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

A service has four properties according to one of many definitions of SOA:

  1. It logically represents a business activity with a specified outcome.
  2. It is self-contained.
  3. It is a black box for its consumers.
  4. It may consist of other underlying services.

A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently

SOA can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:

  • Web services based on WSDL and SOAP
  • Messaging, e.g., with ActiveMQ, JMS, RabbitMQ
  • RESTful HTTP, with Representational state transfer (REST) constituting its own constraints-based architectural style
  • WCF (Microsoft's implementation of Web services, forming a part of WCF)

Deployment strategy for services in SOA architecture is very important aspect.

Have you heard of Docker containers? I will probably cover that topic in separate chapter but just know that it a way to put all the software and dependencies into one box called container images.

So a service deployment on to a single docker host is the first step. But we can deploy a service to Docker clustering software (orchestrator) to address scalability and availability challenges.

Docker containers are useful (but not required) for both traditional service-oriented architectures and the more advanced microservices architectures.

Containerization is an approach to software development in which an application or service, its dependencies, and its configuration (abstracted as deployment manifest files) are packaged together as a container image. You then can test the containerized application as a unit and deploy it as a container image instance to the host operating system.

Another example for SOA is enterprise service bus (ESB).

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA).

Put it simply, all customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct consumer service.

Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. This typically occurs through the use of an enterprise message model. The message model defines a standard set of messages that the ESB transmits and receives. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB has to transform the message into a format that the application can interpret

The primary duties of an ESB are:

  • Route messages between services
  • Monitor and control routing of message exchange between services
  • Resolve contention between communicating service components
  • Control deployment and versioning of services
  • Marshal use of redundant services
  • Provide commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service