Service-Oriented Architecture Pattern
In a service-oriented architecture, independent components are implemented as services, which provide specific functionality. Services are combined at runtime to define the software system’s behavior. For this to work, service consumers must be able to locate and use services without knowing about implementation details behind the services they use.
Service-oriented architectures (SOA) can be implemented in many ways. Traditional SOA relies heavily on message buses and communication via SOAP. Modern SOA encourages the use of fine-grained microservices connected by lightweight message protocols such as HTTP.
Complex organizations will often turn to SOA to design large software systems in which different departments own different pieces of the system. SOA allows each department to work independently within their area of expertise and hide information systems but also provides broad access to those subsystems without compromising design integrity. See the table.
Here is an oversimplified example diagram showing a single view of a service-oriented system. Service-oriented architectures are complicated and involve many architectural components. This diagram shows two services attached to the service registry. Services must check the registry to look up connection information for other services they want to call.
Category | Component & Connector |
Elements |
Service—An independently deployable unit, which provides functionality behind a well-defined interface. Service registry—List of all available services, used by a service to discover other services to use. Message system—The specific element type depends on the flavor of SOA and other design decisions around service communication. Some examples include SOAP, REST (representational state transfer, usually over HTTP), gRPC,[9] and asynchronous messaging. |
Relations | Varies depending on the constraints in the SOA system. With the smart endpoints, dumb pipes approach popularized by Netflix, calls might be the only relation. If your SOA system uses asynchronous messaging, publish and subscribe might be the relations in play. |
Rules for Use | Services have no knowledge about the implementation details of the services they use. Services must discover other services via an external component, either a service registry or message bus in the case of asynchronous message passing. |
Strengths | Promotes interoperability, reusability, and scalability. This is a well-studied pattern with many, many subpatterns defined. |
Weaknesses | SOA systems are distributed systems and include all the complexity that comes with distributed computation. SOA systems have many parts and can be complicated to assemble. Properties that can be handled easily at design time in other patterns are a runtime concern with SOA. For example, it’s impossible to know the version of an SOA system without knowing what services were running at a snapshot in time. Availability, reliability, and performance are inhibited by this pattern. |