The Service Implementation building block provides a set of distinct capabilities in support of the realization of goals associated with the Service Orientation paradigm. In OMESA, a service is defined as a bounded application that abstracts and encapsulates business functionality making it accessible through a standard endpoint.
Depending on specific design concerns and the combination of capabilities required to address them, OMESA acknowledges two general service implementation styles:
- Semi-Decoupled: Services in this category are commonly those implemented under traditional Service Oriented Architectures (SOA), therefore sharing a common runtime environent. They are usually aimed for a high degree of reusability & composability at the cost of low physical / logical autonomy.
- Fully-Decoupled: This kind of services are highly autonomous and mostly self-contained. They don’t share a runtime environment and are usually associated with architectural styles such as Microservices Architecture and Self-Contained Systems (SCS).
As shown by the following diagram, some of the Core Capabilities are common to both service implementation styles, while others can be much more suitable or even exclusive to one of them.
So for example, “Shared Runtime” would clearly speak of a semi-decoupled solution while “Independent Runtime”, “Choreography” or “Stateless Processing” inequivocally relate to fully-decoupled services. In the case of “Service Stability” or “Domain Driven Design”, while they could be applied to some extent in a semi-decoupled scenario (for example a traditional SOA Architecture), they’re much more suited and thus appear clearly tilted towards the fully-decoupled side.
Within the OMESA model, Core Capabilities can also be mapped to one or more Design Patterns, thus providing a link between abstract and concrete design views.
Identifying the desired and / or necessary Core Capabilities for a particular solution as well as the Design Patterns best suited to realize them is key when it comes to delivering an assertive design and eventually justifying specific implementation choices.
*Although design pattern documentation is not within OMESA’s main concerns, for the purpose of this body of work we have researched and handpicked a set of references which we consider highly qualified. However, both individuals and organizations are encouraged to apply their own criteria when choosing, qualifying and mapping their trusted design patterns to architectural blueprints based on OMESA’s Core Capability model.
Core Capability Definitions
- Orchestration - Supports the automated execution, coordination and management of workflows comprised by complex service composition logic. This capability can be realized by applying design patterns such as: Capability Composition, Process Abstraction, Composed Message Processor.
- Service Virtualization - Promotes loose coupling between application logic providers and its consumers by abstracting physical components through an intermediary service layer. Related design patterns include: Decoupled Contract, Service Facade, Legacy Wrapper.
- Service State Management - Enables a group of semi-decoupled services to transition across stateful / stateless conditions predictably and on-demand, by temporarily deferring service state data to a dedicated repository. Related design patterns include: State Repository, Service Grid, Partial State Deferral.
- Shared Runtime - Provides a centralized design and execution platform where multiple physical / logical resources are made available and shared by whole service inventories. Related design patterns include: Process Centralization, Rules Centralization, Resource Pool.
- Common Data Model - Standardizes data exchange by adopting a common vocabulary which can span one or more service inventories as well as their related applications and data sources. Related design patterns include: Canonical Schema, Schema Centralization, Domain Inventory.
- Service Interaction Security - Focuses on security issues and threats related to data exchange among service providers and consumers. Related design patterns include: Direct Authentication, Exception Shielding, Brokered Authentication.
- Business Logic - Fosters reusability and functional abstraction by isolating, regrouping and expressing solution logic through service capabilities consistent with an underlying business model. Related design patterns include: Agnostic Context, Utility Abstraction, Entity Abstraction.
- Service Mediation - Facilitates service interaction by positioning an intermediary layer, which is able to actively alter the nature of exchanges in order to produce a desired outcome. Related design patterns include: Splitter / Aggregator, Message Router, Resequencer.
- Service Connectivity - Supplies services with pluggable interfaces based on distinct connectivity providers. Related design patterns include: Channel Adapter, Multichannel Endpoint, Messaging Bridge.
- Payload Transformation - Enhances interoperability among heterogeneous service consumers and providers by applying intermediate transformation logic to the data being exchanged. Related design patterns include: Data Model Transformation, Data Format Transformation, Content Enricher / Filter.
- Asynchronous Messaging - Decouples message producers and consumers by leveraging asynchronous delivery channels provided byan underlying messaging framework. Related design patterns include: Point to Point Channel, Pub-Sub Channel, Event-Driven Messaging.
- Service Stability - Promotes overall system resiliency by positioning mechanisms designed tocontain and confine potentially catastrophic breakdowns. Related design patterns include: Circuit Breaker, Bulkheads, Backpressure.
- Choreography - Enables efficient and purposeful service interaction in a global scope without introducing a single-point of control. Related design patterns include: Event Sourcing, Parallel Model, CQRS.
- Stateless Processing - Enhances service scalability by using state offloading techniques to minimize resource consumption while still guaranteeing consistent output. Related design patterns include: Stateless Component, Response Caching, IOStrategies.
- Independent Runtime - Ensures development, deployment and execution independence for a particular set of fine-grained services. Related design patterns include: Containerization, Microservice Deployment, Decentralized Data Management.
- Domain Driven Design - Facilitates the design and development of complex software projects byestablishing flexible building blocks and a common language around a well-defined domain core. Related design patterns include: Bounded Context, Ubiquitous Language, Consumer Driven Contracts.
The following references were used by OMESA exclusively for research and example purposes. Credit due to the respective authors & owners of the content.