Upload
edmund-morgan
View
217
Download
2
Tags:
Embed Size (px)
Citation preview
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