DOCSLIB.ORG

2.2.3 Cloud Design Patterns (Microsoft Azure)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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 . 57 3.1.2 Impact of Cloud Computing Properties on Applications . 59 3.1.3 IDEAL Properties of Cloud Applications . 63 3.2 Cloud Application Properties in Other Architectural Styles . 66 3.2.1 Distributed Systems . 67 3.2.2 Messaging . 72 3.2.3 Representational State Transfer (REST) . 74 3.2.4 Service-Oriented Architectures . 78 3.3 Reference Cloud Application . 80 3.3.1 Cloud Runtime Environment . 81 4 Contents 3.3.2 Cloud Application . 82 3.3.3 Application Stack . 84 3.4 Architectural Topics for Cloud Applications . 85 3.4.1 Accounting and Controlling . 86 3.4.2 Application Migration . 87 3.4.3 Cloud Integration . 88 3.4.4 Compliance to Laws and Regulations . 89 3.4.5 Data Storage . 90 3.4.6 License Management . 91 3.4.7 Monitoring, Analysis, and Reporting . 91 3.4.8 Multi-Tenant Cloud Middleware . 92 3.4.9 Organizational Structures . 93 3.4.10 Security . 94 3.5 Information Sources for Cloud Computing Patterns . 95 3.5.1 Cloud Providers and Cloud Applications . 95 3.5.2 Existing Patterns . 96 3.6 Chapter Summary . 97 4 Design OF Cloud Computing Patterns 99 4.1 Pattern Document Format . 102 4.2 Pattern Language Structure . 105 4.2.1 References among Patterns . 107 4.2.2 Constraints on the Pattern Language Metamodel 108 4.3 Graphical Design . 111 4.3.1 Pattern Document Layout . 111 4.3.2 Graphical Elements Used in Patterns . 113 4.3.3 Composition of Graphical Elements . 118 4.4 Summary of Cloud Computing Patterns . 121 4.4.1 Cloud Computing Fundamentals . 123 4.4.2 Cloud Offerings . 129 4.4.3 Cloud Application Architectures . 136 5 Contents 4.4.4 Cloud Application Management . 142 4.4.5 Composite Cloud Applications . 145 4.5 Chapter Summary . 148 5 Application OF Cloud Computing Patterns 149 5.1 Accessibility of Cloud Computing Patterns . 151 5.1.1 Categories of Cloud Computing Patterns . 152 5.1.2 Order of Pattern Consideration . 152 5.2 Pattern-Based Design Method for Cloud Applications . 153 5.2.1 Decomposition . 155 5.2.2 Workload . 158 5.2.3 State . 160 5.2.4 Component Refinement . 164 5.2.5 Elasticity and Resiliency . 167 5.3 Chapter Summary . 171 6 TOOLCHAIN FOR Cloud Computing Patterns 173 6.1 Pattern Authoring Toolkit . 175 6.1.1 Information Classification Template . 176 6.1.2 Pattern Document Template and Stencil Set . 178 6.2 Pattern Importer . 179 6.2.1 Pattern Import Format Editor . 179 6.2.2 Pattern Import Format Converter . 182 6.3 Pattern Repository . 183 6.3.1 Pattern Document Database . 184 6.3.2 Pattern Browser . 185 6.3.3 Pattern Recommender . 187 6.3.4 Pattern Editor . 188 6.4 Reference Implementation Repository . 189 6.5 Chapter Summary . 190 6 Contents 7 VALIDATION 193 7.1 Use of Cloud Computing Patterns by Industry Partners 194 7.1.1 Daimler TSS GmbH . 194 7.1.2 Dr. Ing. h.c. F. Porsche AG . 200 7.2 Uninfluenced Use of Cloud Computing Patterns . .203 7.2.1 Use in Research . 204 7.2.2 Use in Industry . 206 7.3 Chapter Summary . 208 8 Conclusions AND Outlook 211 8.1 Answers to Research Questions . 212 8.2 Limitations of Cloud Computing Patterns . 214 8.3 Research Opportunities . 215 8.3.1 Research-Driven Improvement of Patterns . 215 8.3.2 A Pattern Language for IT Applications . 216 8.3.3 Cloud Computing Patterns as Architectural Decisions . 218 8.3.4 Pattern-Based Architectural Modeling . 218 8.4 Chapter Summary . 219 A Detailed Pattern Engineering PrOCESS 221 B Detailed Mapping OF Related Patterns 223 C TOOLCHAIN FOR Cloud Computing Patterns 247 BibliogrAPHY 249 AcknoWLEDGMENTS (Danksagungen) 269 7 List OF AcrONYMS AADL Architecture Analysis & Design Language ACID Atomicity, Consistency, Isolation, Durability ADL Architecture Description Language AG Aktiengesellschaft API Application Programming Interface AWS Amazon Web Services BASE Basically Available, Soft state, Eventual consistency BPEL Business Process Execution Language BPMN Business Process Model and Notation 9 List OF AcrONYMS CAFE Composite Application Framework CAP Consistency, Availability, Partition tolerance CAPEX Capital Expenditures CDN Content Delivery Network CMS Content Management System CPU Central Processing Unit CQRS Command Query Responsibility Segregation CRM Customer Relationship Management CTO Chief Technology Officer DB Database DBMS Database Management System DDOS Distributed Denial of Service DMTF Distributed Management Task Force, Inc. DNS Domain Name System EAI Enterprise Application Integration EC2 (Amazon) Elastic Compute Cloud ERP Enterprise Resource Planning ESB Enterprise Service Bus GB Gigabyte GPS Global Positioning System HATEOAS Hypermedia as the Engine of Application State 10 List OF AcrONYMS HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IDEAL Isolation, Distribution, Elasticity, Automated Management, Loose Coupling IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IT Information Technology LLC Limited Liability Company LUN Logical Unit Number MVP Most Valuable Professional NAT Network Address Translation NFS Network File System NIC Network Interface Controller NIST National Institute of Standards and Technology OASIS Organization for the Advancement of Structured Information Standards OCL Object Constraint Language OPEX Operational Expenditure OVF Open Virtualization Format PHP PHP: Hypertext Preprocessor 11 List OF AcrONYMS PNG Portable Network Graphics RAM Random-Access Memory RDF Resource Description Framework REST Representational State Transfer RPC Remote Procedure Call SLA Service-Level Agreement SOA Service-Oriented Architecture SOC Service-Oriented Computing SQL Structured Query Language UML Unified Modeling Language URI Uniform Resource Identifier URL Uniform Resource Locator VPC (Amazon) Virtual Private Cloud VPN Virtual Private Network WAF Web Application Firewall XML Extensible Markup Language 12 Zusammenfassung Die breite Verfügbarkeit von schnellen Internetzugängen hat die Be- deutung der geographischen Position von IT Betriebsumgebungen re- duziert. Fortschritte in der Verwaltungsfunktionalität von Hardware und Software erlauben es darüber hinaus IT Ressourcen sehr flexibel und automatisiert zur Verfügung zu stellen. Das Geschäftsmodell Cloud Computing entstand auf Basis dieser Entwicklungen. Cloud Anbieter stellen IT Ressourcen, wie Server, Laufzeitumgebungen oder komplette Anwendungen zur Selbstbedienung durch den Kunden über das Internet bereit. Da diese Cloud Dienste sehr große Kundengruppen erreichen, können Anbieter Skaleneffekte ausnutzen. Daher sind Cloud Dienste oft schneller betriebsbereit und günstiger als gleichartige selbstverwaltete IT Ressourcen. Insbesondere können Cloud Ressourcen oftmals flexibel reserviert und freigegeben werden, wodurch Kunden die verwendeten 13 Zusammenfassung Ressourcen innerhalb von Minuten dem aktuellen Bedarf ihrer Anwen- dungen anpassen können. Die Auswirkungen dieser Eigenschaften von Cloud Umgebungen auf die dort betriebenen Anwendungen und die re- sultierenden Herausforderungen waren bisher größtenteils unbekannt. Die von Anbietern bereitgestellte Dokumentation und Architekturricht- linien waren stets auf die spezifischen Cloud Dienste zugeschnitten. Die hier vorgestellten Cloud Computing Patterns sind untereinander verknüpfte strukturierte Dokumente, die bewährte Lösungen zu wie- derkehrenden Architekturproblemen beschreiben, mit denen IT Archi- tekten bei der Erstellung von Cloud Anwendungsarchitekturen und ihrer Verwaltung zur Betriebszeit konfrontiert werden. Diese Patterns (dt. Muster) abstrahieren von technologiespezifischen Anbieterdoku- mentationen und -richtlinien, sowie von existierenden Anwendungen. Daher beschreiben sie abstrakte Architekturrichtlinien, die technolo- gieunabhängiges und langlebiges Erfahrungswissen darstellen. Diese Arbeit beschreibt die strukturierte Identifikation der Cloud Com- puting Patterns, ihr textuelles und grafisches Design, um sie für Men- schen leicht zugänglich zu machen, sowie eine Designmethode für Ihre Anwendung.
Recommended publications
  • Dynamic Deployment of Specialized ESB Instances in the Cloud

    Dynamic Deployment of Specialized ESB Instances in the Cloud

    Institute of Architecture of Application Systems University of Stuttgart Universitätsstraße 38 D-70569 Stuttgart Master Thesis No. 3671 Dynamic Deployment of Specialized ESB instances in the Cloud Roberto Jiménez Sánchez Course of Study: Infotech (Non-Degree) Examiner: Prof. Dr. Frank Leymann Supervisors: Santiago Gómez Sáez Johannes Wettinger Commenced: May 22, 2014 Completed: November 21, 2014 CR-Classification: C.2.4 ; D.2 Abstract In the last years the interaction among heterogeneous applications within one or among mul- tiple enterprises has considerably increased. This fact has arisen several challenges related to how to enable the interaction among enterprises in an interoperable manner. Towards addressing this problem, the Enterprise Service Bus (ESB) has been proposed as an integration middleware capable of wiring all the components of an enterprise system in a transparent and interoperable manner. Enterprise Service Buses are nowadays used to transparently establish and handle interactions among the components within an application or with consumed exter- nal services. There are several ESB solutions available in the market as a result of continuously developing message-based approaches aiming at enabling interoperability among enterprise applications. However, the configuration of an ESB is typically custom, and complex. More- over, there is little support and guidance for developers related to how to efficiently customize and configure the ESB with respect to their application requirements. Consequently, this fact also increments notably the maintenance and operational costs for enterprises. Our target is mainly to simplify the configuration tasks at the same time as provisioning customized ESB instances to satisfy the application’s functional and non-functional requirements.
  • Capturing Interactions in Architectural Patterns

    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.
  • Automatic Verification of Java Design Patterns

    Automatic Verification of Java Design Patterns

    Automatic Verification of Java Design Patterns Alex Blewitt, Alan Bundy, Ian Stark Division of Informatics, University of Edinburgh 80 South Bridge, Edinburgh EH1 1HN, UK [email protected] [email protected] [email protected] Abstract 2. Design patterns There are a number of books which catalogue and de- Design patterns are widely used by object oriented de- scribe design patterns [4, 1, 6] including an informal de- signers and developers for building complex systems in ob- scription of the key features and examples of their use. ject oriented programming languages such as Java. How- However, at the moment there are no books which attempt ever, systems evolve over time, increasing the chance that to formalise these descriptions, possibly for the following the pattern in its original form will be broken. reasons: We attempt to show that many patterns (implemented in Java) can be verified automatically. Patterns are defined 1. The implementation (and description) of the pattern is in terms of variants, mini-patterns, and constraints in a language-specific. pattern description language called SPINE. These specifi- 2. There are often several ways to implement a pattern cations are then processed by HEDGEHOG, an automated within the same language. proof tool that attempts to prove that Java source code 3. Formal language descriptions are not common within meets these specifications. the object oriented development community. Instead, each pattern is presented as a brief description, and an example of its implementation and use. Designers and developers are then expected to learn the ‘feel’ of a pat- 1.
  • Co-Occurrence of Design Patterns and Bad Smells in Software Systems

    Co-Occurrence of Design Patterns and Bad Smells in Software Systems

    XI Brazilian Symposium on Information System, Goi^ania,GO, May 26-29, 2015. Co-Occurrence of Design Patterns and Bad Smells in Software Systems: An Exploratory Study Bruno Cardoso Eduardo Figueiredo Software Engineering Lab (LabSoft) Software Engineering Lab (LabSoft) Federal University of Minas Gerais (UFMG) Federal University of Minas Gerais (UFMG) Belo Horizonte, MG - Brazil Belo Horizonte, MG - Brazil [email protected] [email protected] ABSTRACT In a previous work [1], we performed a systematic literature A design pattern is a general reusable solution to a recurring review in order to understand how studies investigate these two problem in software design. Bad smells are symptoms that may topics, design patterns and bad smells, together. Our results indicate something wrong in the system design or code. showed that, in general, studies have a narrow view concerning Therefore, design patterns and bad smells represent antagonistic the relation between these concepts. Most of them focus on structures. They are subject of recurring research and typically refactoring opportunities. Among these, some tools [3][7][15][17] appear in software systems. Although design patterns represent have been proposed to identify code fragments that can be good design, their use is often inadequate because their refactored to patterns. Other studies [2][6] establish a structural implementation is not always trivial or they may be unnecessarily relationship between the terms design pattern and bad smell. In employed. The inadequate use of design patterns may lead to a addition, there are reported cases in the literature where the use of bad smell. Therefore, this paper performs an exploratory study in design patterns may not always be the best option and the wrong order to identify instances of co-occurrences of design patterns use of a design pattern can even introduce bad smells in code [19] and bad smells.
  • Enterprise Development with Flex

    Enterprise Development with Flex

    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
  • Prof. Catalin Boja, Phd Catalin.Boja@Ie.Ase.Ro Source Code Quality

    Prof. Catalin Boja, Phd [email protected] Source Code Quality

    Design patterns Prof. Catalin Boja, PhD [email protected] http://acs.ase.ro/software-quality-testing Source code quality Principles for writing the code: • Easy to read / understand - clear • Easy to modify - structured • Easy to reuse • Simple (complexity) • Easy to test • Implement patterns for the standard problem Left: Simply Explained: Code Reuse 2009-12- acs.ase.ro [email protected] 03.By Oliver Widder, Webcomics Geek Aad Poke.2 Source code quality Forces that influence it: • Available time (delivery terms) • Costs • The experience of the programmer • Programmer competences • Specifications clarity • Solution complexity • Change rates for specifications, requirements, team, etc http://khristianmcfadyen.com/ acs.ase.ro [email protected] 3 Anti-Pattern: Big ball of mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape- and-baling-wire, spaghetti- code jungle.” Brian Foote and Joseph Yoder, Big Ball of Mud, September 1997 acs.ase.ro [email protected] 4 Anti-Pattern: Big ball of mud Where from ? Why ? • Throwaway code - Temporary (Prototyping) solutions to be replaced / rewritten • Cut and Paste code • Adapting code by commenting / deleting other solutions • Very short or unrealistic deadlines • Lack of experience • Lack of standards / procedures acs.ase.ro [email protected] 5 Anti-Pattern: Big ball of mud How do you avoid it? • Rewriting the code (Refactoring) to an acceptable maturity level • Use Clean Code Principles • Design Patterns Implementation acs.ase.ro [email protected] 6 Design-pattern • A pattern is a reusable solution for a standard problem in a given context • Facilitates the reuse of architectures and software design • They are not data structures acs.ase.ro [email protected] 7 Design-pattern “A pattern involves a general “..
  • Reducing Maintenance Costs Through the Application of Modern Software Architecture Principles

    Reducing Maintenance Costs Through the Application of Modern Software Architecture Principles

    Reducing Maintenance Costs Through the Application of Modern Software Architecture Principles Christine Hulse and Michael Ubnoske Louis Vazquez Scott Edgerton Architecture Technology Department of the Army United Defense, LP Minneapolis, Minnesota Picatinny Arsenal, Minneapolis, Minnesota 1.612.829.5864 New Jersey 1.612.572.6109/6156 [email protected] 1.973.724.5259 [email protected] [email protected] [email protected] 1. ABSTRACT 1.1 Keywords Large software programs are usually long lived Architecture, design patterns, software maintenance, modeling, real-time software and continually evolve. Substantial maintenance effort is often extended by 2. INTRODUCTION engineers trying to understand the software The Crusader Field Artillery System is the U.S. Army's next prior to making changes. To successfully generation 155-mm self-propelled howitzer (SPH) and its companion resupply vehicle (RSV). The Crusader is a evolve the software, a thorough understanding software-intensive system that is being designed to last well of the architect's intentions about software into the next century. Ada95 is the implementation language organization is required. Software for all software development on the Crusader program. maintenance costs can be reduced significantly Modern software architecture methods are being applied to if the software architecture is well defined, capture the general principles used throughout the design and to provide a guide for further development of the clearly documented, and creates an software. The architecture is being modeled using the environment that promotes design consistency Unified Modeling Language (UML) to bring together the through the use of guidelines and design design vision of all of the key stakeholders.
  • Donald F. Ferguson, Ph.D

    Donald F. Ferguson, Ph.D

    Donald F. Ferguson, Ph.D. Seeka TV (www.seekatv.com) 21 Hoyt Street 1201 Marquette Ave S., Suite 200 South Salem, NY 10590 Minneapolis, MN 55403 +1 914-548-5001 +1 914-548-4001 [email protected] [email protected] Education 1989 Ph.D., Computer Science, Columbia University. Thesis – “The Application of Microeconomics to the Design of Resource Allocation and Control Algorithms” 1987 M.Phil., Computer Science, Columbia University. 1985 M.S., Computer Science, Columbia University. 1982 B.A. Com Laude, Computer Science, Columbia University. Professional Experience Seeka TV 2016-Present Co-Founder, VP, Head of Engineering Defining and leading technical strategy, architecture, engineering/development for an interactive video/content streaming startup. The platform targets two scenarios: 1) A web channel for independent film and web series creators; 2) Corporate videos and media delivery for education, marketing, conferences, etc. Seeka TV (www.seeka.tv) is currently delivering over 50 independent, professional web series, and is in pilot phase with several enterprises for corporate education/marketing videos. The solution is completely “serverless” using Amazon Web Services and other cloud technology. Core technologies in use include AWS (Lambda Functions, SQS, SNS, RDS, API Gateway, CloudFront, S3), Neo4J, Stripe, Brightcove, MailChimp, OAuth2, Facebook and Twitter APIs. Columbia University Professor of Professional Practice 2018-Present Adjunct Professor, Dept. of Computer Science 2012-Present Full professor and member of faculty starting 2018. Teaching, research, mentoring and helping align department with industry requirements and practices. Teaching popular (80-100 students) senior/master’s level courses on advanced topics in computer science. Supervising student small team projects.
  • HEDGEHOG: Automatic Verification of Design Patterns in Java

    HEDGEHOG: Automatic Verification of Design Patterns in Java

    HEDGEHOG: Automatic Verification of Design Patterns in Java Alex Blewitt I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy School of Informatics University of Edinburgh 2006 Abstract Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken. To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically. Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications. iii Acknowledgements I am indebted to Alan Bundy who has given me the freedom to work on this thesis whilst at the same time guiding me towards the final production and presentation of these results. I not would have been able to achieve this without Alan’s support through a sometimes difficult, but always busy part of my life. This project, and especially the production of this thesis, would not have been possible without the care and attention that Alan provided. Ian Stark has provided invaluable feedback on all aspects of this thesis, from the low-level technical intricacies of Java’s design patterns through to the high-level structure of the thesis as a whole.
  • Zeromq

    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.
  • Automating the Provisioning and Integration of Analytics Tools with Data Resources in Industrial Environments Using Opentosca

    Automating the Provisioning and Integration of Analytics Tools with Data Resources in Industrial Environments Using Opentosca

    Institute of Architecture of Application Systems Automating the Provisioning and Integration of Analytics Tools with Data Resources in Industrial Environments using OpenTOSCA Michael Zimmermann, Michael Falkenthal, Felix W. Baumann, Ulrich Odefey Frank Leymann Institute of Architecture of Application Systems, TWT GmbH Science & Innovation, University of Stuttgart, Stuttgart, Germany Stuttgart, Germany {lastname}@iaas.uni-stuttgart.de {firstname}.{lastname}@twt-gmbh.de : @inproceedings{Zimmermann2017_ProvisioningAnalytics, author = {Michael Zimmermann and Felix W. Baumann and Michael Falkenthal and Frank Leymann and Ulrich Odefey}, title = {Automating the Provisioning and Integration of Analytics Tools with Data Resources in Industrial Environments using OpenTOSCA}, booktitle = {Proceedings of the 2017 IEEE 21st International Enterprise Distributed Object Computing Conference Workshops and Demonstrations (EDOCW 2017)}, year = {2017}, pages = {3--7}, doi = {10.1109/EDOCW.2017.10}, publisher = {IEEE Computer Society} } © 2017 IEEE Computer Society. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. Automating the Provisioning and Integration of Analytics Tools with Data Resources in Industrial Environments using OpenTOSCA Michael Zimmermann, Felix W. Baumann, Ulrich Odefey Michael Falkenthal, Frank Leymann TWT GmbH Science & Innovation Institute of Architecture of Application Systems 70565 Stuttgart, Germany University of Stuttgart Email: {firstname}.{lastname}@twt-gmbh.de 70569 Stuttgart, Germany Email: {lastname}@iaas.uni-stuttgart.de Abstract—The fourth industrial revolution is driven by the in- customers, or equipment. Thus, access to this data has to be tegration and analysis of a vast amount of diverse data.
  • Papers from the 12Th Advanced Summer School on Service-Oriented Computing (Summersoc’18)

    Papers from the 12Th Advanced Summer School on Service-Oriented Computing (Summersoc’18)

    RC25681 (WAT1810-052) October 23, 2018 Computer Science IBM Research Report Papers From the 12th Advanced Summer School on Service-Oriented Computing (SummerSOC’18) Johanna Barzen1, Rania Khalaf2, Frank Leymann1, Bernhard Mitschang1 Editors 1University of Stuttgart Universitätsstraße 38 70569 Stuttgart, Germany 2IBM Research Division, Cambridge 75 Binney Street Cambridge, MA 02142 USA Research Division Almaden – Austin – Beijing – Brazil – Cambridge – Dublin – Haifa – India – Kenya – Melbourne – T.J. Watson – Tokyo – Zurich LIMITED DISTRIBUTION NOTICE: This report has been submitted for publication outside of IBM and will probably be copyrighted if accepted for publication. It has been issued as a Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and specific requests. After outside publication, requests should be filled only by reprints or legally obtained copies of the article (e.g., payment of royalties). Many reports are available at http://domino.watson.ibm.com/library/CyberDig.nsf/home. The 12th Advanced Summer School on Service-Oriented Computing June 24 - June 29 2018 Hersonissos, Crete, Greece th The 12 Advanced Summer School on Service Oriented Computing (SummerSOC’18) continued a successful series of summer schools that started in 2007, regularly attracting world-class experts in Service Oriented Computing to present state-of-the-art research during a week-long program organized in several thematic tracks: patterns and IoT, Quantum Computing, formal methods for SOC, computing in the clouds, data science, e-Health and emerging topics. The advanced summer school is regularly attended by top researchers from academia and industry as well as by PhD and graduate students.