DOCSLIB.ORG

Domain-Driven Design with Architectural Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Domain-Driven Design with Architectural Patterns Masaryk University Faculty of Informatics Domain-driven design with architectural patterns Master’s Thesis Marek Turis Brno, Spring 2019 Replace this page with a copy of the official signed thesis assignment anda copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Marek Turis Advisor: RNDr. Jaroslav Bayer i Acknowledgements I would like to thank my supervisor, RNDr. Jaroslav Bayer, for his guidance and valuable advice while writing this thesis. I would also like to thank my family and friends for the patience and the support when I did not have as much time for them as I wished. ii Abstract This thesis focuses on Domain-driven design, an approach to software development, and architectural patterns and styles. With an analysis of the patterns in the context of Domain-driven design, the compatibility and possibility of the combination of a given pattern and Domain- driven design are examined. An exemplary system is presented that is built on the principles of Domain-driven design and uses the described architectural patterns and styles. iii Keywords Domain-driven design, software architecture, architectural patterns, architectural styles, domain, bounded context iv Contents 1 Introduction 1 2 Principles of Domain-driven design 3 2.1 Domains ............................3 2.2 Knowledge crunching .....................4 2.3 Domain model .........................5 2.4 Bounded context .......................6 2.5 Context maps .........................7 3 Tactical patterns 10 3.1 Entities ............................ 10 3.2 Value objects ......................... 10 3.3 Domain services ........................ 11 3.4 Aggregates .......................... 11 3.5 Domain events ........................ 11 3.6 Modules ............................ 12 3.7 Factories ............................ 12 3.8 Repositories .......................... 12 4 Architecture 14 4.1 Patterns of domain logic ................... 14 4.1.1 Transaction script . 15 4.1.2 Table module . 16 4.1.3 Anemic domain model . 17 4.2 Architecture of bounded contexts ............... 17 4.2.1 Big ball of mud . 17 4.2.2 Layered Architecture . 19 4.2.3 Hexagonal architecture . 21 4.2.4 IDesign . 22 4.2.5 Command query responsibility segregation . 25 4.2.6 Event sourcing . 28 4.2.7 Pipes and filters . 31 4.3 Top-level architecture ..................... 35 4.3.1 Monolithic architecture . 35 4.3.2 Service-oriented architecture (SOA) . 41 4.4 Integration of bounded contexts ............... 43 v 4.4.1 File transfer . 45 4.4.2 Shared database . 45 4.4.3 Remote procedure invocation . 46 4.4.4 Messaging . 46 5 Designing Domain-driven design system 48 5.1 Requirements ......................... 48 5.2 Analysis ............................ 49 5.3 Top-level architecture ..................... 51 5.4 Architecture of bounded contexts ............... 53 6 Conclusion 57 6.1 Future work .......................... 57 Bibliography 58 vi List of Figures 4.1 Big ball of mud with Domain-driven design 18 4.2 Layered architecture 20 4.3 Layers used on a bounded context level 21 4.4 Hexagonal architecture of one bounded context 23 4.5 IDesign components overview 24 4.6 IDesign method used with DDD on a bounded context level 26 4.7 CQRS applied to the whole system 27 4.8 CQRS using DDD 29 4.9 Event sourcing used together with CQRS and DDD 32 4.10 Pipes and filters inside a bounded context 34 4.11 Monolithic architecture 36 4.12 Layers used on a system level 38 4.13 IDesign – bounded context mismatch 40 4.14 Bounded contexts with different architectures 44 5.1 Bounded contexts and subdomains of UniSys2. 52 5.2 Overview of top-level services. 53 vii 1 Introduction As information technologies were gaining popularity in the second half of the 20th century, requirements on information systems grew rapidly. Small applications evolved into complicated systems with rich features, adapting to the increasing demands of customers. As the size of a system grows, so does its complexity, which can make the system harder to understand, maintain, and evolve. New projects did not have it any easier. Large projects were a particular challenge for architects who needed to design systems that would accommodate the requirements of customers, prove useful in practice, and solve the problems the software was intended to tackle. Failing to correctly grasp the requirements of a customer resulted in a system that was not useful and did not deliver the solution to the problems that mattered most. In 2003, Eric Evans published his book, Domain-Driven Design: Tackling Complexity in the Heart of Software [1] that tries to tackle the challenges of designing large systems. In the book he introduced Domain-driven design (DDD), an approach to software design, with its focus on a modeled domain and collaboration between domain experts and developers throughout the entire software development process. The main contribution of Evans’ work lays in introducing practices, principles and patterns that help in all steps of designing software, from requirements engineering to designing implementation solutions. Since the publication of Evans’ book, DDD was examined and described in many derivative books and articles. These publications focused either on the business side of DDD or its usage at the lower level of the system. Particularly popular are the design (tactical) pat- terns that Evans presented. However, a broader work that would focus on DDD in high-level design and its usage in combination with differ- ent architectural patterns is missing. This thesis focuses on presenting various architecture patterns and examines their compatibility and usage with DDD. The structure of the thesis is as follows. The first part introduces DDD with its principles and patterns. Next chapters focus on architec- ture patterns and styles. Given patterns are always briefly described 1 1. Introduction and, as the main goal of this thesis, their usage with DDD is analyzed, mainly their compatibility with the goals of DDD and the possibil- ity of using them in DDD systems. The most important patterns are demonstrated in practice on an exemplary system. 2 2 Principles of Domain-driven design Domain-driven design is a development philosophy that was defined by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. It is an approach that emphasizes the importance of a domain, its proper understanding and collaboration of domain experts with developers. It also presents patterns that can be used together with gained knowledge to design the best possible solution. The main areas where DDD can help are: ∙ knowledge crunching, ∙ collaboration of domain experts with developers, ∙ system design, ∙ refactoring. 2.1 Domains A Domain is basically what an organization does and the environment it does it in [2]. It is an area in which the company operates, and the software is intended to solve problems in this area. A domain can be decomposed into smaller parts, subdomains. Domain-driven design differentiates three types of subdomains: ∙ core domain, ∙ supporting domain, ∙ generic domain. Core domain A core domain is the most important part; it is the heart of the business. It is what makes money and what is the business most focused on and it has the primary importance to the success of the organization [2]. For example for e-shops, the core domain is selling of goods. The core domain is a subdomain where DDD should be applied the most. 3 2. Principles of Domain-driven design It is essential that it gets the most attention and that it is modeled, designed and developed as good as possible. This should be achieved by the increased involvement of domain experts and participation of the best developers in the team [3]. Supporting domain Supporting domains are domains that are not the main focus of the organization, but they help to support core domains. For example for e-shops, warehouse management is not a core domain, it is not what makes money, it only helps to support the core domain of selling goods. Generic domain A generic domain is the least important domain for an organization. It is a subdomain that many systems have, such as sending newsletters. Generic domain doesn’t require much attention and in an ideal case an existing product can be used to save time which can be rather invested in the core domain. 2.2 Knowledge crunching Domain-driven design puts the domain at the center of every stage of software development. To design a useful system, developers need to understand the domain, the processes that happen in given situa- tions, what is important and how it is achieved. People who provide knowledge about the domain are called domain experts. Domain experts and developers should frequently interact and during the whole development process. Even though this interaction can be time-consuming for both, domain experts and developers, it will pay off in the long run. The ideal situation is when domain expert can be a permanent part of a developer team. The important part is direct and ongoing interaction between domain experts and devel- opers, knowledge crunching based on traditional waterfall software 4 2. Principles of Domain-driven design development model1, in which domain analyst will in requirements engineering stage get knowledge from experts and then pass it to developers, will most likely not lead to best results. This is because developers are limited to the knowledge which domain analyst gained and which he found useful. Furthermore, if they need further informa- tion or explanation, they either cannot get it from an expert, because "that was done in the first stage", or they can only do it very infre- quently to "not bother domain experts too much".
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]
  • 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]
  • 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]
  • 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]
  • Patterns-Of-Enterprise-Application-Architecture-Book.Pdf
    Patterns Of Enterprise Application Architecture Book incorrigiblyNoe foxtrots and slantwise metricised as illaudable her worts. Allen Microporous revivify her and jennets tierced lowe Bishop conscientiously. committed her Torrance bulgur overexposes often wons antiseptically smash or uncanonizing when hydroptic thereby, Odell is misspokeSly synodal? Can be done, domain of architecture patterns of enterprise application mentioned in order We use a very useful not to enterprise application development time you will. Kami melawan kejahatan cybee, many architectural style house is done on what constitutes the enterprises use. Recipient email address and how oop and active record. Please enter with different password. How to pee whether two groups of sequences are holding in cycles? Patterns of Enterprise Application Architecture Addison-Wesley Signature Series Fowler English Edition eBook Martin Fowler Amazonde Kindle Store. Patterns of Enterprise Application Architecture Buy Patterns of. You need to patterns book if so that pattern covered by flipkart store? In possible new book noted software engineering expert Martin Fowler turns his bullshit to enterprise application development He helps professionals understand the. Enterprise application architectures application architecture martin fowler presents the books is a new avenues of the majority of new to. What constitutes the patterns of the actual ha surgido un centro de que quien esté detras del computador sea una calificación general books. This site uses Akismet to reduce spam. Product architecture book takes the application architectures application controller is mainly about topping up the patterns are done only storage facilities, uber and shipped by handing it. Exclusive store state in this book is to delete this time and receive notifications of volunteers worked and system that you have the application.
    [Show full text]
  • The Patterns of Architecture/T3xture
    THE PATTERNS OF ARCHITECTURE NIKOS A. SALINGAROS Published in Lynda Burke, Randy Sovich, and Craig Purcell, Editors: T3XTURE No. 3, CreateSpace Independent Publishing Platform, 2016, pages 7-24. EDITORS’ INTRODUCTION Pattern theory has not as yet transformed architectural practice—despite the acclaim for A Pattern Language, 1 Christopher Alexander’s book, which introduced and substantiated the theory. However, it has generated a great amount of far-ranging, supportive scholarship. In this essay Nikos Salingaros expands the scope of the pattern types under consideration, and explicates some of the mathematical, scientific and humanistic justification for the pattern approach. The author also argues for the manifest superiority of the pattern approach to design over Modernist and contemporary theories of the last one hundred years. To a great extent Dr. Salingaros’s conviction rests on the process and goals of the pattern language method which have as their basis the fundamental realities of the natural world: the mathematics of nature (many that have been studied since the beginning of human history); the process of organic development; and the ideal structural environment for human activity. For Salingaros, Alexander, et al. aesthetics in Architecture derive from these principles rather than from notions of style or artistic inspiration. AUTHOR’S INTRODUCTION — KEY PATTERN CONCEPTS Pattern. A pattern is a discovered organization of space, and also a coherent merging of geometry with human actions. In common usage “pattern” has an expansive definition. In Architecture “pattern” often equates with “solution”. In any discussion of architectural pattern theory the word “pattern” itself is used repeatedly, often with reference to somewhat different concepts.
    [Show full text]
  • Software Architectural Support for Tangible User Interfaces In
    Louisiana State University LSU Digital Commons LSU Doctoral Dissertations Graduate School 2012 Software architectural support for tangible user interfaces in distributed, heterogeneous computing environments Cornelius Toole Louisiana State University and Agricultural and Mechanical College, [email protected] Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_dissertations Part of the Computer Sciences Commons Recommended Citation Toole, Cornelius, "Software architectural support for tangible user interfaces in distributed, heterogeneous computing environments" (2012). LSU Doctoral Dissertations. 932. https://digitalcommons.lsu.edu/gradschool_dissertations/932 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Doctoral Dissertations by an authorized graduate school editor of LSU Digital Commons. For more information, please [email protected]. SOFTWARE ARCHITECTURAL SUPPORT FOR TANGIBLE USER INTERFACES IN DISTRIBUTED, HETEROGENEOUS COMPUTING ENVIRONMENTS A Dissertation Submitted to the Graduate Faculty of the Louisiana State University and Agricultural and Mechanical College in partial fulfillment of the requirements for the degree of Doctor of Philosophy in The Department of Computer Science by Cornelius Toole, Jr. B.S. Computer Science, Jackson State University, 2003 M.S. Computer Science, Jackson State University, 2005 August 2012 Acknowledgments Despite the solitary nature of doctoral studies, this dissertation would not have been possible without the support of my advisor, family, friends and colleagues. Thanks to my committee, Professors Brygg Ullmer, Gabrielle Allen and Bijaya Karki for advising me throughout this process. A special thanks goes to my advisor, Professor Brygg Ullmer, for supporting my research at Louisiana State University. He was very instrumental in my coming to the University for doctoral studies and has shown remarkable zeal in supporting my research interests.
    [Show full text]
  • Peer: an Architectural Pattern∗
    Peer: an Architectural Pattern∗ M. Amoretti, M. Reggiani, F. Zanichelli, G. Conte Distributed Systems Group Dipartimento di Ingegneria dell’Informazione Parco Area delle Scienze, 181A, I-43100, Parma, Italy {amoretti, reggiani, mczane, conte}@ce.unipr.it Abstract Virtual Organizations (VOs) are transitory communities made of individuals and insti- tutions coupled together by advanced communications technologies. Today’s VOs are more and more demanding in terms of efficiency and flexibility of the technological infrastructure. Envisioning VOs in which all participants are both resource providers and consumers, in a peer-to-peer fashion, seems to be an appropriate solution. This paper proposes a structure for programmed elements, i.e. Peers, sharing resources through a peer-to-peer network. Publishing and discovery of resource provision services are managed by the routing and communication modules. The first one creates publication/query messages and computes their destination, which is then used by the communication service to transport the message to the destination Peer. Intent The Peer pattern enables Virtual Organizations whose participants collaborate to deploy, pub- lish, discover, and consume heterogeneous resources (CPU, storage, bandwidth, applications). Example Community support systems is gaining more and more attention in application areas ranging from leisure and customer support to knowledge management. ICT, in particular, is becoming of paramount importance for the so-called Informal Learning, which includes all the activities taking place outside classes and course that aim at understanding, creation of knowledge, and skills acquisition. Several universities around the world have already deployed or are experimenting solutions for course content distribution over their TCP/IP wired/wireless networks and the Internet.
    [Show full text]