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:
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:
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: