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.

images/example-pattern-service-oriented-architecture.png

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.

Avoid Architectural Mismatch

Architectural mismatch, described in Architectural Mismatch: Why Reuse Is So Hard [GAO95], is a phenomenon that occurs when the assumptions made about how a component will be used conflicts with that component’s current use. In the best case, a system experiencing architectural mismatch will be difficult to develop and maintain. In the worst case, key quality attributes will be unattainable.

Architectural mismatch can occur at the conceptual level when a selected pattern is in direct tension with high-priority quality attributes. For example, if performance is the number one quality attribute, then selecting service-oriented architecture might be a mismatch. Picking the wrong pattern can significantly harm the architecture’s ability to promote required properties.

Architectural mismatch can also occur when the technology selected to implement the system does not align with assumptions laid out in the architecture. For example, if the architecture describes a publish-subscribe pattern, using a relational database as the primary mechanism for message passing would undermine the properties promoted by the publish-subscribe pattern. When a mismatch occurs on my team, we will talk about how we are fighting the framework. To avoid creating a mismatch, choose technologies that match the assumptions made in the architecture.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.141.52