DOCSLIB.ORG

Towards Cloud Application Architectural Patterns: Transfer, Evolution, Innovation and Oblivion

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Towards Cloud Application Architectural Patterns: Transfer, Evolution, Innovation and Oblivion Towards cloud application architectural patterns: transfer, evolution, innovation and oblivion Dimitar Dimitrov EXAM WORK 2014 Information Engineering and Management Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan 5 036-10 10 00 (vx) 551 11 Jönköping This exam work has been carried out at the School of Engineering in Jönköping in the subject area Information Engineering and Management. The work is a part of the Master of Science programme. The authors take full responsibility for opinions, conclusions and findings presented. Examiner: He Tan Supervisor: Rob Day Scope: 30 credits (second cycle) Date: Abstract Abstract Recently, cloud computing has been gaining more and more popularity. Misunderstanding, misusing and underutilizing the cloud offerings, though, both from business and technical perspective still poses a threat to the success of cloud projects. On the technical side, one of the main reasons for success or failure is often the architectural design of the system – if a system is not architected the “cloud way”, using cloud’s special characteristics, the business benefits of such a system are often questionable at best. Software architecture through architectural patterns – reusable generic solutions to classes of problems – has for long been a good way to overcome the challenges of software architecture. This paper focuses on establishing the grounds and highlighting the differences of the knowledge transfer regarding architectural patterns from building pre-cloud (“traditional”) software systems to building cloud-native systems. The following 3 research questions drive this research: RQ1. How does the existing knowledge on architectural patterns relate to the cloud computing environment? RQ2. Which characteristics of architectural patterns make them suitable for the cloud environment? RQ3. How can architectural pattern evolution be documented effectively for usage in the practice? In order to answer these 3 research questions and considering their focus is on utility i.e. creating a model which can be directly used in practice, the research uses design science research methodology (Peffers, et al., 2007-8). The emphasis in this methodology is iteratively building artefact(s) which can be improved and proven through practice that they actually help solving the problem at hand. This research contributes with building 4 inter-connected artefacts: a cloud applicability taxonomy of architectural patterns (CATAP) showing how applicable to a cloud environment an architectural pattern is and why; a pattern-to-characteristics mapping showing how using an architectural pattern affects the resulting system in traditional and cloud environments; a pattern form documenting the architectural patterns and the findings about them in the previous two artefacts; a wiki site, APE Wiki, which makes the results available to the public for reference and discussion and improvement. This research has a few interesting findings. First of all, the current architectural pattern knowledge seems to be very mature as no pattern has been found to have significantly evolved because of cloud – the architectural patterns are really generic and very flexible and only their effect on system characteristics has changed with the environment switch. On the other hand, a few new patterns were discovered Abstract and documented, which confirms the need for special attention to the new environment. Apart from that, the pattern-to-characteristics mapping provides interesting insights into which characteristics are most important for cloud and where there is a gap which may need to be filled. This paper presents both the process and the results of the research as equally important as replicating and extending this research could help in maturing the results and the knowledge about architecting systems for cloud thus increasing the chances of success of cloud projects. Keywords Architectural Patterns – Cloud Computing – Knowledge Transfer – Enterprise Software Architectures – Software Engineering Acknowledgements Acknowledgements I would like to express my gratitude to my supervisor, Mr Rob Day, who had the patience and willingness to help me throughout the whole research process. His valuable feedback helped not only the research, but me as a person and professional. I would also like to thank Mr. Eoin Woods who readily joined the initial effort of defining the scope of the thesis and provided comments which later helped ensure better validity of the results. Although not directly related, I am very thankful to all students and teachers at Jönköping University who I had the chance to interact with. Last but not least, I would like to thank my family and friends for the support. I dedicate this work to my mother who had supported me during all my education. Contents Contents List of abbreviations ........................................................................ i List of tables ................................................................................... ii List of figures ................................................................................. iii 1 Introduction ............................................................................. 1 1.1 BACKGROUND ............................................................................................................................. 2 1.2 PURPOSE AND RESEARCH QUESTIONS .......................................................................................... 4 1.3 DELIMITATIONS .......................................................................................................................... 5 1.4 CONVENTIONS ............................................................................................................................ 6 1.5 OUTLINE ..................................................................................................................................... 6 2 Theoretical Background .......................................................... 7 2.1 IMPORTANT DEFINITIONS ............................................................................................................ 7 2.1.1 Cloud computing ............................................................................................................... 7 2.1.2 Software architecture ...................................................................................................... 10 2.1.3 Patterns ........................................................................................................................... 11 2.1.4 Pattern evolution ............................................................................................................ 12 2.1.5 Frameworks, architectural styles, and architectural tactics .......................................... 13 2.2 RELATED WORK ........................................................................................................................ 14 2.2.1 Patterns and pattern languages ...................................................................................... 14 2.2.2 Cloud application architectural patterns ........................................................................ 16 2.2.3 Architectural patterns and architectural decisions ........................................................ 16 2.2.4 Documenting patterns ..................................................................................................... 17 2.2.5 Pattern-oriented system design and evolution through pattern evolution ...................... 18 3 Research Method ................................................................... 21 3.1 CHOICE OF METHOD .................................................................................................................. 21 3.2 DESIGN SCIENCE RESEARCH ...................................................................................................... 21 3.3 IMPLEMENTATION ..................................................................................................................... 24 3.3.1 Problem identification and motivation ........................................................................... 24 3.3.2 Definition of solution objectives ..................................................................................... 25 3.3.3 Design and development ................................................................................................. 26 3.3.4 Demonstration ................................................................................................................ 29 3.3.5 Evaluation ....................................................................................................................... 29 3.3.6 Communication ............................................................................................................... 29 4 Design and Development ...................................................... 30 4.1 CLOUD APPLICABILITY TAXONOMY OF ARCHITECTURAL PATTERNS (CATAP) ......................... 30 4.1.1 CATAP construction process .......................................................................................... 30 4.1.2 Selection of architectural patterns for the CATAP ......................................................... 31 4.1.3 The CATAP ..................................................................................................................... 34 4.1.4 Discussion of patterns with respect to the CATAP ......................................................... 35 4.1.5 Analysis of the CATAP ...................................................................................................
Load more

Recommended publications
  • Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp
    Kyle Brown An Introduction to Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp. 4001 Weston Parkway CSC591O Cary, North Carolina 27513-2303 April 7-9, 1997 919-481-4000 Raleigh, NC [email protected] http://www.ksccary.com Copyright (C) 1996, Kyle Brown, Bobby Woolf, and 1 2 Knowledge Systems Corp. All rights reserved. Overview Bobby Woolf Senior Member of Technical Staff O Patterns Knowledge Systems Corp. O Software Patterns 4001 Weston Parkway O Design Patterns Cary, North Carolina 27513-2303 O Architectural Patterns 919-481-4000 O Pattern Catalogs [email protected] O Pattern Languages http://www.ksccary.com 3 4 Patterns -- Why? Patterns -- Why? !@#$ O Learning software development is hard » Lots of new concepts O Must be some way to » Hard to distinguish good communicate better ideas from bad ones » Allow us to concentrate O Languages and on the problem frameworks are very O Patterns can provide the complex answer » Too much to explain » Much of their structure is incidental to our problem 5 6 Patterns -- What? Patterns -- Parts O Patterns are made up of four main parts O What is a pattern? » Title -- the name of the pattern » A solution to a problem in a context » Problem -- a statement of what the pattern solves » A structured way of representing design » Context -- a discussion of the constraints and information in prose and diagrams forces on the problem »A way of communicating design information from an expert to a novice » Solution -- a description of how to solve the problem » Generative:
    [Show full text]
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ￭ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ￭ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ￭ discordapp.com ▹ Slack ￭ slack.com ▹ Riot.im ￭ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Capturing Interactions in Architectural Patterns
    Capturing Interactions in Architectural Patterns Dharmendra K Yadav Rushikesh K Joshi Department of Computer Science and Engineering Department of Computer Science and Engineering Indian Institute of Technology Bombay Indian Institute of Technology Bombay Powai, Mumbai 400076, India Powai, Mumbai 400076, India Email: [email protected] Email: [email protected] TABLE I Abstract—Patterns of software architecture help in describing ASUMMARY OF CCS COMBINATORS structural and functional properties of the system in terms of smaller components. The emphasis of this work is on capturing P rimitives & Descriptions Architectural the aspects of pattern descriptions and the properties of inter- Examples Significance component interactions including non-deterministic behavior. Prefix (.) Action sequence intra-component Through these descriptions we capture structural and behavioral p1.p2 sequential flow specifications as well as properties against which the specifications Summation (+) Nondeterminism choice within a component are verified. The patterns covered in this paper are variants of A1 + A2 Proxy, Chain, MVC, Acceptor-Connector, Publisher-Subscriber Composition (|) Connect matching multiple connected and Dinning Philosopher patterns. While the machines are CCS- A1 | A2 i/o ports in assembly components based, the properties have been described in Modal µ-Calculus. Restriction (\) Hiding ports from Internal The approach serves as a framework for precise architectural A\{p1, k1, ..} further composition features descriptions. Relabeling ([]) Renaming of ports syntactic renaming A[new/old, ..] I. INTRODUCTION In component/connector based architectural descriptions [6], [13], components are primary entities having identities in the represents interface points as ports uses a subset of CSP for system and connectors provide the means for communication it’s formal semantics.
    [Show full text]
  • Wiki As Pattern Language
    Wiki as Pattern Language Ward Cunningham Cunningham and Cunningham, Inc.1 Sustasis Foundation Portland, Oregon Michael W. Mehaffy Faculty of Architecture Delft University of Technology2 Sustasis Foundation Portland, Oregon Abstract We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show here how the relationship is deeper than previously understood, opening up the possibility of expanded capability for wikis, including a new generation of “federated” wiki. [NOTE TO REVIEWERS: This paper is part first-person history and part theory. The history is given by one of the participants, an original developer of wiki and co-developer of pattern language. The theory points toward future potential of pattern language within a federated, peer-to-peer framework.] 1. Introduction Wiki is today widely established as a kind of website that allows users to quickly and easily share, modify and improve information collaboratively (Leuf and Cunningham, 2001). It is described on Wikipedia – perhaps its best known example – as “a website which allows its users to add, modify, or delete its content via a web browser usually using a simplified markup language or a rich-text editor” (Wikipedia, 2013). Wiki is so well established, in fact, that a Google search engine result for the term displays approximately 1.25 billion page “hits”, or pages on the World Wide Web that include this term somewhere within their text (Google, 2013a). Along with this growth, the definition of what constitutes a “wiki” has broadened since its introduction in 1995. Consider the example of WikiLeaks, where editable content would defeat the purpose of the site.
    [Show full text]
  • Enterprise Integration Patterns Introduction
    Enterprise Integration Patterns Gregor Hohpe Sr. Architect, ThoughtWorks [email protected] July 23, 2002 Introduction Integration of applications and business processes is a top priority for many enterprises today. Requirements for improved customer service or self-service, rapidly changing business environments and support for mergers and acquisitions are major drivers for increased integration between existing “stovepipe” systems. Very few new business applications are being developed or deployed without a major focus on integration, essentially making integratability a defining quality of enterprise applications. Many different tools and technologies are available in the marketplace to address the inevitable complexities of integrating disparate systems. Enterprise Application Integration (EAI) tool suites offer proprietary messaging mechanisms, enriched with powerful tools for metadata management, visual editing of data transformations and a series of adapters for various popular business applications. Newer technologies such as the JMS specification and Web Services standards have intensified the focus on integration technologies and best practices. Architecting an integration solution is a complex task. There are many conflicting drivers and even more possible ‘right’ solutions. Whether the architecture was in fact a good choice usually is not known until many months or even years later, when inevitable changes and additions put the original architecture to test. There is no cookbook for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines and principles. As a result, successful enterprise integration architects tend to be few and far in between and have usually acquired their knowledge the hard way.
    [Show full text]
  • Tiddlywiki in Science Education
    1 TiddlyWiki in Science Education Franco Bagnoli Dipartimento di Energetica & Centro Dinamiche Complesse Universita` di Firenze, I-50139 Firenze, Italy Email: [email protected] Peter Jipsen Department of Mathematics and Computer Science Chapman University, Orange, CA 92866, USA Email: [email protected] Andrea Sterbini Dipartimento di Informatica Universita` di Roma 1, I-00198 Roma, Italy Email: [email protected] Abstract— We discuss here an ongoing experiment and questions are communicated and answered by which uses ASciencePad [1], an adapted version of Tid- voice, or using e-mail, web forms and chat forums, dlyWiki [2] as a support for teaching/learning physics but seldom stored and/or converted to a structured (elementary and advanced) to engineering students. form, like for instance a FAQ table. ASciencePad is a “live math notebook” that is editable with a modern browser and includes a WYSIWYG editor This almost one-way communication is rather with mathematical formulas and SVG plots. It allows unsatisfactory, especially when teachers and stu- also the inclusion of JavaScript simulations, that can be dents come from a very different background, like easily edited by users and therefore can be used as a in our case of teaching physics for two master playground for computational experiments. Our graph level courses in environmental engineering. Stu- drawing extension allows the construction of graph maps dents’ feedback, possibly in the form of an edited of the learning paths to help the student navigate through the notebook topics. frequently asked question (FAQ) list, is a didacti- This client-side tool is complemented by a wiki-based cally valuable tool.
    [Show full text]
  • A Survey of Architectural Styles.V4
    Survey of Architectural Styles Alexander Bird, Bianca Esguerra, Jack Li Liu, Vergil Marana, Jack Kha Nguyen, Neil Oluwagbeminiyi Okikiolu, Navid Pourmantaz Department of Software Engineering University of Calgary Calgary, Canada Abstract— In software engineering, an architectural style is a and implementation; the capabilities and experience of highest-level description of an accepted solution to a common developers; and the infrastructure and organizational software problem. This paper describes and compares a selection constraints [30]. These styles are not presented as out-of-the- of nine accepted architectural styles selected by the authors and box solutions, but rather a framework within which a specific applicable in various domains. Each pattern is presented in a software design may be made. If one were to say “that cannot general sense and with a domain example, and then evaluated in be called a layered architecture because the such and such a terms of benefits and drawbacks. Then, the styles are compared layer must communicate with an object other than the layer in a condensed table of advantages and disadvantages which is above and below it” then one would have missed the point of useful both as a summary of the architectural styles as well as a architectural styles and design patterns. They are not intended tool for selecting a style to apply to a particular project. The to be definitive and final, but rather suggestive and a starting paper is written to accomplish the following purposes: (1) to give readers a general sense of several architectural styles and when point, not to be used as a rule book but rather a source of and when not to apply them, (2) to facilitate software system inspiration.
    [Show full text]
  • Pattern Languages in HCI: a Critical Review
    HUMAN–COMPUTER INTERACTION, 2006, Volume 21, pp. 49–102 Copyright © 2006, Lawrence Erlbaum Associates, Inc. Pattern Languages in HCI: A Critical Review Andy Dearden Sheffield Hallam University Janet Finlay Leeds Metropolitan University ABSTRACT This article presents a critical review of patterns and pattern languages in hu- man–computer interaction (HCI). In recent years, patterns and pattern languages have received considerable attention in HCI for their potential as a means for de- veloping and communicating information and knowledge to support good de- sign. This review examines the background to patterns and pattern languages in HCI, and seeks to locate pattern languages in relation to other approaches to in- teraction design. The review explores four key issues: What is a pattern? What is a pattern language? How are patterns and pattern languages used? and How are values reflected in the pattern-based approach to design? Following on from the review, a future research agenda is proposed for patterns and pattern languages in HCI. Andy Dearden is an interaction designer with an interest in knowledge sharing and communication in software development. He is a senior lecturer in the Com- munication and Computing Research Centre at Sheffield Hallam University. Janet Finlay is a usability researcher with an interest in design communication and systems evaluation. She is Professor of Interactive Systems in Innovation North at Leeds Metropolitan University. 50 DEARDEN AND FINLAY CONTENTS 1. INTRODUCTION 2. THE SCOPE OF THIS REVIEW 2.1. General Software Design Patterns 2.2. Interface Software Design Patterns 2.3. Interaction Design Patterns 3. A SHORT HISTORY OF PATTERNS 3.1.
    [Show full text]
  • The Origins of Pattern Theory the Future of the Theory, and the Generation of a Living World
    THE ORIGINS OF PATTERN THEORY THE FUTURE OF THE THEORY, AND THE GENERATION OF A LIVING WORLD Christopher Alexander Introduction by James O. Coplien nce in a great while, a great idea makes it across the boundary of one discipline to take root in another. The adoption of Christopher O Alexander’s patterns by the software community is one such event. Alexander both commands respect and inspires controversy in his own discipline; he is the author of several books with long-running publication records, the first recipient of the AIA Gold Medal for Research, a member of the Swedish Royal Academy since 1980, a member of the American Academy of Arts and Sciences, recipient of dozens of awards and honors including the Best Building in Japan award in 1985, and the American Association of Collegiate Schools of Architecture Distinguished Professor Award. It is odd that his ideas should have found a home in software, a discipline that deals not with timbers and tiles but with pure thought stuff, and with ephemeral and weightless products called programs. The software community embraced the pattern vision for its relevance to problems that had long plagued software design in general and object-oriented design in particular. September/October 1999 IEEE Software 71 Focusing on objects had caused us to lose the pattern discipline that the software community has system perspective. Preoccupation with design yet scarcely touched: the moral imperative to build method had caused us to lose the human perspec- whole systems that contribute powerfully to the tive. The curious parallels between Alexander’s quality of life, as we recognize and rise to the re- world of buildings and our world of software con- sponsibility that accompanies our position of influ- struction helped the ideas to take root and thrive in ence in the world.
    [Show full text]
  • Which Wiki for Which Uses
    Which wiki for which uses There are over 120 Wiki software available to set up a wiki plateform. Those listed below are the 13 more popular (by alphabetic order) wiki engines as listed on http://wikimatrix.org on the 16th of March 2012. The software license decides on what conditions a certain software may be used. Among other things, the software license decide conditions to run, study the code, modify the code and redistribute copies or modified copies of the software. Wiki software are available either hosted on a wiki farm or downloadable to be installed locally. Wiki software Reference Languages Wikifarm Technology Licence Main audience Additional notes name organization available available very frequently met in corporate environment. Arguably the most widely deployed wiki software in the entreprise market. A zero- Confluence Atlassian Java proprietary 11 confluence entreprise cost license program is available for non-profit organizations and open source projects aimed at small companies’ documentation needs. It works on plain DokuWiki several companies Php GPL2 50 small companies text files and thus needs no database. DrupalWiki Kontextwork.de Php GPL2+ 12 entreprise DrupalWiki is intended for enterprise use Entreprise wiki. Foswiki is a wiki + structured data + Foswiki community Perl GPL2 22 entreprise programmable pages education, public Wikimedia Php with backend MediaWiki is probably the best known wiki software as it is the MediaWiki GPLv2+ >300 wikia and many hostingservice, companies private Foundation and others database one used by Wikipedia. May support very large communities knowledge-based site MindTouchTCS MindTouch Inc. Php proprietary 26 SamePage partly opensource and partly proprietary extensions Jürgen Hermann & Python with flat tech savy MoinMoin GPL2 10+ ourproject.org Rather intended for small to middle size workgroup.
    [Show full text]
  • The Tiddlywiki Manual
    THETHE BOOKBOOK OFOF TT II DD DD LL YY WW II KK II ADVANCED CUSTOMIZATION LUIS J. GONZÁLEZ CABALLERO Advanced Customization Luis Javier González Caballero November 28, 2019 Acknowledgements This book would not have been possible without the help of people from the tiddlywiki google group. Special thanks to: • Ton Gerner for his help with css classes. • Riz for his help with templates. • Mohammad Rahmani for his wonderful wikis and plugins. • Chris Hunt for his Tiddlywiki coding notes. 3 Contents 1 Introduction 11 1.1 Key points............................................ 11 1.2 What is tiddlywiki........................................ 12 1.3 Starting with tiddlywiki..................................... 13 1.4 Reasons to use tiddlywiki.................................... 13 1.5 Elements of TW......................................... 14 1.5.1 The screen........................................ 14 1.5.2 Tiddlers.......................................... 14 1.5.3 The Story River..................................... 15 1.5.4 Tags............................................ 15 1.5.5 Fields........................................... 16 1.5.6 Text format........................................ 16 1.5.7 Transclusion....................................... 16 1.5.8 Templates......................................... 16 1.5.9 Filters........................................... 16 1.5.10 Macros and widgets................................... 16 1.5.11 Mechanism........................................ 17 1.5.12 Lists...........................................
    [Show full text]
  • Understanding Architectural Assets
    ® IBM Software Group Understanding Architectural Assets Peter Eeles [email protected] © 2008 IBM Corporation IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 2 IBM Software Group | Rational software Inputs into this Presentation Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008 18 – 22 February 2008, Vancouver, BC, Canada Working session: Architectural Knowledge IBM Asset Architecture Board Reusable Asset Specification Rational Asset Manager RUP for Asset-based Development © 2006 Tourism Vancouver 3 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 4 IBM Software Group | Rational software Sources of Architecture Theft From a previous system or from technical literature Method An approach to deriving the architecture from the requirements Intuition The experience of the architect From “Mommy, Where Do Software Architectures Come From?”, Philippe Kruchten 1st International Workshop on Architectures for Software Systems, Seattle, 1995 5 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 6 IBM Software Group | Rational software What Types of Architectural Asset are there? Reference Design Architecture
    [Show full text]