SOAThis is in response to Jeppe Cramon’s

presentation on “SOA & EDA”

There are problems with SOA

Systems are more fragile

Development and Maintenance costs are higher

Your services are not being reused

You thought SOA would solve your integration problems, but they’ve gotten worse

No one wants to build or maintain services

System performance is worseSource: Jeppe Cramon

All these symptoms can be experienced if you do not understand what you are doing

Systems are more fragile

This is because there are more moving parts and services are shared assets and when changes are needed it impacts/breaks more components

Development and Maintenance costs are higherTo Quote Peter H. : “the second you introduce distributed, you need to leverage infrastructure that addresses network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads within the application tiers etc […] Takes top level talent at the moment, not something all enterprises have access to.”

All these symptoms can be experienced if you do not understand what you are doing

Your services are not being reusedIn SOA reuse happens the other way around, when a new consumer wants to reuse a service, there is a very low probability that the service will be reused as is.

It generally requires some small changes, when you change the service, what happens is that it is the old consumer which reuses the new version of the services, unless you adopt a “compatible versioning” strategy where new versions of services are compatible with older consumers.

All these symptoms can be experienced if you do not understand what you are doing

“You thought SOA would solve your integration problems, but they’ve gotten worse” Well, following what you say, would certainly create a massive

mess with events flying every where and everyone write code to correlate their content world class encapsulation, cohesion and lose coupling

“No one wants to build or maintain services” That’s why you need a dedicated service team It also fit well the architectural paradigm of intent / consistency

with SoR exposing Integration Points

“System performance is worse” Not quite sure about that. I did some measurements on Synapse

for instance and the added latency is less than 50 ms (measured around 10 ms, but just to be safe, I say 50)

If you have arrived at the realization that SOA is a pain and costs too much without enabling business agility or reducing your costs, you are not the only one.

You will have to change your approach to achieve the benefits of

SOA

If only no one would listen to hipsters, pundits and other self proclaimed experts

Have our mindset changed over the last 40 years?

Clearly yours has not

To be clear – none of the examples represent in my

opinion SOAThe 4 tenets of SOA1. Services are autonomous– Encapsulation & Cohesion at a bigger scale. – A service is autonomous if it doesn’t rely on other services to

complete its job2. Services have explicit boundaries– Services should not be too familiar with each other. There’s a clear

boundary to where the responsibilities of each services starts and ends

– Boundaries are made unclear when a service rely on other services to complete its job

3. Services share contract and schema, not class or type– Encapsulation improved. We need not worry about how things are

implemented (languages or platform dependent information)4. Service interaction is controlled by a policy– Controls under which rules/form of technical communication

between services take place (e.g. using encryption incl. algorithm and keys)

Services ensure consistency

Service Interfaces are Intentional

Ok

Whatever

WebServices and in general synchronous integration has nothing to do with real SOA

Some call this pattern for SOA 1.0 to distinguish them selves from the old

approach and the mess it causes

Because “real” SOA is a protocol?

Layered Architectures typically leaves all orchestration to a central manager (ESB) where business processes are coordinated through spaghetti code

(BPEL)I am actually the (pre) author of that figure coming from BPMN. There is no ESB and no BPEL in it, this is actually a collaboration diagram, which I can be credited for pushing into BPMN

BPEL is actually the only technology available today to achieve consistency at a reasonable cost. You simply have no freaking clue as to what you are talking about

These BPEL processes typically break all Service encapsulation as they are data and feature envious

This hurts our coupling an autonomy even further

BPEL is actually the only technology available today to achieve consistency at a reasonable cost. You simply have no freaking clue as to what you are talking about

These past two slides is the reason why I am so mad at Jeppe. It shows that no only he has no understanding whatsoever as to what he is talking about, and he has no restraint in what he is claiming

What we have with classic layered SOA is a HARD COUPLED

architecture

You have no understanding as to what coupling means

Service reuse multiplies our direct and especially indirect

dependencies which creates high coupling

My new Service

that wants to

reuse other

services

Service that is

going to be

reused

Reusable

Service

Reusable

Service

Reusable

Service

Reusable

Service

Reusable

Service

DB service

Another Service that is

going to be

reused

Could please create the same picture with code duplication? Specially the stateful code that is needed for achieving consistency

A Service is

A technical authority for a specific business capability – very similar to Bounded Contexts

The owner of all the data and business rules that support this business capability – like Bounded ContextsA Service is equivalent to a

Bounded Context

When you have 500 apps, can you please show me where the bounded contexts are? There is the “theory” and the practice. Each app is a bounded context?

The more autonomous services are, the more loosely coupled

they are.

Loose coupling is what drives business agility – which is why we wanted SOA in the first place

Yes, we all know that autonomy and lose coupling are synonymous to consistency

The CAR theorem postulates that you can’t have Consistency, Agility and a high degree of Relationality at the same time. You have to pick two.

Loose coupling

Requires good encapsulation and high cohesion

We of course all know that encapsulation and high cohesion drive consistency

Business Events help us achieve autonomy, loose coupling and

encapsulation

Encapsulation - because we don’t need to supply our services internal data (because no on else needs to know them) – internal data will only be accessible through the Services UI (which takes part in a Composite UI)

Events only need to explain WHAT happened and what it relates to and very few business data (which are typically only needed for replication scenarios)And so, how do you do exception handling and roll

back with business events? You emit more message events?Shit happens you know. Where is the context?

Business Events Messages

andBusiness ProcessesBy publishing Events messages from our Services we can communicate

with each other and also drive Business Processes

Events drive business processes? You must be a candidate for the Turing Award.

Business Events example

Sales Service

Order Accepted

Invoicing Service

Retail System

Order Accepted

Customer Billed

Mess

ag

e C

han

nel

We use the Order Accepted event message published from the Sales Serviceto drive the Invoicing/Billing of the customer.

The billing part of the process also use Business Events, in this case Customer BilledEvent, to indicate that its part of the process is completed.

Because we use asynchronous messaging we can still accept orders in the sales service even though the invoicing services is down. The Order Accepted event message will

remain in the Message Channel until the Invoicing Service is ready to process it.

The problem with SOA discussions is that when you take simplistic examples everything works. You need to “scale” these examples, real world stuff, not just PowerPoint Architectures

Please provide end-to-end sequence diagrams including the implementation of the services, which you will discover is best implemented by … an orchestration that waits on the proper events

Domain Events can also be used for data

replication

This is typically used for read-mostly master data that is needed in many

business-domains. This way we avoid having to call a synchronous services to

query the latest value(s)

The response to any business event must be coordinated, Pub/Sub does not work in the business world

Understanding SOA is actually pretty simple

Services provides a normalized interface to the systems of record

They ensure consistency of both the Queries and Command Services serve data from the Systems of Truth They make sure all SoRs are properly updated (or rolled-back) Services call Integration Points on the SoR (not services)

Service interfaces are intentional, they express the intent of the consumer, how this intent is realized is under the control of the service

Technically there are two software paradigms that are essential to SOA Mediation (e.g. Apache Synapse) Orchestration (e.g. Apache ODE)

None of which are part of Jeppe’s presentation, Yes, events are also part of the picture but only to reflect

changes in the SoR when these changes are not “intentional” The response to events is coordinated … by an orchestration