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