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

| 25-06-2012 | Alexander van Trijffel 2

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

decomposition

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

“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

Deutsch 94

Gosling 97

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

Loose coupling at the systems level

▶ Attempt to minimize afferent and efferent coupling

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

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”

Coupling Aspect: Temporal

Service A

Synchronous Call

Waiting Working

Return

Service B

The processing time of Service B affects that of A

Coupling aspect: Spatial

Service A

Service B

Service A

Service B

Service A

Service B

?Can communication

automatically continue?

Coupling solutions

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

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.

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?

Data ready butnot passed toconsumer

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

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

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

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

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

Messaging

Reliability

▶ When servers crash

▶ When databases are down

▶ When deadlocks occur in the database

When Servers Crash

DBApp[HTTP] $$ Order

TxCall 1 of 3

Call 2 of 3

Critical Windows Patch

Rollback

Where’s the order!?

When Deadlocks Happen

TxApp[HTTP] $$ Order

DBCall 1 of 3

Deadlock

ExceptionWrite to log A B

Call 2 of 3

Where’s the order!?

Securing client requests with Messaging

TxQ$$ Order

Receive

DBCall 1 of 3

Rollback

Call 2 of 3

Rollback

The order is back in the queue

Calling Web Services

A B C D

[HTTP] Invoke

$$ Order

Deadlock

Rollback

Not Rolled back

MessagingGateway

A B C D

$$ Order

[HTTP] Invoke

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

Durable Messaging

Server

Client

MSMQIncomingOutgoing

Outgoing Incoming

Store and Forward

adds resilience

Message types

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

Exploit strongly-typed messages

IMessagewhere T : IMessage

IHandleMessages<T>void Handle(T message);

Represent methods as messages IMessage

ChangeAddress

MakePreferred

ChangeCredit

Handling Logic Separated

IHandleMessages<T>void Handle(T message);

H1: IHandleMessages<ChangeAddress>

H2: IHandleMessages<MakePreferred>

H3: IHandleMessages<ChangeCredit>

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

▶ Sending a and receiving a message using the bus

Messaging patterns

▶ Return Address▶ Correlated Request/Response▶ Publish Subscribe

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

Correlated Request/Response

Target Service

Some time in the future

Initiating Service

Ticket (guid)

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

Publish / Subscribe

Service A Service B

Publish updated customer infoStore data

Publisher

Subscriber

Subscribe

Subscriber

Publisher

Subscriber

SubscriberMyEvent

MyEvent

▶ Publishing an event

What is a service?

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

▶ All data and business rules reside within the service.

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

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

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

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

Marketing

Customer care

Which service owns this page?

Same page composition

Server

Product Catalog

Pricing

Inventory

Cross Sell

Amazon.com checkout workflow

Which service owns this flow?

Workflow composition

Shipping

Billing

SalesBilling

BillingShipping

Shipping

Marketing

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

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

Bus TopologyApp

Bus.dll

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

Scaling out an AC Autonomous Component

Distributor ACI

ACI ACI

Autonomous Component Instance

on each machine

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

soa systems design

service b service b

temporal coupling

temporal service

spatial service

efferent coupling

kinds of coupling

coupling use xml

processing time of service

Technology

soa design principles for dummies, ibm limited...

forum systems: techniques attack defend xml-soa

what is real-time soa?...so what is “real-time soa”?...

autosar ethernet design and soa - vector...> small soa...

power systems and soa synergy

monitoring adaptable soa-systems using salmon

enterprise soa the leading website for soa architects1 dirk...

c05 – using soa to modernize critical systems

integrating systems with niem using soa

soa design pattern

implementing soa design implementing soa design patterns...

soa-based process-centric design

erl soa design patterns ch16

1. soa design pattern introduction

message driven distributed systems m essage – d riven soa?...

soa & esb in banking systems(persian language)

soa design patterns a comprehensive course

soa bpm = agile integrated tax systems

suggestions for documenting soa-based systems · 5.2 future...

cloud integration, service, soa and api design...