SOA by the book

Udi Dahan gives a great presentation on common errors of "SOA by the book":

http://www.infoq.com/presentations/SOA-Business-Autonomous-Components

I have taken some notes here:

some skepticism about the term SOA.... "Oriented" means nothing, "Architecture" nobody really agrees on what it means.... only "Service" is left!

Loose Coupling : ok for LC design time, but what about LC Runtime ?

The Tables of the Law:
Services are autonomous
Boundaries are explicit
Share Contract and Schema, not Class and Type
Compatibility is based on Policy

see http://en.wikipedia.org/wiki/Service-orientation

You can end up with extremely complex architectures "everything is a service!" .
Layers on Layers on Layers.
It looks good on PowerPoint, but Hell on Earth.
A simple interaction can trigger zillion of services calling each other.

The entire this is NOT Agile. Any change entails LOTS of changes everywhere.

And if you end up a CYCLE, a service being called twice in an interaction, you are screwed!

Asynchronous invocation only DOUBLE the number of threads blocked.

The longer the interactions last, the more you can have GC problems -> OOM
Long running Transactions generate deadlocks.

Publish Subscribe can alleviate the crazy interdependencies: each service gets a Event notification of the change in other data. No need to ask the price, we are told every time it changes.

SOA is coupled with EDA: Services are coupled with Events.

.... continues ....