soa and event driven architecture (soa 2.0)

99
Jeppe Cramon – Partner in TigerTeam ApS AANUG Conference September 2013 SOA & EDA

Upload: jeppe-cramon

Post on 08-Sep-2014

9.942 views

Category:

Technology


10 download

DESCRIPTION

A historic view on software integration on how we've failed with our current approach to SOA (also know as SOA 1.0). We look at the problem, what to do about them using Events and the changes that we need to apply to our design philosophy and architecture to really obtain loose coupling, reuse (or replaceability) and a reactive system.

TRANSCRIPT

Page 1: SOA and Event Driven Architecture (SOA 2.0)

Jeppe Cramon – Partner in TigerTeam ApS

AANUG ConferenceSeptember 2013

SOA & EDA

Page 2: SOA and Event Driven Architecture (SOA 2.0)
Page 3: SOA and Event Driven Architecture (SOA 2.0)

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

Page 4: SOA and Event Driven Architecture (SOA 2.0)

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

Page 5: SOA and Event Driven Architecture (SOA 2.0)

Let’s take a trip back in time

Page 6: SOA and Event Driven Architecture (SOA 2.0)

And look at how we could do business

Page 7: SOA and Event Driven Architecture (SOA 2.0)

Sales Department

Old style SOA

Ingredients of Blue Satin Dress

Design Department Customer Department Finance Department Fabric Department

The Customer

Create Sales Order

Get Fabric Status and Size

Get Fabric PriceGet Cus

tomer

Details

?

Page 8: SOA and Event Driven Architecture (SOA 2.0)

This is slow

Page 9: SOA and Event Driven Architecture (SOA 2.0)

We are not selling enough!!

Page 10: SOA and Event Driven Architecture (SOA 2.0)

Sales Department

Old style SOA II

Ingredien

ts of B

lue Sati

n Dress

Design Department Customer Department Finance Department Fabric Department

Create Sales Order

Get Fabric Status and Size

Get Fabric PriceGe

t Cus

tom

er D

etai

ls

Reply

Page 11: SOA and Event Driven Architecture (SOA 2.0)

We need to speed things up!

Hackel walks between desks? Way too slow.

Page 12: SOA and Event Driven Architecture (SOA 2.0)

We need to speed things up!

He needs to call So we make sure thathe can

Actually, call a lot!

Page 13: SOA and Event Driven Architecture (SOA 2.0)

We need to speed things up!

But Hackel still have to wait Even if we get creative

Page 14: SOA and Event Driven Architecture (SOA 2.0)

We need to speed things up!

Something needs to be

done!!

Page 15: SOA and Event Driven Architecture (SOA 2.0)

Speed up even more!

Lets get an automatic switchboard!

Page 16: SOA and Event Driven Architecture (SOA 2.0)

Speed up even more!

New technology, same problem

Even if we get creative again

Page 17: SOA and Event Driven Architecture (SOA 2.0)

Or do things Async

So Hackel can send request to Ingeborg and Kresten

which can respond to Hackel when they’ve got an

answer

But even that doesn’t scale well, there’s still only one Ingeborg and Kresten

Page 18: SOA and Event Driven Architecture (SOA 2.0)

Speed up even more!

So Kresten and Ingeborg adds more staff

Page 19: SOA and Event Driven Architecture (SOA 2.0)

Scalability is expensiveSales Department

Design Department Customer Department Finance Department Fabric Department

Coordinator Hackel

Page 20: SOA and Event Driven Architecture (SOA 2.0)

Same problem different technology

Data Storage

Data Storage

Data Storage

FinanceService

DataService

DesignService

Hackel CoordinatorService

Hackel CoordinatorService

Sales Order Service

Sales Order Service

Customer Customer

FabricService

CustomerService

Data Storage

Client

Process Service layer

Activity Service layer

Data Service layer

Aka. Layered SOACaching to Solve

latency problems?

Page 21: SOA and Event Driven Architecture (SOA 2.0)

Resemble much?

Page 22: SOA and Event Driven Architecture (SOA 2.0)

Now back to the story…

• Scaling up Sales requires scaling up other departments relatively much

• People cost money and why have 9 Finance people for every 10 sales people just to answer questions about pricing

• There’s got to be a better way to handle this• And there is

Page 23: SOA and Event Driven Architecture (SOA 2.0)

Sales Department

Event Driven SOA and local caching

Ingredients of Blue Satin Dress

Design Department Customer Department Finance Department Fabric Department

The Customer

Create Sales OrderCusto

mer Deta

ils

Change

dFabric details and stock

Status for Satin Updated

Price for Satin

Changed

Page 24: SOA and Event Driven Architecture (SOA 2.0)

Scalability is cheaperSales Department

Design Department Customer Department Finance Department Fabric Department

Page 25: SOA and Event Driven Architecture (SOA 2.0)

This is just the beginning

Page 26: SOA and Event Driven Architecture (SOA 2.0)

Have our mindset changed over the last 40 years?

Page 27: SOA and Event Driven Architecture (SOA 2.0)

Paper work, file cabinets and manual workflows

Page 28: SOA and Event Driven Architecture (SOA 2.0)

Next step was automating paper forms(aka. The birth of CRUD)

Page 29: SOA and Event Driven Architecture (SOA 2.0)

Database integration

Page 30: SOA and Event Driven Architecture (SOA 2.0)

Enterprise Application Integration (EAI)

Page 31: SOA and Event Driven Architecture (SOA 2.0)

WebServices to the Rescue?

Page 32: SOA and Event Driven Architecture (SOA 2.0)

ESB’s the the Rescue?

Page 33: SOA and Event Driven Architecture (SOA 2.0)

ESB Reality

Page 34: SOA and Event Driven Architecture (SOA 2.0)

I’ve got a cheaper solution

Page 35: SOA and Event Driven Architecture (SOA 2.0)

To be clear – none of the examples represent in my opinion SOA

The 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 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 job3. 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)

Page 36: SOA and Event Driven Architecture (SOA 2.0)

What we’ve seen is just old EAI wine on new SOA bottles

S O A

Page 37: SOA and Event Driven Architecture (SOA 2.0)

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

Page 38: SOA and Event Driven Architecture (SOA 2.0)

Layered Architectures typically leaves all orchestration to a central manager (ESB)

where business processes are coordinated through spaghetti code (BPEL)

Page 39: SOA and Event Driven Architecture (SOA 2.0)

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

envious

This hurts our coupling an autonomy even further

Page 40: SOA and Event Driven Architecture (SOA 2.0)

What we have with classic layered SOA is a HARD COUPLED

architecture

Page 41: SOA and Event Driven Architecture (SOA 2.0)

But what about reuse?• Layered SOA has typically been recommended because it increases reuse (at the

expense of a hard coupled architecture)• The thesis is that the more we reuse, the faster we will be done• But the thesis rest on the false assumption that writing code is the most expensive

part of a project– Not all code takes the same amount of time to write. Some code is very trivial while other

code is very hard to write• The real money and time consumers on any project are:

– Figuring out what the customer needs– The time it takes for the customer to figure what they really needed and the resulting rework– Meetings– Integration work, databases, webservices – Fix bugs– Debugging– Deployment– Test– Ship

Failed?

Yes

No

The more dependencies we have, the worse and more expensive this becomes

Page 42: SOA and Event Driven Architecture (SOA 2.0)

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 servic

e

Another Service that is going to be reused

Page 43: SOA and Event Driven Architecture (SOA 2.0)

Can’t we just avoid Services and make one big application?

Page 44: SOA and Event Driven Architecture (SOA 2.0)

Retail Domain

InvoicingSubdomain

Product Catalog

Subdomain

Shipping Subdomain

Sales (Order) Subdomain

Inventory Subdomain

Pricing

Page 45: SOA and Event Driven Architecture (SOA 2.0)

One Domain Model to Rule them All?

Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on

everything else

Page 46: SOA and Event Driven Architecture (SOA 2.0)

One big model to capture it ALL?

….…..…..

….…..…..

….…..…..

….…..…..

Page 47: SOA and Event Driven Architecture (SOA 2.0)

Result: Our queries get messy

The Query of Despair

Page 48: SOA and Event Driven Architecture (SOA 2.0)

ONE MODEL TO RULE THEM ALL

ONE MODEL TO FIND THEM

ONE MODEL TO BRING THEM ALL AND IN THE DARKNESS BIND THEM

Page 49: SOA and Event Driven Architecture (SOA 2.0)

The database determines our scalability

Page 50: SOA and Event Driven Architecture (SOA 2.0)

And databases often scale poorly

To solve the performance problems for a few, you have to upgrade it all

Page 51: SOA and Event Driven Architecture (SOA 2.0)

Do not design for locality and try to distribute

Design for distribution, take advantage of locality

Page 52: SOA and Event Driven Architecture (SOA 2.0)

Alternatively we can use Read replicas

Master Slave SlaveSlaveSlave

Read

Update

You’re now eventually consistent

Page 53: SOA and Event Driven Architecture (SOA 2.0)

Or introduce caching…

Read

Update

What’s your synchronization mechanism?

?

Page 54: SOA and Event Driven Architecture (SOA 2.0)

Many perspectives on data

Customer

Retail System

Pricing

Inventory

Sales

Product

Unit PricePromotional PricePromotion End Date

Stock Keeping Unit (SKU)Quantity On Hand (QOH)Location Code

PriceQuantity OrderedName

The lifecycle for Data is VERY important!

Forecasting?

Page 55: SOA and Event Driven Architecture (SOA 2.0)

Smaller models & clear data ownership

SalesProduct

ProductIDNameDescriptionQuantity Ordered…

Sales

InventoryProduct

ProductIDSKUQOHLocation Code… Inventory

PricingProduct

ProductIDUnit PricePromotional Price…

Pricing

DDD:Bounded Context

SOA:Service

Retail System

Shared Entity identity

Page 56: SOA and Event Driven Architecture (SOA 2.0)

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

Page 57: SOA and Event Driven Architecture (SOA 2.0)

What a Service is NOT

• A service with only functionality (and no data) is a FUNCTION– Like: check if order is valid

• A service that only has data is a DATABASE– Like: CRUD of an entity

This is typically seen in a lot of layered SOA usages where a function calls a function that calls a function that calls a database

Page 58: SOA and Event Driven Architecture (SOA 2.0)

Autonomy becomes the next (and biggest) problem

Can you rely on others?

Page 59: SOA and Event Driven Architecture (SOA 2.0)

Data Layer

Service Orchestration issue

Data Access Layer

Service Layer

Interface/Display Layer

System CSystem BSystem A

UI

Service Service

DAL DAL DAL

Schema Schema Schema

Local transactionspanning all

modules

Service

Page 60: SOA and Event Driven Architecture (SOA 2.0)

Service autonomy

Service B Service C

Service A

System XService A

System Y

Service B Service C

System X

Slow/unreliable networkDifferent SLASlow system

Page 61: SOA and Event Driven Architecture (SOA 2.0)

Orchestration using synchronouscommunication and local transactions

System CSystem BSystem A

UI

Service Service

DAL DAL DAL

Schema Schema Schema

B:Service() call C:Service() call B:DAL() call A:Service() commit()

Service

Page 62: SOA and Event Driven Architecture (SOA 2.0)

Solution for when going distributed?

Can’t we just distributed transactions?(XA / 2 phase commit)

Page 63: SOA and Event Driven Architecture (SOA 2.0)

Distributed Transactions…. Oh my

Sales system

Sale

Update customer status (e.g. Gold customer)

Bookkeeping

Deliver goods

Deliverysystem Deliveries

Customer/CRM system Customer

SAPBookkeeping

CompletePurchase

TransactionCoordinator

TransactionalResource

Request-to-Prepare

Commit

Prepared

Done

PreparePhase

CommitPhase

2 Phase Commit

Page 64: SOA and Event Driven Architecture (SOA 2.0)

What’s wrong with distributed transactions?

• Transactions lock resources while active• Services are autonomous– Can’t be expected to finish within a certain time

interval• Locking keeps other transactions from

completing their job• Locking doesn’t scale• X Phase Commit is fragile by design

Page 65: SOA and Event Driven Architecture (SOA 2.0)

Orchestration using synchronouscommunication and without distributed transactions

System CSystem BSystem A

UI

Service Service

DAL DAL DAL

Schema Schema Schema

ServiceB:Service() call C:Service() call B:DAL() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:DAL AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well) commit()

Page 66: SOA and Event Driven Architecture (SOA 2.0)

More of the same clearly can’t be

The answer…

Page 67: SOA and Event Driven Architecture (SOA 2.0)

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

Page 68: SOA and Event Driven Architecture (SOA 2.0)

Loose coupling

Requires good encapsulation and high cohesion

Page 69: SOA and Event Driven Architecture (SOA 2.0)

Return of the SILOS!!!!

Page 70: SOA and Event Driven Architecture (SOA 2.0)

We need SMALL SILOS that SHARE very LITTLE with each other

Sales Pricing InventoryShipping

✕ ✕ ✕

Page 71: SOA and Event Driven Architecture (SOA 2.0)

A silo/bounded-context contains all parts related to it

DB Schema

Domain Services

Application Services

DomainModel

Aggregates, Entities,

Value Objects, Events

Integration Endpoints

(REST, SOAP,

Pub/Sub)

User Interface

Silo

Page 72: SOA and Event Driven Architecture (SOA 2.0)

A silos parts are not limited to deployment at a single location

Subdomain

User Interface

Integration Endpoints

(REST, SOAP,

Pub/Sub)

Domain Services

Application Services

Aggregates, Entities,

Value Objects, Events

DB Schema

Units of individual deployment

Page 73: SOA and Event Driven Architecture (SOA 2.0)

What should our silos share?

Bounded Context

Page 74: SOA and Event Driven Architecture (SOA 2.0)

Degrees of coupling

UI

UI

Service

ServiceData

Data Events

Events

Page 75: SOA and Event Driven Architecture (SOA 2.0)

Composite UI’sRetail System

Sales Pricing Inventory

Web/Applicationtier

Background servertier

Storage tier

Composite UI

UI LayeredApplicationData Access Layer

Read

mod

el

Writ

e m

odel

✕ ✕

Remember

Layers != Tiers

Page 76: SOA and Event Driven Architecture (SOA 2.0)

Composite UI - exampleContext:

Book ISBN-10 0-321-12521-5

Page 77: SOA and Event Driven Architecture (SOA 2.0)

Composite UI - HTML

#DIV – BookReviews

#DIV – BookImage

#DIV – BookTitleAndAuthor

#DIV – BookPricing

#DIV – BookAvailability

#DIV - Header

#DIV - Body

Page 78: SOA and Event Driven Architecture (SOA 2.0)

Composite UI

Page 79: SOA and Event Driven Architecture (SOA 2.0)

The Service owns it UI in all Contexts and for all Composite UI’s

Not just for HTML clients

Page 80: SOA and Event Driven Architecture (SOA 2.0)

Invoice Composite UI example

InvoiceHeader

Order:ShippingInfo

Invoice:NextInvoiceNu

mberInvoice:Data and Due

date

Order:RelationInformation

Ord

er:It

em-Q

ty

Prod

uct:

Item Product:

DescriptionOrder:

Item-Unit-Price

Order:Item-Total-Price

Order:Total

Billing:Balance

All Services participate at the UI level for

each individual Item in the

Order

Page 81: SOA and Event Driven Architecture (SOA 2.0)

When won’t a Composite UI make sense?

For certain types of UI’s that built outside of the organization, e.g. customer specific netbank apps and mobile banking application we need to provide a synchronous integration API that will allow them to integrate with the business domains without having to coordinate with the business domains UI team.

The integration API could be built using both a REST* and/or a SOAP approach.

* It’s not such a distant thought to see a Composite UI part as a REST resource with a rendering matching the requested MimeType encoding.

Page 82: SOA and Event Driven Architecture (SOA 2.0)

That covers data presentation

What about transactions?

Page 83: SOA and Event Driven Architecture (SOA 2.0)

Next Step – Event Driven Architecture

Page 84: SOA and Event Driven Architecture (SOA 2.0)

Why Events?

Page 85: SOA and Event Driven Architecture (SOA 2.0)

Synchronous calls lowers our Fault tolerance

• When servers crashes• When databases are down• When deadlocks occurs in the database– Do you retry?

With synchronous RPC style Services interaction we loose business data. There’s no automatic retry and idempotence is often an after though.

Page 86: SOA and Event Driven Architecture (SOA 2.0)

Cure: Messaging

• Message based communication is asynchronous and thereby breaks temporal coupling

• Messages can be exchanged between services over a message channel

• The Message channel is responsible for delivering the message(s) to the relevant parties (consumers). If something goes wrong, the message will be put back on the Message channel (rollback) and will be resent later

Page 87: SOA and Event Driven Architecture (SOA 2.0)

Let’s make the implicit explicit!Old wisdom seems to have been forgotten. Let’s introduce:

Business EventsWhich:• Signal that something has happened• Closely aligned to the Domain Model• Are handled by a messaging system• They are in the past tense:

– CustomerBilled– ParcelShipped– CustomerCreated– ReviewCreated– CommentAdded– CommentDeleted

Page 88: SOA and Event Driven Architecture (SOA 2.0)

Business Events as Messages

A Business Event can be transferred over a message channel, such as a Queue or a Topic, in

many different formats

Page 89: SOA and Event Driven Architecture (SOA 2.0)

Business Event as XML Message<OrderWasAccepted> <CustomerId>50D1F244-ABBC-4EC7-BDCA-E4934C124A89</CustomerId> <OrderId>C199322A-01F1-4E56-918E-7A63529F8FA3</OrderId> <ShippingAddress> ... </ShippingAddress> <BillingAddress> ... </BillingAddress> <Items> <Item ProductId="4CD22C4B-600C-4477-B5BF-48ABDEE4DA61" Amount="100" AmountUnit="Pieces" UnitPrice="100,10" UnitCurrency="EUR"/> <Item ProductId="56E6BD19-660C-464A-9120-100DAF579855" Amount="10" AmountUnit="Litres" UnitPrice="56,95" UnitCurrency="CHF"/> </Items></OrderWasAccepted>

Page 90: SOA and Event Driven Architecture (SOA 2.0)

Business Event as JSON Message{

EventType: "OrderWasAccepted",CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89",OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3",ShippingAddress: { ... }BillingAddress: { ... }Items: [

{ ProductId: "4CD22C4B-600C-4477-B5BF-

48ABDEE4DA61",Amount: "100", AmountUnit: "Pieces", UnitPrice: "100,10",UnitCurrency: "EUR"

},{

ProductId: "56E6BD19-660C-464A-9120-100DAF579855",

Amount: "10", AmountUnit: "Litres", UnitPrice: "56,95", UnitCurrency: "CHF"

}]

}

Page 91: SOA and Event Driven Architecture (SOA 2.0)

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)

Page 92: SOA and Event Driven Architecture (SOA 2.0)

Business Events Messagesand

Business Processes

By publishing Events messages from our Services we can communicate with each other and also drive Business Processes

Page 93: SOA and Event Driven Architecture (SOA 2.0)

Using Business Events to drive Business Processes

Sales Service

Shipping

Invoicing

Sales

CustomersM

essa

ge

Chan

nel

The sales fulfillment processing can now begin…

Online Ordering System

Web Shop(Composite

UI)

Invoicing Service

Shipping ServiceOrder

Accepted

Event

Page 94: SOA and Event Driven Architecture (SOA 2.0)

Business Events example

Sales Service

Order Accepte

d

Invoicing Service

Retail System

Order Accepte

d

Customer Billed

Mes

sage

Cha

nnel

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.

Page 95: SOA and Event Driven Architecture (SOA 2.0)

Introducing Choreographed Processes

Sales ServiceOrder

Accepted

Invoicing Service

Shipping Process Manager

(Saga)

Shipping Service

Retail System

Mes

sage

Ch

anne

l

Order Accepte

d

Order Accepte

d

Customer Billed

Customer Billed

Order Ready

for Shipmen

t

Order Ready

for Shipmen

t

Works as a Finite State Machine

(WorkFlow)handling the life cycle of Shipping

and thereby forms a very central new

Aggregate in the System

Page 96: SOA and Event Driven Architecture (SOA 2.0)

Process Managers

• Process Managers are essential to the coordination and monitoring of long running processes.

• They work as a Finite State Machines (WorkFlow) which handling the life cycle of Process (e.g. Shipping an Order) and thereby forms a very central new Aggregate in the System

• They can include manual steps/person intervention• Sometimes these Process Managers belong naturally

within a specific Subdomain and other times they are truly and thing by themselves and often form new Subdomains that way

Companies often derive their competitive advantages from their Processes.

A Process Manager allows you coordinate Business Processes on the basis of Events

Page 97: SOA and Event Driven Architecture (SOA 2.0)

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)

Page 98: SOA and Event Driven Architecture (SOA 2.0)

Event Based ReplicationSubdomain Z

Repository

Repository

Z DataSubdomain Y

Service Repository

Message channel

Event ReceiverY Event Receiver and Local Cache Builder

Y DataCache

Y Events

Y Events

Page 99: SOA and Event Driven Architecture (SOA 2.0)

Questions?@jeppec on [email protected]

@TigerTeamDK on Twitterhttp://tigerteam.dk