This document discusses problems that can arise with service-oriented architectures (SOA) if not implemented properly, as well as presenting an alternative approach. Some key issues mentioned include systems becoming more fragile, higher development and maintenance costs, and services not being reused as intended. The alternative approach presented focuses on autonomy, loose coupling, encapsulation, and using business events to help achieve these goals. It is argued that this can drive business agility while avoiding consistency issues.

1. SOA
This is in response to Jeppe Cramon’s
presentation on “SOA & EDA”

2. 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 worse
Source: Jeppe Cramon

3. 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 higher
To 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.”

4. All these symptoms can be experienced if you
do not understand what you are doing
 Your services are not being reused
In 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.

5. 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)

6. 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

7. Have our mindset changed
over the last 40 years?
Clearly yours has not

8. To be clear – none of the examples
represent in my opinion SOA
The 4 tenets of SOA
1. Services are autonomous
– Encapsulation & Cohesion at a bigger scale.
– A service is autonomous if it doesn’t rely on other services to complete
its job
2. 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

9. 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?

10. 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

11. 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

12. What we have with classic
layered SOA is a HARD
COUPLED
architecture
You have no understanding as to what coupling means

13. 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
Reusa
ble
Servic
e
Reusa
ble
Servic
e
Reusa
ble
Servic
e
Reusa
ble
Servic
e
Reusa
ble
Servic
e
DB
servi
ce
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

14. 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
Contexts
A 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?

15. 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.

16. Loose coupling
Requires good encapsulation and high
cohesion
We of course all know that encapsulation and high
cohesion drive consistency

17. 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?

18. Business Events Messages
and
Business Processes
By 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.

19. Business Events
example
Sales Service
Order
Accepted
Invoicing Service
Retail System
Order
Accepted
Customer
Billed
MessageChannel
We use the Order Accepted event message published from the Sales Service
to drive the Invoicing/Billing of the customer.
The billing part of the process also use Business Events, in this case Customer Billed
Event, 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

20. 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

21. 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