WSO2Con ASIA 2016: Keynote: At the Heart of Services – Loose Coupling and Its Architectural Benefits
•
4 gefällt mir•855 views
The talk will start by reminding the definition of loose coupling and its paradigmatic realization in messaging. Next, it will be shown how loose coupling is realized by traditional Web Service technology as well as by REST Service technology. As examples, scalability, high availability, and stability will be presented as easy to achieve based on being loosely coupled. Finally, the talk will argue that micro-services as well as native-cloud services imply loose coupling. Presenter: Frank Leymann Ph.D. Director, Institute of Architecture of Application Systems University of Stuttgart
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie WSO2Con ASIA 2016: Keynote: At the Heart of Services – Loose Coupling and Its Architectural Benefits
Ähnlich wie WSO2Con ASIA 2016: Keynote: At the Heart of Services – Loose Coupling and Its Architectural Benefits (20)
Mehr von WSO2
Mehr von WSO2 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
WSO2Con ASIA 2016: Keynote: At the Heart of Services – Loose Coupling and Its Architectural Benefits
- 1. Prof. Dr. Dr. h.c. Frank Leymann Institute of Architecture of Application Systems Universitätsstr. 38 70569 Stuttgart Germany Phone +49-711-685 88 470 Fax +49-711-685 88 472 e-mail Leymann@ iaas.uni-stuttgart.de At the Heart of Services: Loose Coupling and Its Architectural Benefits ( WSO2Conn Asia – Colombo, Sri Lanka – February 17th , 2016
- 4. © Frank Leymann 4 T h e M is s in g P ie c e s L o o s e ly C o u p le d
- 5. © Frank Leymann Integration Problem: The Origin 5 E01-EDI Data Warehouse (Interfaces to and from the Data Warehouse are not displayed on this diagram) G02 - General Ledger A05 - AP S01 - Sales Corrections I01 PO Receiving I03 Return to Vendor I06 Warehouse Management Maininframe PC/NT apps Unix apps 3rd Party Interface S06 - Credit App P15 EES Employee Change Notice O THER APPS - PC AP - Col l ect i ons/ Credi t TM - Credi t Card DB ACCTS REC APPS - PC 990CO R Bad Debt Benef i ci al Fees Benef i ci al Reconci l e JEAXF JEBFA JEBKA JEDVA JESO A JEVSA JEVSF NSF Tel eCredi t Fees I NVENTO RY CO NTRO L APPS - PC Code Al arm Debi t Recei vi ngs Devo Sal es Di spl ay I nvent ory I n Home Junkout s M erchandi se Wi t hdraw al Promo Credi t s RTV Accrual Shri nk AP Research - I nv Cnt rl AP Research- Addl Rpt s Book t o Perpet ual I nvent ory Cl ose O ut Report i ng Comput er I nt el l i gence Dat a Count Correct i ons Cross Ref f or VCB Dnl ds Damage Wri t e O f f Debi t Recei vi ngs DFI Vendor Dat abase Di spl ay I nvent ory Reconci l e Di spl ay I nvent ory Report i ng I NVENTO RY CO NTRO L APPS - PC DPI / CPI I C Bat chi ng I nvent ory Adj / Count Correct I nvent ory Cont rol Report s I nvent ory Level s I nvent ory Rol l M erchandi se Wi t hdraw al O pen Recei vi ngs PI Count Resul t s PI Ti me Resul t s f rom I nv Pri ce Prot ect i on Sal es Fl ash Report i ng Shri nk Report i ng SKU G ross M argi n SKU Shri nk Level Det ai l USM VCB Dow nl oads Journal Entry Tool Kit Scorecard - HR L02-Resource Scheduling (Campbell) P09 - P17 Cyborg M02 - Millennium M03 - Millennium 3.0 Banks - ACH and Pos to Pay Cobra B01 - Stock Status S03-Polling P14 On-line New Hire Entry CTS Plan Administrators (401K, PCS, Life, Unicare, Solomon Smith Barney) D01 Post Load Billing I04 Home Deliveries I02 - Transfers Arthur Planning I07 Purchase Order I12 Entertainment Software I05 Inventory Info E13 E3 Interface S04 - Sales Posting V01-Price Management System I10 Cycle Physical Inventory I55 SKU Information K02 Customer Repair Tracking I35 Early Warning System B02 Merchandise Analysis I13- Auto Replenishment U18 - CTO Intercept I09 Cycle Counts E02-Employee Purchase Texlon 3.5 ACH Stock Options I17 Customer Perceived In-Stock U16-Texlon SiteSeer C02 - Capital Projects F06 - Fixed Assets US Bank Recon File Star Repair EDI Coordinator M esa Dat a NEW Soundscan NPD G roup AI G Warrant y G uard Resumix Optika Store Budget Reporting P16 - Tally Sheet Cash Receipts/Credit S05 - House Charges Ad Expense L01-Promo Analysis V02-Price Marketing Support BMP - Bus performance Mngt Store Scorecard I11 Price Testing Valley Media P09 Bonus/HR I15 Hand Scan Apps Roadshow POS S08 - Vertex Sales Tax A04 - Cust Refund Chks Equifax ICMS Credit Cellular Rollover S09 - Digital Satellite System NPD, SoundScan Sterling VAN Mailbox (Value) I18 SKU Rep X92-X96 Host to AS400 Communication S02 - Layaways Washington, RGIS, Ntl Bus Systems V04-Sign System I14 Count CorrectionsNARM P01- Employee Masterfile I06 - Customer Order Frick Co UAR - Universal Account Reconciliation Depository Banks S07 - Cell Phones S11 - ISP Tracking AAS Fringe PO Cash Over/ Short L60 MDF Coop SKU Selection Tool SKU Performance Supplier Compliance 1 I35 - CEI ASIS Misc Accounting/Finance Apps - PC/NT COBA (Corp office Budget Assistant) PCBS(Profit Center Budget System) Merchandising Budget AIMS Merch Mngr Approval Batch Forecasting Ad Measurement AIMS Admin AIMS ReportingAd Launcher V03- Mkt Reactions Spec Source CTO2.Bestbuy. com Rebate Transfer Sign System CopyWriter's Workspace ELT PowerSuite Store Monitor AIS Calendar Stores & Mrkts Due Dates Smart Plus Insertions Orders Budget Analysis Tool Print Costing Invoice App AIS Reports Broadcast Filter Smart Plus Launcher General Maintenance Printer PO Printer Maintenance Vendor Maintenance Vendor Setup Connect 3 Connect 3 Reports Connect 3 PDF Transfer Spec Source SKU Tracking S20-Sales Polling Prodigy PSP In-Home Repair Warranty Billing System Process Servers (Imaging) Prepared by M i chel l e M i l ls Application Architecture of a real company J
- 6. © Frank Leymann Tight Coupling: Local Method Call Lot of assumptions between called and calling method n Both methods run in same address space n Both methods written in same language n Calling method has to pass expected number of parameters in expected data types n Call is immediate (i.e. synchronous) 6
- 7. © Frank Leymann RPC (Remote Procedure Call) n Attempt to make remote communication via RPC behave like local call n Upside: n Semantics familiar to developers n Downside: n Remote (!) communication invalidates many assumptions local calls are based on n Thus: RPC simply does not have semantics of a local call! 7
- 8. © Frank Leymann RPC ≠ Local Call (1/2) n Called method might not be available (network fragmentation, server outage,...) Time Dependency n How long should caller wait? n Remote method often controlled by a different party (business partner,...) Format Dependency n What if signature of called method changes? n Rewrite code of calling application! L 8
- 9. © Frank Leymann RPC ≠ Local Call (2/2) n Calling function often explicitly points to a particular target function Reference Dependency n What if called function is moved to different machine? n Parameters have to match machine architecture (little/big Endian,…), locale settings (code pages, time zones,…) Platform Dependency 9
- 10. © Frank Leymann Σ = Causes of Volatility of RPC n Time Autonomy violation ≈ All ingredients have to be available at same time n Format Autonomy violation ≈ Number and types of parameters must match n Reference Autonomy violation ≈ Hard-coded addresses n Platform Autonomy violation ≈ Internal representations of data (little/big endian...) 10
- 12. © Frank Leymann Loose Coupling: Autonomy Aspects n Reference Autonomy n Producers and consumers don’t know each other n Time Autonomy n Producers and consumers execute at their own pace n Format Autonomy n Producers and consumers may use different formats of data exchanged n Platform Autonomy n Producers and consumers may be in different environments, written in different languages,… 12
- 16. © Frank Leymann Reference Autonomy in Messaging n Producers and consumers communicate via queues or topics, i.e. they don’t know each other n Routing components free producers even from having to know which queue or topic to use n …i.e. producers only has to understand single source to send messages to 16 Consumer A Consumer B Producer
- 17. © Frank Leymann Time Autonomy in Messaging n Asynchrony is at the heart of messaging, thus time autonomy is “in its guts” n Queuing is providing 1-1 connections n Pubsub is providing 1-n connections 17 Sender Receiver1 Receiverj Receivern … … Receiver1 Receiverj Receivern … … Sender
- 18. © Frank Leymann Platform Autonomy in Messaging n Endpoint are isolating applications from messaging environment n Application can be… n …in any programming language n …in any operating environment n … n Messaging products run in many environments n You can even bridge between different products 18 Channel Adapter Endpoint Implement As… Messaging Mapper Uses A… Messaging Gateway Implemented As… MOM 1 MOM 2
- 19. © Frank Leymann Format Autonomy in Messaging n Transformation of messages is done “on the wire” n Versioning of messages is enabled n … 19 A Translator B Translator A B Translator Translator Canonical Data Model Translator C C Translator Translator
- 22. © Frank Leymann Message Endpoints n Applications typically do not send data to or receive data from a channel n They are not built with integration in mind! n Message endpoints connect applications to integration solution 22 A EndpointA EndpointB B M M’
- 24. © Frank Leymann Protocols are Changing Along A Path 24 Initial Sender Ultimate Receiver My Gateway Firewall Your Gateway In general, you cannot rely on any QoS of „the“ transport protocol Message path Enterprise1 Enterprise2 JMS HTTP RMI/ IIOP MQ
- 25. © Frank Leymann SOAP 25 Intended for ultimate receiver SOAP Envelope SOAP Header SOAP Body Header Block H1 Header Block Hn Body Sub-element B1 Body Sub-element Bk ... ... Intended for intermediaries Payload for middleware ensuring QoS Payload for application
- 26. © Frank Leymann Loose Coupling in WS* n Reference Autonomy n Client interacts with an endpoint (often a URI) not with a concrete program, i.e. client doesn’t know the actual service n Time Autonomy n Asynchronous bindings (JMS,…) can be used n Reply-to header, Correlation header,… support asynchrony even over synchronous transports n Platform Autonomy n Client interacts with service without having to know programming language, hosting environment,… of service n Format Autonomy n Binding specifies serialization format n Transformation can be done “invisibly” along the wire 26
- 29. © Frank Leymann Core Idea Behind REST n REST is an architectural style, not a technology n It allows to apply the Web Architecture to more sophisticated interactions n Key Points: n REpresentational n State Transfer
- 30. © Frank Leymann Characteristics Of The Web Architecture n Interaction with URI addressable resources n Fixed set of generic interactions (mainly HTTP GET, POST, PUT, and DELETE) n Standard data format (HTML, XML,… - MIME types) n Stateless n All context is fully understandable from message
- 32. © Frank Leymann Time Autonomy in REST: Long Running Requests n Sometimes requests may take too long for a client to wait for response n Especially POST and DELETE may take some time n They might initiate a complete business processes n Server acknowledges reception of request n Via HTTP Status Code 202 Accepted n Server provides a resource that client can use to track progress of long-running request (aka “task”) n Via Content-Location header of this resource, or n Via Link to this resource
- 33. © Frank Leymann Example: Starting Long Running Request POST /imageProcessing/beautify HTTP/1.1 Host: www.fl.com Content-Type: multipart/related; boundary=fl42 --fl42 ... --fl42 ... --fl42-- HTTP/1.1 202 Accepted Content-Type: application/xml Content-Location: http://www.fl.com/imageProcessing/tasks/1 <status> <state>running</state> <link rel="self" href=".../tasks/1"/> <estimatedCompletion>2020-04-01</estimatedCompletion> </status> TaskResource
- 34. © Frank Leymann Example: Checking State of Long Running Request GET /imageProcessing/tasks/1 HTTP/1.1 Host: www.fl.com HTTP/1.1 200 OK Content-Type: application/xml Content-Location: http://www.fl.com/imageProcessing/tasks/1 <status> <state>running</state> <link rel="self" href=".../tasks/1"/> <estimatedCompletion>2020-10-10</estimatedCompletion> </status>
- 35. © Frank Leymann Example: Completion of Long Running Request n Location header points to newly created, i.e. successfully processed resource but not to the task resource n Content-Location header (still) points to the task resource GET /imageProcessing/tasks/1 HTTP/1.1 Host: www.fl.com HTTP/1.1 303 See Other Content-Type: application/xml Location: http://www.fl.com/images/314 Content-Location: http://www.fl.com/imageProcessing/tasks/1 <status> <state>ready</state> <link rel="self" href=".../tasks/1"/> <message>Image processed & stored</message> </status>
- 36. © Frank Leymann Example: Failed Long Running Request GET /imageProcessing/tasks/1 HTTP/1.1 Host: www.fl.com HTTP/1.1 200 OK Content-Type: application/xml Content-Location: http://www.fl.com/imageProcessing/tasks/1 <status> <state>failed</state> <link rel="self" href=".../tasks/1"/> <message>Image could not be processed</message> </status>
- 37. © Frank Leymann Platform Autonomy in REST n The premier transport to implement REST is HTTP(S) n HTTP clients and HTTP servers are available in all major environments n Programs in most languages can be producers and consumers of HTTP messages 37
- 38. © Frank Leymann Format Autonomy in REST: Content Negotiation n Often, requested entity is available in multiple variants n HTTP defines procedures to negotiate the appropriate variant to be transferred 38 Client Server Variant Entity Variant Variant Variant Selection Response Request
- 40. © Frank Leymann Example: Returning Applicable Functions GET /orders/42 HTTP/1.1 Host: www.fl.com HTTP/1.1 200 OK Content-Type: application/xml <order> <customer>Frank</customer> ... <link href="www.fl.com/cancellations/42" rel="www.rels.com/orderAPI/POST/cancel"/> <link href="www.fl.com/ShipDetails/42" rel="www.rels.com/orderAPI/GET/shipping"/> </order
- 41. © Frank Leymann REST Maturity Model (aka Richardson Maturity Model) n Support of HATEOAS n Use of appropriate HTTP methods to manipulate individual resources n Use of appropriate HTTP status codes and header fields n Individual resources are identified n Use of single method (typically POST) n Method invoked on individual resource n Similar to “objects” n HTTP is used as a transport only n Single entry point only n Use of single method (typically POST) n Examples: SOAP, XML-RPC Swamp of POX Resources HTTP Verbs Hypermedia Controls Level 0 Level 1 Level 2 Level 3
- 44. © Frank Leymann Two Classes of Faults n A fault is an event within a system that caused a failure n Transient fault does not re-occur when retrying the operation (“Heisenbug”) n Permanent fault is repeatable (“Bohrbug”) 44
- 45. © Frank Leymann Fixing Faults If software fault is a Bohrbug there is no repair: n Get an emergency fix or wait for the next release If software fault is a Heisenbug then repair is easy: → Shutdown and restart Luckily, most software-caused faults are Heisenbugs 45
- 46. © Frank Leymann Fail-Fast Techniques: Watchdog A watchdog is a special program that detects faults of application components fast It does so by… n Monitoring the liveness of these components, and n Re-creating failed components “immediately” …which is equivalent to shutdown and retry J 46
- 48. © Frank Leymann Hot-Pooling: High Availability n Hot Pool: n A collection of application components with identical functionality sharing a common input queue n When a member fails the other members will continue processing requests from input queue Availability n Watchdog will restart failed members High Availability 48 Server Server Server Client AppPUT GET Hot Pool Update Watchdog = Shutdown & Retry
- 49. © Frank Leymann A Bit of Math: Forgive Me J 49 αhot pool = P≥1 = i N ( )i=1 N ∑ αi 1−α( ) N−i = i N ( )i=0 N ∑ αi 1−α( ) N−i − N 0 ⎛ ⎝ ⎜ ⎞ ⎠ ⎟ α0 1−α( ) N⎛ ⎝ ⎜ ⎞ ⎠ ⎟ = α + 1−α( )( ) N − 1−α( ) N …a lot of explanations, e.g. application components fail independently; independent events are “binomial distributed”; availability means that at least one member is running in hot pool; etc etc… αhot pool = 1− 1−αmember( ) N Example: Assume a terribly bad application component with 80% availability (αmember=0.8). Hot pool with 8 of such bad components has 99.999 availability (αhot pool=0.99999)!
- 50. © Frank Leymann Hot-Pooling: Scalability n Watchdog can monitor metrics of SLOs of hot pool n If SLOs are threatened to be not met, watchdog will start additional members Scale-out n If members are underused, watchdog will shutdown subset of members Scale-in 50 Server Server App GET Watchdog Server Server Server App GET Watchdog Scale-out Server App GET Watchdog Scale-in
- 52. © Frank Leymann n An Application System is the complete, interdependent set of hardware, middleware, applications,... required to process complete business requests C1 C2 Cn… Application System Application Systems 52
- 53. © Frank Leymann Stability n An application system (or system for short) is called stable iff it keeps processing business requests even when there are transient impulses, persistent stresses, or component failures disrupting normal processing n An impulse is a rapid shock to a system n It's like whacking the system with a hammer n Stress is like a force being applied to a system over an extended period of time n It's like constantly pushing against the system 53
- 54. © Frank Leymann n 100.000 new sessions within a minute is an impulse n 8.000.000 new messages in a queue within a few minutes before close-of-business is an impulse n Such an impulse can break a system within seconds! Impulse in Software 54
- 55. © Frank Leymann n Slow response from your credit card processor over a long period of time (see next) is stress n ...because it reduces the capacity to serve customers Stress produces strain n Stress from the credit card processor produces strain that propagate to other parts of the system n ...resulting in requests piling up in queues, queues getting full, refusing new requests, stopping services to customers Stress in Software 55
- 56. © Frank Leymann n How long is a "long period of time"? It depends! n A very good definition is the time between two code deployments n If you deploy your system once a week it doesn't matter to build the system to run for five years without interrupt Long Period of Time 56
- 60. © Frank Leymann How to Cope with Cracks n The most important technique to avoid cracks is the Circuit Breaker n But there are many other techniques: see the book by Michael T. Nygard n However: n Thus: 60 Design for failure! Cracks WILL HAPPEN!
- 64. © Frank Leymann Definition: Quote (*) n …microservice architectural style is an approach to n developing a single application as a suite of small services, n each running in its own process and n communicating with lightweight mechanisms, often an HTTP resource API. n These services are built n around business capabilities and n independently deployable by fully automated deployment machinery. n There is a bare minimum of centralized management of these services, which n may be written in different programming languages and n use different data storage technologies. 64 (*) J. Lewis & M. Fowler: “Microservices” (2015), http://martinfowler.com/articles/microservices.html
- 65. © Frank Leymann Microservice: Main Properties Microservice is n small n running in its own process n communicating often [via] HTTP n built around business capabilities n written in different programming languages n use different data storage technologies n independently deployable by fully automated deployment machinery 65 …what ever that means L True for many (!) service True for many (!) service, and most REST services That’s what services are all about! That’s interesting J container
- 67. © Frank Leymann A Problem n You have a “big application” (a.k.a. “monolith”) n If you want to replicate it n …e.g. because of scale, availability, elasticity,… you pay penalties (e.g. licenses for all components) although you only need “a few components” replicated 67 Application … Scale,HA,…
- 68. © Frank Leymann Solution n Split your “big application” into “smaller” granules that can be deployed independently n I.e. split it into microservices n Replication can be restricted to those components that turn out to be bottlenecks ( scale), critical ( HA),… without paying the penalties for all other components of the “big application” 68 Application
- 69. © Frank Leymann The Essence of Microservices n Microservices are all about… n …proper granularity of components n …independent deployment n They are not a counter-proposal to SOA n They do not prove that SOA failed n In the opposite: they require loose coupling,… n They require a methodology to determine “proper granules” for components n …something like the holy grail of software engineering for decades! n …so, don’t expect your middleware vendors to solve this problem for you! It’s all about YOU solving an very difficult architecture/design problem!!! 69
- 71. © Frank Leymann IDEAL Principle: Native Cloud Application Properties - Architects View Distribution: decomposed application to… … use multiple cloud resources … support the fact that clouds are large globally distributed systems Elasticity: build application to support scaled-out and scaled-in dynamically Scale out: acquire additional resources to satisfy growing workload Scale in: free up resources if workload shrinks ? Loose Coupling: influence of application components has to be limited Example: failures should not impact other components Example: addition / removal of components is simplified Isolated State: build the application stateless with respect to… Session State: state of the communication with the application Automated Management: runtime management should be handled quickly , automatic Example: automatic license acquisition because of use of additional resources Example: resiliency by reacting to resource failures
- 72. © Frank Leymann Cloud Computing Patterns: Overview Applica on Workloads Cloud Service Models & Cloud Deployment Types Cloud Environments Processing Offerings Communica on Offerings Storage Offerings Applica on Management Cloud Integra onMul -TenancyFundamental Architecture StylesNa ve Cloud Applica onsHybrid Cloud Applica ons Applica on Components Cloud Run me Environment Cloud Applica on User Group Load Balancer Presenta on Message Queue Business Logic Data Opera on Management Processing ... ... Communica on Storage 1 2 3 Sta c Workload (25) Periodic Workload (28) Once-in-a-life me Workload (31) Unpredictable Workload (33) Con nuously Changing Workload (36) Infrastructure as a Service (41) Pla orm as a Service (44) So ware as a Service (49) Public Cloud (56) Private Cloud (59) Community Cloud (64) Hybrid Cloud (67) Elas c Infrastructure (78) Elas c Pla orm (81) Node-based Availability (85) Environment-based Availability (88) Hypervisor (91) Execu on Environment (94) Virtual Networking (118) Message-oriented Middleware (122) Exaclty-once Delivery (126) At-least-once Delivery (128) Transac on-based Delivery (130) Timeout-based Delviery (132) Two- er Cloud Applica on (259) Three- er Cloud Applica on (263) Content Distribu on Network (268) Hybrid User Interface (271) Hybrid Processing (274) Hybrid Data (277) Hybrid Backup (280) Hybrid Backend (282) Hybrid Applica on Func ons (285) Hybrid Mul media Web Applica on (287) Hybrid Develop- ment Environment (289) Provider Adapter (216) Managed Configura on (219) Elas city Manager (221) Elas c Load Balancer (224) Elas c Queue (227) Watchdog (230) Elas city Man- agement Process (237) Feature Flags Man- agement Process (240) Update Transi on Process (245) Standby Pooling Process (248) Resiliency Man- agement Process (252) Shared Component (188) Tenant-isolated Component (191) Dedicated Component (195) Restricted Data Access Component (198) Message Mover (201) Applica on Component Proxy (203) Compliant Data Replica on (205) Stateful Component (150) Stateless Component (153) Mul Component Image (184) User Interface Component (156) Processing Component (160) Batch Processing Component (165) Idempotent Processor (176) Transac on-based Processor (179) Timeout-based Message Processor (182) Data Access Component (168) Data Abstractor (173) Map Reduce (96) =1 1+ Strict Consistency (110) Eventual Consistency (113) Key-value Storage (107) ID Blob Storage (101) Block Storage (100) 1.1 1.2 ZZZ Integra on Provider (208) Distributed Applica on (143) Loose Coupling (139) ? 1+ Rela onal Database (103) www 3,14159... 3,14 hosted onhosted onhosted on §
- 74. © Frank Leymann Summary n Building robust applications is all about proper architecture and design n Loose-Coupling is a central principle of such architecture and design n Loose-Coupling is supported by the mainstream service technologies n There is no middleware or tooling magic that ensures building “good” service-based systems! 74 But it’s all about YOU applying good architectural principles (like loose coupling J)