Udi Dahan - Avoid failed SOA

Services
Buisness components
Autonomous components

A 2 year product development project lifecycle compresses into one hour
Business
Archiecture
Technology

"Tenets of service orientation" does not give much practial guidance for developing successful SOA solutions.

Refers to the Microsoft service classification hiearchy as "way up into the ivory tower".
- Process services
- Activity services
- Entity services

Described a "as is" architecture with service to service to service call between modules, that leads to bad performance and issues with technology like the number of threads, memory and locks and how these affect eachother.

The core issue: The synchronous communication = Tight coupling at runtime

Solution: Move to pub/sub
At first, this seems very strange since we have point to point communicaion (service to service calls). There is no one to many in the business process or the solution.

(Udi displayed some fun slides in this section with Yoda"talking" about solutions to our problems, hope to get a copy and re-use this idea)

Pub/sub in practice:
- Let modules subscribe to interesting events from other solutions, act on these events and store the impact for the subscriber locally at the subscriber module
- The events happen over a long period of time
- The process is what emerges from the cascading events, not something you plan

The business wants to have this flexibility - "When this happens (event published) do this (act on subscribed event)"

This is Event Driven architecture - the way the world works.

We realise: We cannot talk about services without talking about the events they publishes.
SOA and EDA are twins..

Minimize duplex request/response.

Services are not about providing services (they don't serve), they just are.

Services, contracts and pub/sub.
The Publisher defines the contract of the Event (message) - what you publish - you own.

Endpoints and buiness are connected.

More than one service in a business component can (and will) subscribe to the same events.

Create autonomous components within, as scale out happens within an autonomous component.

Retorical question: Does this not violate the DRY principle? It seems like we are duplicating logic?
(have to write more about this later)

This architecture allows for applying more infrastructure to targeted parts of the solution, and

Conclusion in the end: This approach complies with the "Tenets of service orientation" and we have real SOA

see more on http://www.UdiDahan.com


My takeaway from this session: This is very interesting stuff, and I really would like to look more into this approach. I think we have major issues in our internal "SOA efforts" and this might be a part of the to-be solution.