1

I am not trying to launch a Microservices vs SOA debate but I find hard to understand the following statement:

"Microservices architecture does not support contract decoupling, whereas contract decoupling is one of the primary capabilities offered within a SOA"

As I know REST contracts can be specified via Open API (ex Swager) or RAML. For transforming messages there are API Mangement tools (like OSB in SOA) where message enhancements or transformation can be done.

So does the above statement makes sense to you ? Can I have other points of view ?

Sources:

https://www.nginx.com/resources/library/microservices-vs-soa/

https://s3.amazonaws.com/ivansalvadori.doctorate/MicroservicesResearch/RichardsMark2015.html#

4

It appears that you're focusing on one specific point in Mark Richard's paper without considering the context that the rest of the paper provides.

Read the following three paragraphs (quoted from the paper). I have highlighted some key points in bold:

SOA is well-suited for large, complex, enterprise-wide systems that require integration with many heterogeneous applications and services. It is also well-suited for applications that have many shared components, particularly components that are shared across the enterprise. As such, SOA tends to be a good fit for large insurance companies due to the heterogeneous systems environment and the sharing of common services—customer, claim, policy, etc.—across multiple applications and systems.

However, workflow-based applications that have a well-defined processing flow and not many shared components (such as securities trading) are difficult to implement using the SOA architecture pattern. Small web-based applications are also not a good fit for SOA because they don’t need an extensive service taxonomy, abstraction layers, and messaging middleware components.

The microservices pattern is better suited for smaller, well-partitioned web-based systems rather than large-scale enterprise-wide systems. The lack of a mediator (messaging middleware) is one of the factors that makes it ill-suited for large-scale complex business application environments. Other examples of applications that are well-suited for the microservices architecture pattern are ones that have few shared components and ones that can be broken down into very small discrete operations.

What the author is saying, in a nutshell, is that SOA is better suited to large, diverse systems with heterogenous components; that is, systems that must talk to each other, but each having differing interfaces and data protocols.

OK, now read the following three paragraphs:

Contract decoupling is the holy grail of abstraction. Imagine being able to communicate with a service using data in a message format that differs from what the service is expecting—that is the very essence of contract decoupling.

Contract decoupling allows services and service consumers to evolve independently from each other, while still maintaining a contract between them. It also helps give your service consumers the ability to drive contract changes, thereby creating a more collaborative relationship between the service and the service consumer.

There are two primary forms of contract decoupling: message transformation and message enhancement. Message transformation is concerned only about the format of the message, not the actual request data. For example, a service might require XML as its input format, but a service consumer decides to send JSON payload instead.

The author's original assertion should now be self evident:

Microservices architecture does not support contract decoupling, whereas contract decoupling is one of the primary capabilities offered within a SOA.

Of course, whether you consider that statement self-evident or not is entirely up to you. It's not clear to me why a microservices architecture would preclude the use of contract decoupling mechanisms, though it's probably true that SOA supports such "middleware" more robustly, or provides such middleware out of the box so that you don't have to write it yourself.

  • 1
    Probably a better conclusion would have been that SOA support better contract decoupling (message transformation and enhancement) due to the middleware solutions it offers (ESB). – Cris Oct 24 '17 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.