omesa

Main repository

View project on GitHub

Service Implementation

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:

  1. 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.
  2. 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).

Core Capabilities

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

References

The following references were used by OMESA exclusively for research and example purposes. Credit due to the respective authors & owners of the content.

  • http://soapatterns.org/
  • http://www.enterpriseintegrationpatterns.com
  • https://martinfowler.com/
  • http://www.reactivemanifesto.org
  • https://github.com/Netflix/Hystrix/wiki/How-it-Works
  • http://www.cloudcomputingpatterns.org/
  • http://assets.en.oreilly.com/1/event/79/Stability%20Patterns%20Presentation.pdf
  • https://www.thoughtworks.com/insights/microservices
  • https://12factor.net/
  • https://javaee.github.io/grizzly/iostrategies.html
  • http://coresecuritypatterns.com/patterns.htm
  • https://skife.org