Reactive Design Patterns

Total Page:16

File Type:pdf, Size:1020Kb

Reactive Design Patterns Reactive Design Patterns ROLAND KUHN WITH BRIAN HANAFEE AND JAMIE ALLEN FOREWORD BY JONAS BONÉR MANNING SHELTER ISLAND For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: [email protected] ©2017 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. Manning Publications Co. Development editor: Jennifer Stout 20 Baldwin Road Technical development editor: Brian Hanafee PO Box 761 Project editors: Tiffany Taylor and Janet Vail Shelter Island, NY 11964 Line editor: Ben Kovitz Copyeditor: Tiffany Taylor Proofreader: Katie Tennant Technical proofreader: Thomas Lockney Typesetter: Dottie Marsico Cover designer: Leslie Haimes ISBN 9781617291807 Printed in the United States of America 1 2 3 4 5 6 70 8 9 10 – EBM – 22 21 20 19 18 17 To my children — Roland brief contents PART 1 INTRODUCTION................................................................ 1 1 ■ Why Reactive? 3 2 ■ A walk-through of the Reactive Manifesto 12 3 ■ Tools of the trade 39 PART 2 THE PHILOSOPHY IN A NUTSHELL ................................... 65 4 ■ Message passing 67 5 ■ Location transparency 81 6 ■ Divide and conquer 91 7 ■ Principled failure handling 100 8 ■ Delimited consistency 105 9 ■ Nondeterminism by need 113 10 ■ Message flow 120 PART 3 PATTERNS .................................................................... 125 11 ■ Testing reactive applications 127 12 ■ Fault tolerance and recovery patterns 162 13 ■ Replication patterns 184 14 ■ Resource-management patterns 220 15 ■ Message flow patterns 255 16 ■ Flow control patterns 294 17 ■ State management and persistence patterns 311 v contents foreword xv preface xvii acknowledgments xix about this book xxi about the authors xxiv PART 1 INTRODUCTION.................................................1 Why Reactive? 3 1 1.1 The anatomy of a Reactive application 4 1.2 Coping with load 5 1.3 Coping with failures 7 1.4 Making the system responsive 8 1.5 Avoiding the ball of mud 10 1.6 Integrating nonreactive components 10 1.7 Summary 11 A walk-through of the Reactive Manifesto 12 2 2.1 Reacting to users 12 Understanding the traditional approach 13 ■ Analyzing latency with a shared resource 15 ■ Limiting maximum latency with a queue 16 vii viii CONTENTS 2.2 Exploiting parallelism 18 Reducing latency via parallelization 18 ■ Improving parallelism with composable Futures 20 ■ Paying for the serial illusion 21 2.3 The limits of parallel execution 23 Amdahl’s Law 23 ■ Universal Scalability Law 24 2.4 Reacting to failure 26 Compartmentalization and bulkheading 28 ■ Using circuit breakers 29 ■ Supervision 30 2.5 Losing strong consistency 31 ACID 2.0 33 ■ Accepting updates 34 2.6 The need for Reactive design patterns 35 Managing complexity 36 ■ Bringing programming models closer to the real world 37 2.7 Summary 38 Tools of the trade 39 3 3.1 Early Reactive solutions 39 3.2 Functional programming 41 Immutability 41 ■ Referential transparency 44 ■ Side effects 45 ■ Functions as first-class citizens 46 3.3 Responsiveness to users 47 Prioritizing the three performance characteristics 47 3.4 Existing support for Reactive design 48 Green threads 48 ■ Event loops 49 ■ Communicating Sequential Processes 50 ■ Futures and promises 52 Reactive Extensions 57 ■ The Actor model 58 Summary 62 PART 2 THE PHILOSOPHY IN A NUTSHELL ....................65 Message passing 67 4 4.1 Messages 67 4.2 Vertical scalability 68 4.3 Event-based vs. message-based 69 4.4 Synchronous vs. asynchronous 71 4.5 Flow control 73 CONTENTS ix 4.6 Delivery guarantees 76 4.7 Events as messages 78 4.8 Synchronous message passing 80 4.9 Summary 80 Location transparency 81 5 5.1 What is location transparency? 81 5.2 The fallacy of transparent remoting 82 5.3 Explicit message passing to the rescue 83 5.4 Optimization of local message passing 84 5.5 Message loss 85 5.6 Horizontal scalability 87 5.7 Location transparency makes testing simpler 87 5.8 Dynamic composition 88 5.9 Summary 90 Divide and conquer 91 6 6.1 Hierarchical problem decomposition 92 Defining the hierarchy 92 6.2 Dependencies vs. descendant modules 94 Avoiding the matrix 95 6.3 Building your own big corporation 96 6.4 Advantages of specification and testing 97 6.5 Horizontal and vertical scalability 98 6.6 Summary 99 Principled failure handling 100 7 7.1 Ownership means commitment 100 7.2 Ownership implies lifecycle control 102 7.3 Resilience on all levels 104 7.4 Summary 104 Delimited consistency 105 8 8.1 Encapsulated modules to the rescue 106 8.2 Grouping data and behavior according to transaction boundaries 107 x CONTENTS 8.3 Modeling workflows across transactional boundaries 107 8.4 Unit of failure = unit of consistency 108 8.5 Segregating responsibilities 109 8.6 Persisting isolated scopes of consistency 111 8.7 Summary 112 Nondeterminism by need 113 9 9.1 Logic programming and declarative data flow 113 9.2 Functional reactive programming 115 9.3 Sharing nothing simplifies concurrency 116 9.4 Shared-state concurrency 117 9.5 So, what should we do? 117 9.6 Summary 119 Message flow 120 10 10.1 Pushing data forward 120 10.2 Modeling the processes of your domain 122 10.3 Identifying resilience limitations 122 10.4 Estimating rates and deployment scale 123 10.5 Planning for flow control 124 10.6 Summary 124 PART 3 PATTERNS .....................................................125 Testing reactive applications 127 11 11.1 How to test 127 Unit tests 128 ■ Component tests 129 ■ String tests 129 Integration tests 129 ■ User-acceptance tests 130 ■ Black-box vs. white-box tests 130 11.2 Test environment 131 11.3 Testing asynchronously 132 Providing blocking message receivers 133 ■ The crux of choosing timeouts 135 ■ Asserting the absence of a message 141 Providing synchronous execution engines 142 ■ Asynchronous assertions 144 ■ Fully asynchronous tests 145 ■ Asserting the absence of asynchronous errors 147 CONTENTS xi 11.4 Testing nondeterministic systems 150 The trouble with execution schedules 151 ■ Testing distributed components 151 ■ Mocking Actors 152 ■ Distributed components 153 11.5 Testing elasticity 154 11.6 Testing resilience 154 Application resilience 155 ■ Infrastructure resilience 158 11.7 Testing responsiveness 160 11.8 Summary 161 Fault tolerance and recovery patterns 162 12 12.1 The Simple Component pattern 162 The problem setting 163 ■ Applying the pattern 163 The pattern, revisited 165 ■ Applicability 166 12.2 The Error Kernel pattern 166 The problem setting 167 ■ Applying the pattern 167 The pattern, revisited 170 ■ Applicability 171 12.3 The Let-It-Crash pattern 171 The problem setting 172 ■ Applying the pattern 172 The pattern, revisited 173 ■ Implementation considerations 174 ■ Corollary: the Heartbeat pattern 175 Corollary: the Proactive Failure Signal pattern 176 12.4 The Circuit Breaker pattern 177 The problem setting 177 ■ Applying the pattern 178 The pattern, revisited 181 ■ Applicability 182 12.5 Summary 182 Replication patterns 184 13 13.1 The Active–Passive Replication pattern 184 The problem setting 185 ■ Applying the pattern 186 The pattern, revisited 196 ■ Applicability 197 13.2 Multiple-Master Replication patterns 197 Consensus-based replication 198 ■ Replication with conflict detection and resolution 201 ■ Conflict-free replicated data types 203 13.3 The Active–Active Replication pattern 210 The problem setting 211 ■ Applying the pattern 211 xii CONTENTS The pattern, revisited 217 ■ The relation to virtual synchrony 218 13.4 Summary 219 Resource-management patterns 220 14 14.1 The Resource Encapsulation pattern 221 The problem setting 221 ■ Applying the pattern 221 The pattern, revisited 227 ■ Applicability 228 14.2 The Resource Loan pattern 229 The problem setting 229 ■ Applying the pattern 230 The pattern, revisited 232 ■ Applicability 233 Implementation considerations 233 ■ Variant: using the Resource Loan pattern for partial exposure 234 14.3 The Complex Command pattern 234 The problem setting 235 ■ Applying the pattern 236 The pattern, revisited 243 ■ Applicability 243 14.4 The Resource Pool pattern 244 The problem setting 244 ■ Applying the pattern 245 The pattern, revisited 247 ■ Implementation considerations 248 14.5 Patterns for managed blocking 248 The problem setting 249 ■ Applying the pattern 249 The pattern, revisited 251 ■ Applicability 253 14.6 Summary 253 Message flow patterns 255 15 15.1 The Request–Response pattern 255 The problem setting 256 ■ Applying the pattern 257 Common instances of the pattern 258 ■ The pattern,
Recommended publications
  • Zeromq
    ZeroMQ Martin Sústrik <> ØMQ is a messaging system, or "message-oriented middleware", if you will. It's used in environments as diverse as financial services, game development, embedded systems, academic research and aerospace. Messaging systems work basically as instant messaging for applications. An application decides to communicate an event to another application (or multiple applications), it assembles the data to be sent, hits the "send" button and there we go—the messaging system takes care of the rest. Unlike instant messaging, though, messaging systems have no GUI and assume no human beings at the endpoints capable of intelligent intervention when something goes wrong. Messaging systems thus have to be both fault-tolerant and much faster than common instant messaging. ØMQ was originally conceived as an ultra-fast messaging system for stock trading and so the focus was on extreme optimization. The first year of the project was spent devising benchmarking methodology and trying to define an architecture that was as efficient as possible. Later on, approximately in the second year of development, the focus shifted to providing a generic system for building distributed applications and supporting arbitrary messaging patterns, various transport mechanisms, arbitrary language bindings, etc. During the third year the focus was mainly on improving usability and flattening the learning curve. We've adopted the BSD Sockets API, tried to clean up the semantics of individual messaging patterns, and so on. Hopefully, this chapter will give an insight into how the three goals above translated into the internal architecture of ØMQ, and provide some tips for those who are struggling with the same problems.
    [Show full text]
  • Integration Patterns Integration Patterns
    Integration Patterns Integration Patterns patterns & practices David Trowbridge, Microsoft Platform Architecture Guidance Ulrich Roxburgh, Microsoft Consulting Services (Australia) Gregor Hohpe, ThoughtWorks, Inc. Dragos Manolescu, ThoughtWorks, Inc. E.G. Nadhan, EDS ISBN 0-7356-1850-X Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2004 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, BizTalk, InfoPath, Visio, Visual Basic, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
    [Show full text]
  • Migration of a Chosen Architectural Pattern to Service Oriented
    Master Thesis Software Engineering Thesis no: MSE-2012:96 06 2012 Migration of chosen architectural pattern to Service Oriented Architecture Piotr Kaliniak This thesis is presented as part of Degree of European Master in Software Engineering School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author(s): Piotr Kaliniak E-mail: [email protected] University advisor(s): Dr. Ludwik Ku´zniarz School of Computing, Blekinge Institute of Technology, Sweden External University advisor(s) Dr. Bogumi laHnatkowska Wroc law University of Technology, Poland School of Computing Blekinge Institute of Technology Internet : www.bth.se/com SE-371 79 Karlskrona Phone : +46 455 38 50 00 Sweden Fax : +46 455 38 50 57 Abstract Context: Several examples of successful migrations of systems to Service Oriented Architecture (SOA) are presented in the literature. Some of the approaches also try to structure the process of migration to SOA. The re- ported migration attempts underline the role of architecture of migrated system, but they do not explore the architectural patterns applied in ar- chitecture of migrated systems while proper usage of patterns may simplify and improve quality of migration. Objectives: This work is aimed at elaborating guidelines that support migration from a system that is based on a chosen architectural pattern towards a system based on Service Oriented Architecture.
    [Show full text]
  • Patterns: Implementing Self-Service in an SOA Environment
    Front cover Patterns: Implementing Self-Service in an SOA Environment Integrate Web applications with the enterprise tier Explore Web services, J2EE Connectors, and JMS solutions Use SOA and ESB technology Carla Sadtler Anup Aggarwal Diego Cotignola Sandy Grewal Peter Hood Shashi Shrimali Fernando Teixeira ibm.com/redbooks International Technical Support Organization Patterns: Implementing Self-Service in an SOA Environment January 2006 SG24-6680-01 Note: Before using this information and the product it supports, read the information in “Notices” on page xi. Second Edition (January 2006) This edition applies to WebSphere Application Server V6. © Copyright International Business Machines Corporation 2005, 2006. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xi Trademarks . xii Preface . xiii The team that wrote this redbook. xiii Become a published author . xv Comments welcome. xv Summary of changes . xvii January 2006, Second Edition . xvii Chapter 1. Patterns for e-business . 1 1.1 The Patterns for e-business layered asset model . 2 1.2 How to use the Patterns for e-business . 4 1.2.1 Selecting a Business, Integration, Composite pattern, or a Custom design. 4 1.2.2 Selecting Application patterns. 9 1.2.3 Review Runtime patterns . 11 1.2.4 Reviewing Product mappings . 13 1.2.5 Reviewing guidelines and related links . 14 1.3 Summary . 15 Chapter 2. Self-Service business pattern . 17 2.1 Self-service applications . 18 2.2 Self-Service application patterns. 18 2.3 Application pattern used in this book.
    [Show full text]
  • ZHANG-THESIS.Pdf (1.887Mb)
    n-Screen Application Framework A Thesis Submitted to the College of Graduate Studies and Research in Partial Fulfillment of the Requirements for the degree of Master of Science in the Department of Computer Science University of Saskatchewan Saskatoon By Xiaobo Zhang c Xiaobo Zhang, November/2012. All rights reserved. Permission to Use In presenting this thesis in partial fulfilment of the requirements for a Postgraduate degree from the University of Saskatchewan, I agree that the Libraries of this University may make it freely available for inspection. I further agree that permission for copying of this thesis in any manner, in whole or in part, for scholarly purposes may be granted by the professor or professors who supervised my thesis work or, in their absence, by the Head of the Department or the Dean of the College in which my thesis work was done. It is understood that any copying or publication or use of this thesis or parts thereof for financial gain shall not be allowed without my written permission. It is also understood that due recognition shall be given to me and to the University of Saskatchewan in any scholarly use which may be made of any material in my thesis. Requests for permission to copy or to make other use of material in this thesis in whole or part should be addressed to: Head of the Department of Computer Science 176 Thorvaldson Building 110 Science Place University of Saskatchewan Saskatoon, Saskatchewan Canada S7N 5C9 i Abstract Smartphones and tablets with advanced computing ability and connectivity have already become indis- pensable in our daily lives.
    [Show full text]
  • 2.2.3 Cloud Design Patterns (Microsoft Azure)
    Cloud Computing Patterns Identification, Design, and Application Von der Fakultät für Informatik, Elektrotechnik und Informationstechnik der Universität Stuttgart zur Erlangung der Würde eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigte Abhandlung Vorgelegt von Christoph Fehling aus Hannover Hauptberichter: Prof. Dr. Dr. h. c. Frank Leymann Mitberichter: Univ.Prof. Dr. Schahram Dustdar Tag der mündlichen Prüfung: 07.10.2015 Institut für Architektur von Anwendungssystemen der Universität Stuttgart 2015 Contents List OF AcrONYMS 9 Zusammenfassung 13 AbstrACT 15 1 INTRODUCTION 17 1.1 Terminology and Conventions . 19 1.1.1 Patterns and Pattern Languages . 19 1.1.2 Cloud Applications and Cloud Providers . 20 1.2 Problem Domain and Contributions . 21 1.2.1 Architectural Baseline of Cloud Computing . 22 1.2.2 Cloud Computing Patterns . 24 1.2.3 Cloud Computing Pattern Language . 29 3 Contents 1.2.4 Design Method for Cloud Applications . 31 1.3 Pattern Engineering Process . 33 1.4 Chapter Summary . 35 2 Related WORK 39 2.1 Guidelines for Pattern Research . 40 2.1.1 Pattern Identification and Authoring . 41 2.1.2 Iterative Pattern Review . 42 2.1.3 Participating in Pattern Conferences . 42 2.2 Other Cloud Computing Patterns . 43 2.2.1 Cloud Computing Patterns of PLoP Conferences 44 2.2.2 Cloud Design Patterns (Amazon Web Services) 45 2.2.3 Cloud Design Patterns (Microsoft Azure) . 46 2.2.4 Cloud Architecture Patterns . 48 2.2.5 CloudPatterns.org . 49 2.3 Chapter Summary . 51 3 IDENTIfiCATION OF Patterns FOR Cloud Computing 53 3.1 Architectural Principles of Cloud Computing . 56 3.1.1 Cloud Computing Properties .
    [Show full text]
  • An Iot Oriented Comparison
    REST and MQTT An IoT oriented comparison Credits: Prof.Pietro Manzoni, University of Valencia, Spain REST vs MQTT 1 IoT Protocols HTTP, CoAP, REST, MQTT, AMQP, XMPP, DDS TCP, UDP IPv4, IPv6, 6LoWPAN Cellular: LR-WPAN: 2G (GSM, GPRS), Ethernet WiFi Bluetooth, ZigBee, 3G (HSPDA,…), IEEE 802.15.x 4G (LTE), REST vs MQTT 2 Network layer protocols ¡ The network (or OSI Layer 3 abstraction) provides an abstraction of the physical world. ¡ Communication protocols £ Most of the IP-based communications are based on the IPv4 (and often via gateway middleware solutions) £ However, IP overhead makes it inefficient for embedded devices with low bit rate and constrained power. ¢ IPv6 is increasingly being introduced for embedded devices è 6LowPAN (IPv6 over Low power Wireless Personal Area Networks) REST vs MQTT 3 IoT standards: OASIS ü OASIS is a nonprofit consortium that drives the development, convergence and adoption of open standards for the global information society. ü OASIS promotes industry consensus and produces worldwide standards for security, Internet of Things, cloud computing, energy, content technologies, emergency management, and other areas. REST vs MQTT 4 IoT standards: open-source implementations ¡ While Open Standards are key, it is also important to make available open-source implementations of such standards, to encourage adoption of such standards both by IoT developers and the IoT industry at large. ¡ http://iot.eclipse.org/ £ Eclipse IoT is an ecosystem of companies and individuals that are working together to establish an Internet of Things based on open technologies. REST vs MQTT 5 “Message based” communications ¡Data bundles (i.e., messages) interchange is becoming everyday more common £E.g., Twitter, Whatsapp, Instagram, Snapchat, Facebook,..
    [Show full text]
  • Building a Framework for High-Performance In-Memory Message-Oriented Middleware
    Building a Framework for High-performance In-memory Message-Oriented Middleware by Huy Hoang A thesis presented to the University of Waterloo in fulfillment of the thesis requirement for the degree of Master of Mathematics in Computer Science Waterloo, Ontario, Canada, 2019 c Huy Hoang 2019 AUTHOR’S DECLARATION I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract Message-Oriented Middleware (MOM) is a popular class of software used in many dis- tributed applications, ranging from business systems and social networks to gaming and streaming media services. As workloads continue to grow both in terms of the number of users and the amount of content, modern MOM systems face increasing demands in terms of performance and scalability. Recent advances in networking such as Remote Di- rect Memory Access (RDMA) offer a more efficient data transfer mechanism compared to traditional kernel-level socket networking used by existing widely-used MOM systems. Unfortunately, RDMA’s complex interface has made it difficult for MOM systems to utilize its capabilities. In this thesis we introduce a framework called RocketBufs, which provides abstrac- tions and interfaces for constructing high-performance MOM systems. Applications im- plemented using RocketBufs produce and consume data using regions of memory called buffers while the framework is responsible for transmitting, receiving and synchronizing buffer access. RocketBufs’ buffer abstraction is designed to work efficiently with different transport protocols, allowing messages to be distributed using RDMA or TCP using the same APIs (i.e., by simply changing a configuration file).
    [Show full text]
  • Communication Protocols of an Industrial Internet of Things Environment: a Comparative Study
    future internet Article Communication Protocols of an Industrial Internet of Things Environment: A Comparative Study Samer Jaloudi Department of Information and Communication Technology, Al Quds Open University, Nablus 00407, West Bank, Palestine; [email protected] or [email protected]; Tel.: +970-0599-376-492 Received: 4 February 2019; Accepted: 4 March 2019; Published: 7 March 2019 Abstract: Most industrial and SCADA-like (supervisory control and data acquisition) systems use proprietary communication protocols, and hence interoperability is not fulfilled. However, the MODBUS TCP is an open de facto standard, and is used for some automation and telecontrol systems. It is based on a polling mechanism and follows the synchronous request–response pattern, as opposed to the asynchronous publish–subscribe pattern. In this study, polling-based and event-based protocols are investigated to realize an open and interoperable Industrial Internet of Things (IIoT) environment. Many Internet of Things (IoT) protocols are introduced and compared, and the message queuing telemetry transport (MQTT) is chosen as the event-based, publish–subscribe protocol. The study shows that MODBUS defines an optimized message structure in the application layer, which is dedicated to industrial applications. In addition, it shows that an event-oriented IoT protocol complements the MODBUS TCP but cannot replace it. Therefore, two scenarios are proposed to build the IIoT environment. The first scenario is to consider the MODBUS TCP as an IoT protocol, and build the environment using the MODBUS TCP on a standalone basis. The second scenario is to use MQTT in conjunction with the MODBUS TCP. The first scenario is efficient and complies with most industrial applications where the request–response pattern is needed only.
    [Show full text]
  • Software Design Pattern 1 Software Design Pattern
    Software design pattern 1 Software design pattern In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages. Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm. History Patterns originated as an architectural concept by Christopher Alexander as early as 1966 (c.f. "The Pattern of Streets," JOURNAL OF THE AIP, September, 1966, Vol. 32, No. 3, pp. 273-278). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year. In the following years, Beck, Cunningham and others followed up on this work.
    [Show full text]
  • 2 on Distributed Systems
    PATTERN-ORIENTED SOFTWARE ARCHITECTURE PATTERN-ORIENTED SOFTWARE ARCHITECTURE A Pattern Language for Distributed Computing Volume 4 Frank Buschmann, Siemens, Munich, Germany Kevlin Henney, Curbralan, Bristol, UK Douglas C. Schmidt, Vanderbilt University, Tennessee, USA Copyright 2007 John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777 Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770620. Front cover Image Copyright 2007 Yann Arthus-Bertrand/Altitude Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The Publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered.
    [Show full text]