Real World SOA Ronnie Saurenmann Architect Microsoft Switzerland

Real World SOAReal World SOA

Ronnie SaurenmannArchitectMicrosoft Switzerland

A few definitionsA few definitions

2

Service-Orientation: Clarifying Service-Orientation: Clarifying TermsTerms ServicesServices

An endpoint that reacts to messages Web ServicesWeb Services

Described using XML Schema and WSDL, Accessed via SOAP

Service-oriented applicationsService-oriented applicationsExpose (and consume) business logic through services

Service-oriented architecture (SOA)Service-oriented architecture (SOA)Defines patterns and practices for creating and using

service-oriented applications

Web ServicesWeb Services The road to service-oriented architectures

Dream of faster, cheaper, easier integrationWS-* makes service orientation practicalIndustry interoperability

Microsoft roleIndustry catalystBroad products and tools supportDeveloper ecosystem and skills

ResultsFrom devices to the datacenterFaster, easier, cheaper integration

Service Oriented Service Oriented ArchitectureArchitecture A style of architecture, not a product Leverage existing assets in a loosely-coupled

manner Address business needs and exploit new business

opportunities

Primary benefit centers around business agility Standards are critical for success

WS-*, XML, RSS…

1.1. SOA is a design philosophy SOA is a design philosophy independent of any product, independent of any product, technology or industry trendtechnology or industry trend

2. SOAs may be realized via web services but using web services will not necessarily result in a SOA

3. EDI and CORBA were early examples of SO

4.4. SOA is not a methodologySOA is not a methodology

5. SOAs are like snowflakes – no two are the same.

6. SOA should be incremental and build on your current investments

7. Tools, not consultants

8.8. SOA is a means, not an endSOA is a means, not an end

1. SOA is a technology

2. SOAs require Web Services

3. SOA is new and revolutionary

4. SOA ensures the alignment of IT and business

5. A SOA Reference Architecture reduces implementation risk

6. SOA requires a complete technology and business processes overhaul

7. SOA requires an army of consultants

8. We need to build a SOA

FactsMyths

Common Myths about SOACommon Myths about SOA

Deliver a Deliver a solutionsolution, not a SOA, not a SOA

The SOA ROI Crisis…The SOA ROI Crisis…

24% say projects fell short of expectations

55% say project introduced more complexity

41% say project cost more than expected but failed to generate promised return

Only 7% say results exceeded expectations

“The Dark Side of SOA”InformationWeek, September 4, 2006

“The Truth About SOA”CIO Magazine, June 15, 2006

“Services built in isolation, without taking into account the architectural and business goals of the company…may fail outright. Grand architectural planning exercises may drag on endlessly, without providing any real business benefit.”

The dream of SOAThe dream of SOAHow do you get there?How do you get there?

9

Two ApproachesTwo Approaches

Top-Down Bottom-Up

10

The Top-Down ApproachThe Top-Down Approach How it works:How it works:

Define a business architecture○ Using, for example, Microsoft’s Motion methodology

Discover what services are requiredCreate service-oriented apps based on this

Pros:Pros:It’s elegant, clean, and sensible

Cons:Cons:It’s very difficult in most organizations

○ Getting the up-front funding and business buy-in is tough

Keeping up with business change is also tough

The Bottom-Up ApproachThe Bottom-Up Approach How it works:

Build a service-oriented appThen build another oneNext, work on central SOA issues, e.g., security and

managementThen build another service-oriented app . . .

Pros:Pros:It’s the only approach that has worked in most

organizations Cons:

It’s an inelegant, piecemeal way to address the problemRisk of “rogue services”, chaos without a well-defined

governance plan

Suggested ApproachSuggested Approach ““Think globally, act locally”Think globally, act locally” ““Middle out” strategyMiddle out” strategy, the blending of strategic

and tactical, or what we prefer to call “strategical.”

Expose

ComposeConsume

IncrementalDelivery

Business drivers

Without SOAWithout SOA

User

Data Entities LoB Systems SecuritySecurityLoB Systems Data Entities

User

Data Entities LoB Systems SecuritySecurityLoB Systems Data Entities

Billing Service

IDService

SOA AppliedSOA Applied

LoB Systems

Billing Service

SOA AppliedSOA Applied

User

Data Entities LoB Systems SecuritySecurityData Entities

IDService

DataServices

LoB Systems

Billing Service

SOA AppliedSOA Applied

User

Entities LoB Systems SecuritySecurity Entities

IDService

DataServices

CustomerService Product

Service

LoB Systems

Billing Service

SOA AppliedSOA Applied

User

LoB Systems Security Security

IDService

DataServices

CustomerService Product

Service

Security Service

LoB Systems

Billing Service

SOA AppliedSOA Applied

User

LoB Systems

IDService

DataServices

CustomerService

ProductService

Security Service

Service Agent

AdapterAdapter BP Platform

LoB Systems

Billing Service

SOA AppliedSOA Applied

User

LoB Systems

IDService

DataServices

CustomerService

ProductService

Security Service

Service Agent

SOA Pattern and Anti-SOA Pattern and Anti-PatternsPatterns

24

Services interact by exchanging messagesServices interact by exchanging messages

Each message exchange traverses boundaries Each message exchange traverses boundaries

and may have costsand may have costs

SO formalizes intentional, and explicit interactionSO formalizes intentional, and explicit interaction

Tenet 1 – Boundaries are Tenet 1 – Boundaries are ExplicitExplicit

Services expose schemas defining data structures Services expose schemas defining data structures and contracts defining available operationsand contracts defining available operations

Contracts and schema may be independently Contracts and schema may be independently versioned over timeversioned over time

Tenet 2 – Share Schema and Tenet 2 – Share Schema and Contract, Not TypesContract, Not Types

Policy is the statement of communication requirements Policy is the statement of communication requirements

necessary for service interactionnecessary for service interaction

Service capabilities and requirements are expressed in Service capabilities and requirements are expressed in

terms of a policy expressionterms of a policy expression

A policy can contain multiple assertionsA policy can contain multiple assertions

Tenet 3 – Policy defines Tenet 3 – Policy defines Service CompatibilityService Compatibility

Autonomy ≠ IndependenceAutonomy ≠ Independence Topology of a system evolves over time Topology of a system evolves over time Unlike OO, services do not share behaviorUnlike OO, services do not share behavior Services gracefully handle failureServices gracefully handle failure

Tenet 4 – Services Are Tenet 4 – Services Are AutonomousAutonomous

Pattern Document Pattern Document ProcessorProcessor

How do you create a simple to use, well defined interface?How do you create a simple to use, well defined interface?

How did people do How did people do business before business before computers?computers?

August 1880 - Zurich Stock Exchange Association August 1880 - Zurich Stock Exchange Association

The way it was doneThe way it was done

1.1. Messages were Messages were sent on paper sent on paper formsforms

2.2. Most things were Most things were done done asynchronouslyasynchronously

3.3. Process boundaries Process boundaries were well-definedwere well-defined

Create the ContractCreate the Contract1.1. Define the messagesDefine the messages

[[MessageMessageContract] Contract] public class public class UpdateCustomerRequestMessageUpdateCustomerRequestMessage{{ [MessageBody][MessageBody] public Customer updatedCustomer;public Customer updatedCustomer; [MessageBody][MessageBody] public UpdateReason updatedReason;public UpdateReason updatedReason; [MessageBody][MessageBody] public DateTime effectiveDate;public DateTime effectiveDate;}}

Create the ContractCreate the Contract1.1. Define the messagesDefine the messages

2.2. Define the operationsDefine the operations

[OperationContract][OperationContract]public public response response UpdateCustomer(request)UpdateCustomer(request){{ // Note message type names omitted// Note message type names omitted}}

Operations move a process to another state in Operations move a process to another state in atomic fashionatomic fashion

Create the ContractCreate the Contract1.1. Define the messagesDefine the messages

2.2. Define the operationsDefine the operations

3.3. Group operations into servicesGroup operations into services

[[ServiceServiceContract]Contract]public public interface ICustomerServiceinterface ICustomerService{{ [OperationContract][OperationContract] public response public response RegisterNewCustomer(…)RegisterNewCustomer(…) [OperationContract][OperationContract] public response QueryCustomer(…)public response QueryCustomer(…)}}

GranularityGranularity

How granular should a service be? Should it do all the work in one e.g.

SubmitOrder? Should it be a set of smaller services?

EnumerationEnumeration

What is wrong with this What is wrong with this interface?interface?

[OperationContract][OperationContract]

public public object Current {object Current {……}}

[OperationContract][OperationContract]

public bool MoveNext()public bool MoveNext() {{……}}

Chatty InterfaceChatty Interface// Update the customer record on the // Update the customer record on the serverserverif (CheckOutCustomer(custID))if (CheckOutCustomer(custID)){{ // Customer record has app level lock// Customer record has app level lock UpdateName(custName);UpdateName(custName); UpdateAddress(custAddress);UpdateAddress(custAddress); UpdateCity(custCity);UpdateCity(custCity); //etc//etc CommitChanges();CommitChanges();}}

What is wrong with this What is wrong with this service interface?service interface?

Chatty InterfaceChatty Interface// Update the customer record on the // Update the customer record on the serverserverif (CheckOutCustomer(custID))if (CheckOutCustomer(custID)){{ // Customer record has app level lock// Customer record has app level lock UpdateName(custName);UpdateName(custName); UpdateAddress(custAddress);UpdateAddress(custAddress); UpdateCity(custCity);UpdateCity(custCity); //etc//etc CommitChanges();CommitChanges();}}

Operations which require multiple Operations which require multiple messages to complete are messages to complete are dangerousdangerous

State management and transactions are very expensive

How do I factor my service How do I factor my service so that it is flexible and so that it is flexible and highly adaptable?highly adaptable?

The Über ServiceThe Über Service[ServiceContract][ServiceContract]public class UberServicepublic class UberService{{ [OperationContract][OperationContract] public XmlSerializer Execute(XmlSerializer request)public XmlSerializer Execute(XmlSerializer request) {{……}}}}

What is wrong with this What is wrong with this service?service?

No Real Solution For No Real Solution For Versioning Versioning

Changing namespace makes systems incompatible, lowering valueSupporting n versions leads to lots of

transformation work

Can minimize namespace changes with a few simple rulesThere will always be some

Which Modifications Are Which Modifications Are Safe?Safe?

Adding new definitions…

Extending existing definitions…

Changing existing definitions…

Service type

No effect on clients, always okay

Okay to add new operations to service interface

Be very careful adding operations to service callback interfaces

Almost never safe, introduce a new type instead

Data type No effect on clients, always okay

Okay to add optional properties/fields as long as other side allows it

Follow appropriate guidance for your serializer

Almost never safe, introduce a new type instead

Versioning PrinciplesVersioning Principles Receive liberally, send specificallyReceive liberally, send specifically Contracts define expectations, make them clear and version the Contracts define expectations, make them clear and version the

service when expectations change significantlyservice when expectations change significantly

Distributed TransactionsDistributed TransactionsAssume a degree of trust between systems that is typically Assume a degree of trust between systems that is typically not desirable in loosely coupled message exchangesnot desirable in loosely coupled message exchanges

Tx MgrTx Mgr

Org AOrg A

Who controls the Who controls the transaction?transaction?

Org BOrg B

TransactionsTransactions

Spanning atomic transactions across services is dangerousPerformance issuesHolding lock for too longChain of locks

But in some scenarios transactions can be usedE.g. Stocks Position and Cash Account BalanceTransaction duration should be < 0.5 second

What do the airlines do?What do the airlines do?

Airlines permit you to make a Airlines permit you to make a tentative operation known as a tentative operation known as a reservationreservation

Because they don’t trust you…Because they don’t trust you…

Example: Supply ChainExample: Supply ChainReserve part: 49389Qty: 200

Reservation ID: 14432Expires: 2006-11-16 02:43:53Z

Confirm reservation: 14432 PO #49839

Reservation: 14432Receipt: 29389PO #49839

Where do I startWhere do I start Real-world business drivers Middle-out Partition your business capabilities Demonstrate value in rapid iterations – not

waterfall Successful customers ‘snowball’

63

© 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.64