soa systems design

59
| 25-06-2012 | Alexander van Trijffel 18-06-2012 Your business technologists. Powering progress © Confidential Service Oriented Architecture Systems Design Alexander van Trijffel

Upload: alexander-van-trijffel

Post on 15-Jan-2015

113 views

Category:

Technology


2 download

DESCRIPTION

Service Oriented Architecture Systems Design Patterns.

TRANSCRIPT

Page 1: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

18-06-2012

Your business technologists. Powering progress © Confidential

Service Oriented Architecture Systems Design

Alexander van Trijffel

Page 2: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel 2

Agenda▶ The network▶ Coupling ▶ Messaging▶ Reliability▶ Services▶ Service

decomposition

Page 3: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Connectivity – The network matters

▶ Common assumptions made by developers and architects in distributed systems

• The network is reliable• Latency isn’t a problem• Bandwidth isn’t a problem• The network is secure• The topology won’t change• The administrator will know what to do• Transport cost isn’t a problem• The network is homogeneous

3

Page 4: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

“The 8 fallacies of distributed computing”

1. The network is reliable2. Latency isn’t a problem3. Bandwidth isn’t a problem4. The network is secure5. The topology won’t change6. The administrator will know what to do7. Transport cost isn’t a problem8. The network is homogeneous

4

Deutsch 94

Gosling 97

Page 5: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling

▶ What is coupling?

– A measure of dependencies

– If X depends on Y, there is coupling between them

– 2 kinds of coupling:

– Afferent (Ca) - Who depends on you

– Efferent (Ce) - On who do you depend

Page 6: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Loose coupling at the systems level

▶ Attempt to minimize afferent and efferent coupling

▶ 3 Different aspects of coupling for systems:– Platform– Temporal– Spatial

Page 7: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect: Platform

▶ Also known as “Interoperability”

▶ Using protocols only available on one platform– Remoting– Enterprise Services/COM+– Datasets over Web Services

▶ One of the 4 Tenets of Service Orientation:– “Share contract and schema, not class or type”

Page 8: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect: Temporal

Service A

Synchronous Call

Waiting Working

Return

Service B

The processing time of Service B affects that of A

Page 9: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling aspect: Spatial

Service A

Service B

Page 10: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling aspect: Spatial

Service A

Service B

Page 11: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling aspect: Spatial

Service A

Service B

Service B

?Can communication

automatically continue?

Page 12: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling solutions

Page 13: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect #1: Platform

▶ XML on the wire.

▶ XSD (schema) describing XML structure

▶ Use standards based transfer protocol like http

▶ Standards based description of message flow– WSDL

Page 14: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect #2: Temporal - 1

Service A Service B

Customer GetCustomerInfo(id)

Calling thread iswaiting for theresult

MakeCustomerPreferred(id)

Save customer as preferred

Bad. Resources are held while waiting.

Page 15: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect #2: Temporal - 2

Resources are held while waiting. Increased load on service B per consumer (impacted by polling interval)

Service A Service B

YieldCustomerInfo(id)MakeCustomerPreferred(id)

Spawn polling thread

Got data?

Data ready

Got data?

Got data?

Save customer as preferred

Data ready butnot passed toconsumer

Page 16: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect #2: Temporal - final

Good. By separating (in time) the inter-service communication and the request handling

Service A Service B

Publish updated customer infoStore data

MakeCustomerPreferred(id)

Save customer as preferred

Page 17: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Coupling Aspect #3: Spatial

▶ Application level code should not need to know where cooperating services are on the network

▶ Delegate communications to “something else”, let’s call it an “agent” for now.– myAgent.Send(message);

▶ But if the application code doesn’t tell the agent which logical destination to send the message to, how would the agent know?

▶ If there was a direct mapping from message type to logical destination, then specifying the type of message being sent/published would be enough

Page 18: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Message Type = Logical Destination

▶ AddCustomerMessage: – Sent by clients to one logical server– Multiple physical servers behind a load balancer if required

▶ OrderCancelledEventMessage:– Published by one logical server

▶ Strongly-typed messages simplify routing

Page 19: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Messaging

▶ Asynchronous: One-way, fire & forget messages

▶ Why messaging?

▶ Reduces coupling– Use XML for platform coupling– Use asynchronous messaging for temporal coupling

▶ Reduces Afferent and Efferent coupling while increasing autonomy

Page 20: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Performance – RPC vs Messaging

▶ With RPC, threads are allocated with load– With messaging, threads are independent– Difference based on blocking nature of communication

▶ Memory, DB locks, held longer with RPC

Throughput

Load

RPC

Messaging

Page 21: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Reliability

▶ When servers crash

▶ When databases are down

▶ When deadlocks occur in the database

Page 22: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

When Servers Crash

DBApp[HTTP] $$ Order

TxCall 1 of 3

Call 2 of 3

Critical Windows Patch

Rollback

Where’s the order!?

Page 23: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

When Deadlocks Happen

TxApp[HTTP] $$ Order

DBCall 1 of 3

Deadlock

ExceptionWrite to log A B

Call 2 of 3

Where’s the order!?

Page 24: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Securing client requests with Messaging

TxQ$$ Order

App

Receive

DBCall 1 of 3

Rollback

Call 2 of 3

Rollback

The order is back in the queue

Page 25: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Calling Web Services

A B C D

WSDB

[HTTP] Invoke

$$ Order

Deadlock

Rollback

Not Rolled back

Page 26: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

MessagingGateway

A B C D

WS

Msg

DB

$$ Order

[HTTP] Invoke

The message won’t be sent if there’s a failure

Page 27: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Durable Messaging

Server

Client

MSMQ

MSMQIncomingOutgoing

Outgoing Incoming

Store and Forward

adds resilience

Page 28: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Message types

Page 29: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Standard message handling

▶ Problem is that service layers get too large▶ Difficult for multiple developers to collaborate▶ Difficult to reuse logging, authorization, etc

Customer Service

void ChangeAddress(Guid id, Address a);

void MakePreferred(Guid id);

void ChangeCredit(Guid id, Credit c);

Page 30: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Exploit strongly-typed messages

IMessagewhere T : IMessage

IHandleMessages<T>void Handle(T message);

Page 31: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Represent methods as messages IMessage

ChangeAddress

MakePreferred

ChangeCredit

Page 32: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Handling Logic Separated

IHandleMessages<T>void Handle(T message);

H1: IHandleMessages<ChangeAddress>

H2: IHandleMessages<MakePreferred>

H3: IHandleMessages<ChangeCredit>

Page 33: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Multiple handlers per message

H1: IHandleMessages<ChangeAddress>

H4: IHandleMessages<ChangeAddressV2>

Authorization: IHandleMessages<IMessage>

▶ Dispatch based on type polymorphism▶ Allows for pipeline of handler invocation▶ As side effect less merge change conflicts

Page 34: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Demo

▶ Sending a and receiving a message using the bus

Page 35: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Messaging patterns

▶ Return Address▶ Correlated Request/Response▶ Publish Subscribe

Page 36: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Return Address Pattern – Send / Reply

2 Channels: one for requests, one for responses

Return Address

Target Service

Return Address

Some time in the future

Initiating Service

Page 37: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Correlated Request/Response

Target Service

Some time in the future

Initiating Service

Ticket (guid)

Ticket (guid)

In the header of the response message, there is a correlation id equal to the request message id

Page 38: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Publish / Subscribe

Service A Service B

Publish updated customer infoStore data

MakeCustomerPreferred(id)

Save customer as preferred

Page 39: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Publisher

Subscriber

Subscribe

Subscriber

Subscriber

Subscriber

Subscriber

Page 40: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Publisher

Subscriber

Subscriber

Subscriber

Subscriber

SubscriberMyEvent

MyEvent

MyEvent

MyEvent

MyEvent

Page 41: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Demo

▶ Publishing an event

Page 42: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

What is a service?

▶ A service is the technical authority for a specific business capability.

▶ All data and business rules reside within the service.

Page 43: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

What a service is NOT

▶ A service that has only functionality is a function, not a service.– Like check if order is valid

▶ A service that has only data is a database, not a service.– Like [create, read, update, delete] entity

Page 44: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Technical properties of a service

▶ A service may have multiple end points

▶ A service may communicate over multiple protocols and transports

▶ A service is responsible for its own availability and scalability

Page 45: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Service deployments

▶ Many services can be deployed to the same box

▶ Many services can be deployed in the same app

▶ Many services can cooperate in a workflow

▶ Many services can be mashed up in the same page

Page 46: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Service Examples

Subscribe to Customer Status Updated

Publish

Customer Status Updated

Save status locally

Subscribe to Product Pricing Updated

Publish

Product Pricing Updated

Save pricing locally

Place Order

Publish Order Accepted

Sales

Marketing

Customer care

Page 47: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Which service owns this page?

Page 48: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Which service owns this page?

None

Page 49: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Same page composition

Server

Product Catalog

Pricing

Inventory

Cross Sell

Page 50: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Amazon.com checkout workflow

Page 51: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Which service owns this flow?

Page 52: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Which service owns this flow?

None

Page 53: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Workflow composition

Shipping

Billing

SalesBilling

BillingShipping

Shipping

Marketing

Page 54: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Autonomous Components

▶ The large-scale business capability that a service provides can be further broken down

▶ A service is composed of one or more Autonomous Components

▶ An AC takes responsibility for a specific set of message types in the service

▶ Autonomous Components are the unit of deployment in SOA

▶ An AC uses the bus to communicate with other ACs.

Is independently deployable, has its own endpoint

Page 55: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Flexibility in deployment

▶ Any number of autonomous components (ACs) can be deployed to a single machine

▶ Or even a single process

▶ Or have a single AC deployed on each machine

Page 56: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Bus TopologyApp

Bus.dll

App

Bus.dll

App

Bus.dll

App

Bus.dll

App

Bus.dll

App

Bus.dll

App

Bus.dll

App

Bus.dll

Page 57: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Scalability

▶ Since each autonomous component maintains its state in the database of its service

▶ We can have a number of servers each running an instance of the same autonomous component

Page 58: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

Scaling out an AC Autonomous Component

Distributor ACI

ACI ACI

Ready

Autonomous Component Instance

on each machine

Page 59: SOA Systems Design

| 25-06-2012 | Alexander van Trijffel

www.atos.net

Atos, the Atos logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud and Atos WorldGridare registered trademarks of Atos SA. June 2011© 2011 Atos. Confidential information owned by Atos, to be used by the recipient only. This document, or any part of it, may not be reproduced, copied, circulated and/or distributed nor quoted without prior written approval from Atos.

Your business technologists. Powering progress © ConfidentialYour business technologists. Powering progress © Confidential

www.atos.net

Atos, the Atos logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud and Atos Worldgridare registered trademarks of Atos SA. July 2011© 2011 Atos. Confidential information owned by Atos, to be used by the recipient only. This document, or any part of it, may not be reproduced, copied, circulated and/or distributed nor quoted without prior written approval from Atos.

Thank You

For more information, please contact :

Alexander van Trijffel