DOCSLIB.ORG

Using Design Patterns and Frameworks to Develop Object

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Design Patterns and Frameworks to Develop Object Motivation Using Design Patterns and Frameworks to Develop Developing ecient, robust, extensible, portable, and reusable communication software is Object-Oriented Communication hard Systems It is essential to understand successful tech- niques that have proven e ective to solve Douglas C. Schmidt common development challenges www.cs.wustl.edu/schmidt/ Design patterns and frameworks help to [email protected] capture, articulate, and instantiate these Washington University, St. Louis successful techniques 2 1 Observations Design Patterns Develop ers of communication software con- front recurring challenges that are largely Design patterns represent solutions to prob- application-indep endent lems that arise when developing software within a particular context { e.g., service initialization and distribution, error handling, ow control, event demultiplexing, { i.e., \Patterns == problem/solution pairs in a concurrency control context" Patterns capture the static and dynamic Successful develop ers resolve these chal- structure and collab oration among key par- lenges by applying appropriate design pat- ticipants in software designs terns { They are particularly useful for articulating how and why to resolve non-functional forces However, these patterns have traditionally b een either: Patterns facilitate reuse of successful soft- 1. Lo cked inside heads of exp ert develop ers ware architectures and designs 2. Buried in source co de 3 4 Proxy Pattern Graphical Notation 1: METHOD : BROKER CALL : QUOTER 4: METHOD OBJECT PROXY RETURN PROCESS : CLASS 2: FORWARD THREAD REQUEST 3: RESPONSE CLASS CLIENT CLASS TEMPLATE UTILITY : QUOTER CLASS NETWORK CLASS CATEGORY INHERITS INSTANTIATES SERVER ABSTRACT CLASS A CONTAINS USES Intent: provide a surrogate for another object that controls access to it 5 6 Frameworks A framework is: More Observations { \An integrated collection of comp onents that collab orate to pro duce a reusable architecture Reuse of patterns alone is not sucient for a family of related applications" { Patterns enable reuse of architecture and de- sign knowledge, but not co de directly Frameworks di er from conventional class libraries: 1. Frameworks are \semi-complete" applications To be pro ductive, develop ers must also reuse detailed designs, algorithms, inter- 2. Frameworks address particular application do- mains faces, implementations, etc. 3. Frameworks provide \inversion of control" Application frameworks are an e ective way to achieve broad reuse of software Typically, applications are develop ed by in- heriting from and instantiating framework comp onents 7 8 Tutorial Outline Di erences Between Class Libraries and Frameworks Outline key challenges for developing com- NETWORKING software APPLICATION munication SPECIFIC LOGIC INVOKES MATH ADTS Present the key reusable design patterns framework comp onents in high-p erformance EVENT USER and eb clients and servers DATA W LOOP INTERFACE BASE { Both single-threaded and various multi-threaded are presented (A) CLASS LIBRARY solutions ARCHITECTURE { The patterns and frameworks covered general- ize to other communication software systems NETWORKING USER MATH e.g., ORBs, video-on-demand, medical imag- INTERFACE APPLICATION ing CALL INVOKES SPECIFIC BACKS LOGIC EVENT LOOP Discuss lessons learned from using pat- ADTS and frameworks on pro duction soft- DATABASE terns ware systems (B) APPLICATION FRAMEWORK e.g., telecom, avionics, medical systems ARCHITECTURE { 10 9 Concurrency vs. Parallelism Stand-alone vs. Distributed Application Architectures SERVER PRINTER maxfdp1 read_fds COMPUTER CLIENT WORK FILE REQUEST CD ROM SYSTEM WORK WORK WORK CLIENT REQUEST REQUEST REQUEST (1) STAND-ALONE APPLICATION ARCHITECTURE CLIENT CLIENT TIME CONCURRENT SERVER NAME SERVICE CYCLE SERVICE SERVICE SERVER DISPLAY SERVICE CPU1 CPU2 CPU3 CPU4 FI LE CLIENT NETWORK SERVICE WORK REQUEST PRINT SERVICE WORK WORK WORK CD ROM CLIENT REQUEST REQUEST REQUEST PRINTER FILE SYSTEM CLIENT CLIENT (2) PARALLEL SERVER DISTRIBUTED APPLICATION ARCHITECTURE 11 12 Sources of Complexity Sources of Complexity cont'd Distributed application development exhibits b oth inherent and accidental complexity Accidental complexity results from limita- tions with to ols and techniques, e.g., Inherent complexity results from funda- mental challenges, e.g., { Low-level to ols { Distributed systems e.g., Lack of typ e-secure, portable, re-entrant, and extensible system call interfaces and com- Latency p onent libraries Error handling { Inadequate debugging supp ort Service partitioning and load balancing { Widespread use of algorithmic decomp osition { Concurrent systems Fine for explaining network programming con- cepts and algorithms but inadequate for de- Race conditions veloping large-scale distributed applications Deadlo ck avoidance { Continuous rediscovery and reinvention of core concepts and comp onents Fair scheduling Performance optimization and tuning 14 13 OO Contributions Concurrent Web Client/Server Example Communication software has traditionally b een p erformed using low-level OS mech- anisms, e.g., The following example illustrates a con- { fork/exec current OO architecture for a high-p erformance { Shared memory Web client/server { Signals Key system requirements are: { So ckets and select 1. Robust implementation of HTTP proto col { POSIX pthreads, Solaris threads, Win32 threads { i.e., resilient to incorrect or malicious Web clients/servers OO design patterns and frameworks ele- vate fo cus to application concerns, e.g., 2. Extensible for use with other proto cols { Service functionality and p olicies { e.g., DICOM, HTTP 1.1, SFP { Service con guration 3. Leverage multi-pro cessor hardware and OS soft- { Concurrent event demultiplexing and event han- ware dler dispatching { e.g., Supp ort various concurrency mo dels { Service concurrency and synchronization 16 15 Web Server Software Architecture General Web Client/Server Interactions HTTP HTTP Handler Handler 1: GET ~schmidt WWW HTTP/1.0 WWW Sock Sock HTTP Stream Stream CLIENT SERVER Handler 2: index.html HTTP Sock Acceptor PROTOCOL Stream HTML HANDLERS Event Sock PARSER Dispatcher Acceptor GUI DISPATCHER REQUESTER Event Dispatcher GRAPHICS COMMUNICATION PROTOCOL Encapsulates Web server concurrency and dis- ADAPTER (E.G., HTTP) { patching strategies HTTP Handlers OS KERNEL OS KERNEL Parses HTTP headers and pro cesses requests OS I/O SUBSYSTEM OS I/O SUBSYSTEM { HTTP Acceptor NETWORK ADAPTERS NETWORK ADAPTERS NETWORK { Accepts connections and creates HTTP Han- dlers 17 18 Tactical Patterns Design Patterns in the Web Server Implementation Proxy { \Provide a surrogate or placeholder for another to control access to it" Thread object Thread-per Acceptor Request Pool Strategy Active Connector \De ne a family of algorithms, encapsulate each Object { and make them interchangeable" Thread-per one, Session Service Adapter Half-Sync/ Configurator \Convert the interface of a class into another Half-Async { client exp ects" Asynchronous interface Completion Reactor/ Double Checked Singleton Token Proactor Locking \Ensure a class only has one instance and pro- STRATEGIC PATTERNS { vide a global p oint of access to it" TACTICAL PATTERNS Abstract State State Strategy Adapter Singleton Factory { \Allow an object to alter its b ehavior when its internal state changes" 20 19 Concurrency Patterns Event Handling Patterns Active Object Reactor { \Decouples metho d execution from metho d in- vo cation and simpli es synchronized access to { \Decouples synchronous event demultiplexing shared resources by concurrent threads" and event handler initiation dispatching from services p erformed in resp onse to events" Half-Sync/Half-Async Proactor { \Decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent pro- { \Decouples asynchronous event demultiplexing gramming e ort without degrading execution and event handler completion dispatching from eciency" services p erformed in resp onse to events" Double-Checked Lo cking Optimization Pat- Asynchronous Completion Token tern { \Eciently asso ciates state with the comple- { \Ensures atomic initialization of objects and tion of asynchronous op erations" eliminates unnecessary lo cking overhead on each access" 21 22 Concurrency Architecture Service Initialization Patterns Patterns Connector Thread-p er-Request { \Decouples active connection establishment from the service p erformed once the connection is { \Allows each client request to run concurrently established" in a separate thread" Acceptor Thread Pool { \Decouples passive connection establishment { \Allows up to N requests to execute concur- from the service p erformed once the connec- rently within a pool of threads " tion is established" Thread-p er-Connection Service Con gurator { \Allows each client connection to run concur- { \Decouples the b ehavior of network services rently" from p oint in time at which services are con- gured into an application" Suited for HTTP 1.1, but not HTTP 1.0 23 24 Alternative Web Server Selecting the Server's Concurrency Patterns Concurrency Architecture Problem The following example illustrates the de- sign patterns and framework comp onents { A very strategic design decision for high-p erformance Web servers is selecting an ecient concur- in an OO implementation of a concurrent rency architecture Web Server The following are the key concurrency pat- Forces tern alternatives: { No single concurrency architecture is optimal 1. Reactive { Key factors include
Load more

Recommended publications
  • What Is Spring Framework?
    Software Engineering a.a. 2019-2020 Introduction to Spring Framework Prof. Luca Mainetti Università del Salento Roadmap ■ Introduction to Spring ■ Dependency Injection and IoC ■ Bean ■ AoP ■ Module Architecture Introduction to Spring Framework 2 Luca Mainetti What Is Spring Framework? ■ Spring is the most popular application development framework for Java enterprise ■ Open source Java platform since 2003. ■ Spring supports all main application servers and JEE standards ■ Spring handles the infrastructure so you can focus on your application ■ Current version: 5.0.X Introduction to Spring Framework 3 Luca Mainetti What does Spring offer? ■ Dependency Injection – Also known as IoC (Inversion of Control) ■ Aspect Oriented Programming – Runtime injection-based ■ Portable Service Abstractions – The rest of spring • ORM, DAO, Web MVC, Web, etc. • Allows access to these without knowing how they actually work Introduction to Spring Framework 4 Luca Mainetti Dependency Injection ■ The technology that actually defines Spring (Heart of Spring). ■ Dependency Injection helps us to keep our classes as indepedent as possible. – Increase reuse by applying low coupling – Easy testing – More understandable An injection is the passing of a dependency (a service) to a dependent object (a client). Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern. Introduction to Spring Framework 5 Luca Mainetti Dependency Injection and Inversion of Control (IoC) In software engineering, inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. ■ The Inversion of Control (IoC) is a general concept, and it can be expressed in many different ways and dependency Injection is merely one concrete example of Inversion of Control.
    [Show full text]
  • Design and Performance of a Modular Portable Object Adapter for Distributed, Real-Time, and Embedded CORBA Applications
    Design and Performance of a Modular Portable Object Adapter for Distributed, Real-Time, and Embedded CORBA Applications Raymond Klefstad, Arvind S. Krishna, and Douglas C. Schmidt g fklefstad, krishnaa, schmidt @uci.edu Electrical and Computer Engineering Dept. University of California, Irvine, CA 92697, USA Abstract of distributed computing from application developers to mid- dleware developers. It has been used successfully in large- ZEN is a CORBA ORB designed to support distributed, real- scale business systems where scalability, evolvability, and in- time, and embedded (DRE) applications that have stringent teroperability are essential for success. memory constraints. This paper discusses the design and per- Real-time CORBA [5] is a rapidly maturing DOC middle- formance of ZENs portable object adapter (POA) which is ware technology standardized by the OMG that can simplify an important component in a CORBA object request broker many challenges for DRE applications, just as CORBA has (ORB). This paper makes the following three contributions for large-scale business systems. Real-time CORBA is de- to the study of middleware for memory-constrained DRE ap- signed for applications with hard real-time requirements, such plications. First, it presents three alternative designs of the as avionics mission computing [6]. It can also handle ap- CORBA POA. Second, it explains how design patterns can be plications with stringent soft real-time requirements, such as applied to improve the quality and performance of POA im- telecommunication call processing and streaming video [7]. plementations. Finally, it presents empirical measurements ZEN [8] is an open-source Real-time CORBA object re- based on the ZEN ORB showing how memory footprint can quest broker (ORB) implemented in Real-time Java [9].
    [Show full text]
  • Ioc Containers in Spring
    301AA - Advanced Programming Lecturer: Andrea Corradini [email protected] http://pages.di.unipi.it/corradini/ AP-2018-11: Frameworks and Inversion of Control Frameworks and Inversion of Control • Recap: JavaBeans as Components • Frameworks, Component Frameworks and their features • Frameworks vs IDEs • Inversion of Control and Containers • Frameworks vs Libraries • Decoupling Components • Dependency Injection • IoC Containers in Spring 2 Components: a recap A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. Clemens Szyperski, ECOOP 1996 • Examples: Java Beans, CLR Assemblies • Contractually specified interfaces: events, methods and properties • Explicit context dependencies: serializable, constructor with no argument • Subject to composition: connection to other beans – Using connection oriented programming (event source and listeners/delegates) 3 Towards Component Frameworks • Software Framework: A collection of common code providing generic functionality that can be selectively overridden or specialized by user code providing specific functionality • Application Framework: A software framework used to implement the standard structure of an application for a specific development environment. • Examples: – GUI Frameworks – Web Frameworks – Concurrency Frameworks 4 Examples of Frameworks Web Application Frameworks GUI Toolkits 5 Examples: General Software Frameworks – .NET – Windows platform. Provides language interoperability – Android SDK – Supports development of apps in Java (but does not use a JVM!) – Cocoa – Apple’s native OO API for macOS. Includes C standard library and the Objective-C runtime. – Eclipse – Cross-platform, easily extensible IDE with plugins 6 Examples: GUI Frameworks • Frameworks for Application with GUI – MFC - Microsoft Foundation Class Library.
    [Show full text]
  • Servant Documentation Release
    servant Documentation Release Servant Contributors February 09, 2018 Contents 1 Introduction 3 2 Tutorial 5 2.1 A web API as a type...........................................5 2.2 Serving an API.............................................. 10 2.3 Querying an API............................................. 28 2.4 Generating Javascript functions to query an API............................ 31 2.5 Custom function name builder...................................... 38 2.6 Documenting an API........................................... 38 2.7 Authentication in Servant........................................ 43 3 Cookbook 51 3.1 Structuring APIs............................................. 51 3.2 Serving web applications over HTTPS................................. 54 3.3 SQLite database............................................. 54 3.4 PostgreSQL connection pool....................................... 56 3.5 Using a custom monad.......................................... 58 3.6 Basic Authentication........................................... 60 3.7 Combining JWT-based authentication with basic access authentication................ 62 3.8 File Upload (multipart/form-data)............................... 65 4 Example Projects 69 5 Helpful Links 71 i ii servant Documentation, Release servant is a set of packages for declaring web APIs at the type-level and then using those API specifications to: • write servers (this part of servant can be considered a web framework), • obtain client functions (in haskell), • generate client functions for other programming
    [Show full text]
  • Inversion of Control in Spring – Using Annotation
    Inversion of Control in Spring – Using Annotation In this chapter, we will configure Spring beans and the Dependency Injection using annotations. Spring provides support for annotation-based container configuration. We will go through bean management using stereotypical annotations and bean scope using annotations. We will then take a look at an annotation called @Required, which allows us to specify which dependencies are actually required. We will also see annotation-based dependency injections and life cycle annotations. We will use the autowired annotation to wire up dependencies in the same way as we did using XML in the previous chapter. You will then learn how to add dependencies by type and by name. We will also use qualifier to narrow down Dependency Injections. We will also understand how to perform Java-based configuration in Spring. We will then try to listen to and publish events in Spring. We will also see how to reference beans using Spring Expression Language (SpEL), invoke methods using SpEL, and use operators with SpEL. We will then discuss regular expressions using SpEL. Spring provides text message and internationalization, which we will learn to implement in our application. Here's a list of the topics covered in this chapter: • Container configuration using annotations • Java-based configuration in Spring • Event handling in Spring • Text message and internationalization [ 1 ] Inversion of Control in Spring – Using Annotation Container configuration using annotation Container configuration using Spring XML sometimes raises the possibility of delays in application development and maintenance due to size and complexity. To solve this issue, the Spring Framework supports container configuration using annotations without the need of a separate XML definition.
    [Show full text]
  • Concurrency Patterns for Easier Robotic Coordination
    Concurrency Patterns for Easier Robotic Coordination Andrey Rusakov∗ Jiwon Shin∗ Bertrand Meyer∗† ∗Chair of Software Engineering, Department of Computer Science, ETH Zurich,¨ Switzerland †Software Engineering Lab, Innopolis University, Kazan, Russia fandrey.rusakov, jiwon.shin, [email protected] Abstract— Software design patterns are reusable solutions to Guarded suspension – are chosen for their concurrent nature, commonly occurring problems in software development. Grow- applicability to robotic coordination, and evidence of use ing complexity of robotics software increases the importance of in existing robotics frameworks. The paper aims to help applying proper software engineering principles and methods such as design patterns to robotics. Concurrency design patterns programmers who are not yet experts in concurrency to are particularly interesting to robotics because robots often have identify and then to apply one of the common concurrency- many components that can operate in parallel. However, there based solutions for their applications on robotic coordination. has not yet been any established set of reusable concurrency The rest of the paper is organized as follows: After design patterns for robotics. For this purpose, we choose six presenting related work in Section II, it proceeds with a known concurrency patterns – Future, Periodic timer, Invoke later, Active object, Cooperative cancellation, and Guarded sus- general description of concurrency approach for robotics pension. We demonstrate how these patterns could be used for in Section III. Then the paper presents and describes in solving common robotic coordination tasks. We also discuss detail a number of concurrency patterns related to robotic advantages and disadvantages of the patterns and how existing coordination in Section IV.
    [Show full text]
  • Monadic Functional Reactive Programming
    Monadic Functional Reactive Programming Atze van der Ploeg Centrum Wiskunde & Informatica [email protected] Abstract FRP is based on the notion of a reactive computation: a monadic Functional Reactive Programming (FRP) is a way to program reac- computation which may require the occurrence of external events tive systems in functional style, eliminating many of the problems to continue. The Monadic FRP variant of a signal is a signal that arise from imperative techniques. In this paper, we present an computation: a reactive computation that may also emit values alternative FRP formulation that is based on the notion of a reac- during the computation. tive computation: a monadic computation which may require the This novel formulation has two differences with other FRP occurrence of external events to continue. A signal computation approaches: is a reactive computation that may also emit values. In contrast to • In contrast to signals in other FRP formulations, signal compu- signals in other FRP formulations, signal computations can end, tations can end. This leads to a simple, monadic interface for leading to a monadic interface for sequencing behavioral changes. sequencing behavioral changes. This interface has several advantages: routing is implicit, sequencing • behaviors is easier and more intuitive than the switching combina- In other FRP approaches, either the entire FRP expression is tors found in other FRP approaches, and dynamic lists require much re-evaluated on each external stimulus, or impure techniques less boilerplate code. In other FRP approaches, either the entire are used to prevent redundant re-computations: re-computing FRP expression is re-evaluated on each external stimulus, or impure the current value of signal while the input it depends on has not techniques are used to prevent redundant re-computations.
    [Show full text]
  • Servant Documentation Release
    servant Documentation Release Servant Contributors March 07, 2016 Contents 1 Introduction 3 2 Tutorial 5 2.1 A web API as a type...........................................5 2.2 Serving an API..............................................9 2.3 Querying an API............................................. 25 2.4 Generating Javascript functions to query an API............................ 28 2.5 Documenting an API........................................... 30 3 Helpful Links 35 i ii servant Documentation, Release servant is a set of packages for declaring web APIs at the type-level and then using those API specifications to: • write servers (this part of servant can be considered a web framework), • obtain client functions (in haskell), • generate client functions for other programming languages, • generate documentation for your web applications • and more... All in a type-safe manner. Contents 1 servant Documentation, Release 2 Contents CHAPTER 1 Introduction servant has the following guiding principles: • concision This is a pretty wide-ranging principle. You should be able to get nice documentation for your web servers, and client libraries, without repeating yourself. You should not have to manually serialize and deserialize your resources, but only declare how to do those things once per type. If a bunch of your handlers take the same query parameters, you shouldn’t have to repeat that logic for each handler, but instead just “apply” it to all of them at once. Your handlers shouldn’t be where composition goes to die. And so on. • flexibility If we haven’t thought of your use case, it should still be easily achievable. If you want to use templating library X, go ahead. Forms? Do them however you want, but without difficulty.
    [Show full text]
  • The Spring Framework: an Open Source Java Platform for Developing Robust Java Applications
    International Journal of Innovative Technology and Exploring Engineering (IJITEE) ISSN: 2278-3075, Volume-3 Issue-2, July 2013 The Spring Framework: An Open Source Java Platform for Developing Robust Java Applications Dashrath Mane, Ketaki Chitnis, Namrata Ojha Abstract— The fundamental concepts of Spring Framework is Supported deployment platforms range from standalone presented in this paper.Spring framework is an open source Java applications to Tomcat and Java EE servers such as platform that provides comprehensive infrastructure support for WebSphere. Spring is also a first-class citizen on major developing robust Java applications very easily and very rapidly. cloud platforms with Java support, e.g. on Heroku, Google The Spring Framework is a lightweight solution and a potential App Engine, Amazon Elastic Beanstalk and VMware's one-stop-shop for building your enterprise-ready applications. Cloud Foundry.[1] IndexTerms— Aspect Oriented Programming, Dependency Injection, IoC Container, ORM. II. SPRING FRAMEWORK ARCHITECTURE Spring could potentially be a one-stop shop for all your I. INTRODUCTION enterprise applications; however, Spring is modular, Spring is the most popular application development allowing you to pick and choose which modules are framework for enterprise Java. Millions of developers applicable to you, without having to bring in the rest. around the world use Spring Framework to create high The Spring Framework provides about 20 modules which performing, easily testable, reusable code. Spring can be used based on an application requirement. framework is an open source Java platform and it was initially written by Rod Johnson and was first released under the Apache 2.0 license in June 2003.
    [Show full text]
  • An Introduction to Dependency Inversion Page 1 of 12
    Peruse Muse Infuse: An Introduction to Dependency Inversion Page 1 of 12 An Introduction to Dependency Inversion Originaly posted by AdrianK, 1-Nov-2010 at: http://www.morphological.geek.nz/blogs/viewpost/Peruse Muse Infuse/An Introduction to Dependency Inversion.aspx Tagged under: Architecture, Web Development, Patterns An Introduction to Dependency Inversion This article is for anyone (mainly developers, and specifically .Net developers) who is unfamiliar with Dependency Inversion or design patterns in general. The basic rationale behind the Dependency Inversion Principle [1] (DIP, or simply DI) is very simple; and like most other simple design principles it is suitable in many different situations. Once you understand it you’ll wonder how you managed without it. The key benefit it brings is control over dependencies – by removing them (or perhaps more correctly – by “inverting” them), and this isn’t just limited to “code” – you’ll find this also opens up new opportunities regarding how you can structure and run the actual development process. Implementing DI and is fairly straight forward and will often involve other design patterns, such as the Factory pattern [2] and Lazy Load pattern [3] ; and embodies several other principles including the Stable Abstractions Principle and Interface Segregation Principle. I’ll be using acronyms where I can, here’s a quick glossary for them. • BL: Business Logic, sometimes referred to as the Business Logic Layer. • DA: Data Access, often referred to as the DAL or Data Access Layer. • DI: can refer to either Dependency Inversion or Dependency Injection – both of which (at least for this article) essentially mean the same thing.
    [Show full text]
  • Isolated Actors for Race-Free Concurrent Programming
    Isolated Actors for Race-Free Concurrent Programming THÈSE NO 4874 (2010) PRÉSENTÉE LE 26 NOVEMBRE 2010 À LA FACULTÉ INFORMATIQUE ET COMMUNICATIONS LABORATOIRE DE MÉTHODES DE PROGRAMMATION 1 PROGRAMME DOCTORAL EN INFORMATIQUE, COMMUNICATIONS ET INFORMATION ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Philipp HALLER acceptée sur proposition du jury: Prof. B. Faltings, président du jury Prof. M. Odersky, directeur de thèse Prof. D. Clarke, rapporteur Prof. V. Kuncak, rapporteur Prof. P. Müller, rapporteur Suisse 2010 ii Abstract Message-based concurrency using actors has the potential to scale from multi- core processors to distributed systems. However, several challenges remain until actor-based programming can be applied on a large scale. First, actor implementations must be efficient and highly scalable to meet the demands of large-scale distributed applications. Existing implementations for mainstream platforms achieve high performance and scalability only at the cost of flexibility and ease of use: the control inversion introduced by event-driven designs and the absence of fine-grained message filtering complicate the logic of application programs. Second, common requirements pertaining to performance and interoperability make programs prone to concurrency bugs: reusing code that relies on lower-level synchronization primitives may introduce livelocks; passing mutable messages by reference may lead to data races. This thesis describes the design and implementation of Scala Actors. Our sys- tem offers the efficiency and scalability required by large-scale production sys- tems, in some cases exceeding the performance of state-of-the-art JVM-based ac- tor implementations. At the same time, the programming model (a) avoids the control inversion of event-driven designs, and (b) supports a flexible message re- ception operation.
    [Show full text]
  • Design Patterns
    Design Patterns Andy Verkeyn April 2001 - March 2003 Third version [email protected] http://allserv.rug.ac.be/~averkeyn Contents Contents ______________________________________________________________________ 1 Foreword _____________________________________________________________________ 1 Introduction___________________________________________________________________ 1 Iterator _______________________________________________________________________ 2 Adapter (class)_________________________________________________________________ 4 Adapter (object) ________________________________________________________________ 5 Decorator _____________________________________________________________________ 7 Singleton _____________________________________________________________________ 9 Chain of responsibility _________________________________________________________ 12 Observer_____________________________________________________________________ 14 Command____________________________________________________________________ 16 Bridge_______________________________________________________________________ 18 Factory method _______________________________________________________________ 20 Abstract factory _______________________________________________________________ 21 Proxy _______________________________________________________________________ 22 Other patterns used in Java _____________________________________________________ 24 Foreword This text is mainly taken from the excellent book “Design patterns: Elements of reusable Object- Oriented
    [Show full text]