DOCSLIB.ORG

Efficient Engineering and Execution of Pipe-And-Filter Architectures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Efficient Engineering and Execution of Pipe-and-Filter Architectures Dissertation M.Sc. Christian Wulf Dissertation zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) der Technischen Fakultät der Christian-Albrechts-Universität zu Kiel eingereicht im Jahr 2019 1. Gutachter: Prof. Dr. Wilhelm Hasselbring Christian-Albrechts-Universität zu Kiel 2. Gutachter: Prof. Dr. Steffen Becker Universität Stuttgart Datum der mündlichen Prüfung: 19. Juli 2019 ii Zusammenfassung Pipe-and-Filter (P&F) ist ein wohlbekannter und häufig verwendeter Archi- tekturstil. Allerdings gibt es unseres Wissens nach kein P&F-Framework, das beliebige P&F-Architekturen sowohl modellieren als auch ausführen kann. Beispielsweise unterstützen die Frameworks FastFlow, StreamIT and Spark nicht mehrere Input- und Output-Ströme pro Filter, sodass sie kei- ne Verzweigungen modellieren können. Andere Frameworks beschränken sich auf sehr spezielle Anwendungsfälle oder lassen die Typsicherheit zwi- schen zwei miteinander verbundenen Filtern außer Acht. Außerdem ist eine effiziente parallele Ausführung von P&F-Architekturen weiterhin eine Herausforderung. Obwohl einige vorhandene Frameworks Filter parallel ausführen können, gibt es noch viel Optimierungspotential. Leider besit- zen die meisten Frameworks kaum Möglichkeiten, die einzig vorhandene Ausführungsstrategie ohne großen Aufwand anzupassen. In dieser Arbeit präsentieren wir unser generisches und paralleles P&F- Framework TeeTime. Es kann beliebige P&F-Architekturen sowohl model- lieren als auch ausführen. Gleichzeitig ist es offen für Modifikationen, um mit dem P&F-Stil zu experimentieren. Zudem erlaubt es, Filter effizient und parallel auf heutigen Multi-core-Systemen auszuführen. Umfangreiche Laborexperimente zeigen, dass TeeTime nur einen sehr geringen und in gewissen Fällen gar keinen zusätzlichen Laufzeit-Overhead im Vergleich zu Implementierungen ohne P&F-Abstraktionen erfordert. Außerdem weisen wir TeeTimes breite Anwendbarkeit und Erweiterbarkeit mit Hilfe von zahlreichen Fallstudien aus der Forschung und der Industrie nach. Wir bieten hierzu ein Replication-Package an, das die Daten und den Quellcode all unserer Experimente beinhaltet. So ermöglichen wir die Veri- fizierbarkeit sowie die Wiederholbarkeit unserer Experimente und erlauben das Nachvollziehen der Ergebnisse. Zudem bieten wir Referenzimplemen- tierungen für TeeTime in Java sowie in C++ als Open-Source-Software unter https://teetime-framework.github.io an. iii Abstract Pipe-and-Filter (P&F) is a well-known and often used architectural style. However, to the best of our knowledge, there is no P&F framework which can model and execute generic P&F architectures. For example, the frame- works Fastflow, StreamIt, and Spark do not support multiple input and output streams per filter and thus cannot model branches. Other frameworks focus on very specific use cases and neglect type-safety when interconnect- ing filters. Furthermore, an efficient parallel execution of P&F architectures is still an open challenge. Although some available frameworks can execute filters in parallel, there is much potential for optimization. Unfortunately, most frameworks have a fixed execution strategy which cannot be altered without major changes. In this thesis, we present our generic and parallel P&F framework TeeTime. It is able to model and to execute arbitrary P&F architectures. Simultaneously, it is open for modifications in order to experiment with the P&F style. Moreover, it allows to execute filters in parallel by utilizing the capabilities of contemporary multi-core processor systems. Extensive lab experiments show that TeeTime imposes a very low and in certain cases even no runtime overhead compared to implementations with- out framework abstractions. Moreover, several case studies from research and industry show TeeTime’s broad applicability and extensibility. We pro- vide a replication package containing all our experimental data and code to facilitate the verifiability, repeatability, and further extensibility of our results. Furthermore, we provide reference implementations for TeeTime in Java and in C++ as open source software on https://teetime-framework.github.io. v Preface by Prof. Dr. Wilhelm Hasselbring Software Engineering of parallel and distributed software systems poses specific challenges for software engineers. The engineered parallel and distributed software systems have to be correct as well as efficient and scalable. Architectural styles and design patterns provide proven solutions to recurring tasks in software development, including the development of such parallel and distributed software systems. Since three decades, this design knowledge is systematically documented in appropriate catalogs for reuse. The so-called “pipe-and-filter” style is one of the first architectural styles, documented early in the nineties. Even if this style can be considered a “clas- sic” style, it remains a great challenge to implement pipe-and-filter systems efficient and scalable on parallel and distributed hardware platforms. In this thesis, Christian Wulf designs, implements and evaluates the new, innovative TeeTime approach to realize efficient pipe-and-filter systems in an efficient way. Besides the conceptual work, this work contains a significant experimental part with an implementation and a multifaceted evaluation. This engineering dissertation has been extensively evaluated with various experiments, including data from an industrial system. Notably, this thesis already now has significant impact. The new Kieker monitoring analysis component has been migrated to TeeTime, and TeeTime is used in various follow-up projects. If you are interested in designing and implementing pipe-and-filter software systems, this is a recommended reading for you. Wilhelm Hasselbring Kiel, August 2019 vii Contents 1 Introduction1 1.1 Motivation and Problem Statement................1 1.2 Approach Overview and Contributions.............3 1.3 Preliminary Work..........................6 1.4 Document Structure........................ 12 I Foundations 17 2 The Evolution of the Pipe-and-Filter Style 19 2.1 The Early Days of Pipes and Filters............... 19 2.2 Dataflow Variations......................... 20 2.3 Pipes as First-Class Entities.................... 20 2.4 The Myth of Pipe Overhead.................... 22 2.5 Sharing State among Filters.................... 23 2.6 Execution of Pipes and Filters................... 24 2.7 Parallel Execution of Pipes and Filters.............. 24 2.8 Scheduling of Filters........................ 26 2.9 Error Handling........................... 28 3 Shared Queues 29 3.1 Performance Affecting Aspects.................. 30 3.2 Lock-based Queues......................... 31 3.3 Lock-free Queues.......................... 32 3.4 Hybrid Queues........................... 33 3.5 Optimization Techniques...................... 33 4 Design Patterns for Parallel Systems 39 4.1 The Pipeline Pattern........................ 39 ix Contents 4.2 The Task Farm Parallelization Pattern.............. 41 5 The Actor Model 45 5.1 Components............................. 45 5.2 Properties.............................. 46 5.3 Example Implementations..................... 47 6 Domain-Specific Languages 49 II The Pipe-and-Filter Framework TeeTime 53 7 Research Design 55 7.1 Research Scope........................... 55 7.2 Research Plan............................ 56 7.3 Research Methods.......................... 58 8 Framework Architecture 59 8.1 Architectural Drivers........................ 59 8.2 Framework Entities......................... 63 9 Executing P&F Systems 75 9.1 Execution Models.......................... 75 9.2 Parallelization via the Task Farm Stage............. 88 9.3 Distributed Execution of Stages.................. 99 9.4 Feedback Loops in P&F Configurations............. 102 10 Developing P&F Systems 105 10.1 Definition of Stages......................... 105 10.2 Definition of P&F Configurations................. 110 10.3 Debugging and Profiling of P&F Configurations........ 115 III Evaluation of TeeTime 127 11 Language Independence Evaluation 129 11.1 Methodology............................ 129 x Contents 11.2 Statistical Overview......................... 130 11.3 State of Development........................ 130 11.4 Summary............................... 134 12 Feasibility Evaluation 135 12.1 Case Study: Trace Reconstruction................. 135 12.2 Case Study: Quicksort....................... 139 12.3 Industrial Case Study: Extraction of User Behavior Profiles. 142 12.4 Case Study: Live Visualization of Performance Anomalies.. 146 12.5 Case Study: Distributed Execution................ 149 13 Performance Evaluation 155 13.1 Framework Overhead Evaluation................. 155 13.2 Scheduling Approach Evaluation................. 166 13.3 Parallelization Approach Evaluation............... 170 14 Reusability and Extensibility Evaluation 179 14.1 Methodology............................ 179 14.2 Reusable and Extensible Entities................. 180 14.3 Public and Private Entities..................... 181 14.4 Case Studies............................. 183 15 Related Work 185 15.1 Related Parallel P&F Frameworks................ 185 15.2 Related Distributed P&F Frameworks.............. 189 15.3 Parallel Execution Strategies for Stages............. 190 15.4 Related Architectural Styles.................... 191 IV Conclusions and Future Work 195 16 Conclusions 197 16.1 Modeling Concepts......................... 197 16.2 Execution Concepts........................
Recommended publications
  • By Sebastiano Vigna and Todd M. Lewis Copyright C 1993-1998 Sebastiano Vigna Copyright C 1999-2021 Todd M

    By Sebastiano Vigna and Todd M. Lewis Copyright C 1993-1998 Sebastiano Vigna Copyright C 1999-2021 Todd M

    ne A nice editor Version 3.3.1 by Sebastiano Vigna and Todd M. Lewis Copyright c 1993-1998 Sebastiano Vigna Copyright c 1999-2021 Todd M. Lewis and Sebastiano Vigna Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Chapter 1: Introduction 1 1 Introduction ne is a full screen text editor for UN*X (or, more precisely, for POSIX: see Chapter 7 [Motivations and Design], page 65). I came to the decision to write such an editor after getting completely sick of vi, both from a feature and user interface point of view. I needed an editor that I could use through a telnet connection or a phone line and that wouldn’t fire off a full-blown LITHP1 operating system just to do some editing. A concise overview of the main features follows: • three user interfaces: control keystrokes, command line, and menus; keystrokes and menus are completely configurable; • syntax highlighting; • full support for UTF-8 files, including multiple-column characters; • 64-bit
  • Building Great Interfaces with OOABL

    Building Great Interfaces with OOABL

    Building great Interfaces with OOABL Mike Fechner Director Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 2 Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 3 Übersicht Consultingwerk Software Services Ltd. ▪ Independent IT consulting organization ▪ Focusing on OpenEdge and related technology ▪ Located in Cologne, Germany, subsidiaries in UK and Romania ▪ Customers in Europe, North America, Australia and South Africa ▪ Vendor of developer tools and consulting services ▪ Specialized in GUI for .NET, Angular, OO, Software Architecture, Application Integration ▪ Experts in OpenEdge Application Modernization © 2018 Consultingwerk Ltd. All rights reserved. 4 Übersicht Mike Fechner ▪ Director, Lead Modernization Architect and Product Manager of the SmartComponent Library and WinKit ▪ Specialized on object oriented design, software architecture, desktop user interfaces and web technologies ▪ 28 years of Progress experience (V5 … OE11) ▪ Active member of the OpenEdge community ▪ Frequent speaker at OpenEdge related conferences around the world © 2018 Consultingwerk Ltd. All rights reserved. 5 Übersicht Agenda ▪ Introduction ▪ Interface vs. Implementation ▪ Enums ▪ Value or Parameter Objects ▪ Fluent Interfaces ▪ Builders ▪ Strong Typed Dynamic Query Interfaces ▪ Factories ▪ Facades and Decorators © 2018 Consultingwerk Ltd. All rights reserved. 6 Übersicht Introduction ▪ Object oriented (ABL) programming is more than just a bunch of new syntax elements ▪ It’s easy to continue producing procedural spaghetti code in classes ▪
  • Pipe and Filter Architectural Style Group Number: 5 Group Members: Fan Zhao 20571694 Yu Gan 20563500 Yuxiao Yu 20594369

    Pipe and Filter Architectural Style Group Number: 5 Group Members: Fan Zhao 20571694 Yu Gan 20563500 Yuxiao Yu 20594369

    Pipe and Filter Architectural Style Group Number: 5 Group Members: Fan Zhao 20571694 Yu Gan 20563500 Yuxiao Yu 20594369 1. Have its own vocabulary for its components and connectors? (define) The Pipe and Filter is an architectural pattern for stream processing. It consists of one or more components called filters. These filters will transform or filter ​ ​ data and then pass it on via connectors called pipes. These filters, which merely ​ ​ consume and produce data, can be seen as functions like sorting and counting. All of these filters can work at the same time. Also, every pipe connected to a filter has its own role in the function of the filter. When data is sent from the producer (pump), it ​ ​ goes through the pipes and filters, and arrives the destination (sink). The pump can ​ ​ be a static text file or a keyboard input. The sink can be a file, a database or a computer screen. 2. Impose specific topological constraints? (diagram) Figure 1 shows a basic structure of Pipe and Filter architecture style. In this example, there are five filters and eight pipes. Each filter will get input from one or more pipes and pass it via pipes. The combination of several filters and pipes can be regarded as a “big” filter. Figure 2 is an specific example using Pipe and Filter architecture style. This example demonstrates a simple process of making sandwiches. To begin with, the first 4 filters can work simultaneously for preparation. Once they are done, the 5th filter can get the output and combine them together. Next, a following filter will add sauce to it and pass it to customer through a pipe.
  • Bibliography of Erik Wilde

    Bibliography of Erik Wilde

    dretbiblio dretbiblio Erik Wilde's Bibliography References [1] AFIPS Fall Joint Computer Conference, San Francisco, California, December 1968. [2] Seventeenth IEEE Conference on Computer Communication Networks, Washington, D.C., 1978. [3] ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, Los Angeles, Cal- ifornia, March 1982. ACM Press. [4] First Conference on Computer-Supported Cooperative Work, 1986. [5] 1987 ACM Conference on Hypertext, Chapel Hill, North Carolina, November 1987. ACM Press. [6] 18th IEEE International Symposium on Fault-Tolerant Computing, Tokyo, Japan, 1988. IEEE Computer Society Press. [7] Conference on Computer-Supported Cooperative Work, Portland, Oregon, 1988. ACM Press. [8] Conference on Office Information Systems, Palo Alto, California, March 1988. [9] 1989 ACM Conference on Hypertext, Pittsburgh, Pennsylvania, November 1989. ACM Press. [10] UNIX | The Legend Evolves. Summer 1990 UKUUG Conference, Buntingford, UK, 1990. UKUUG. [11] Fourth ACM Symposium on User Interface Software and Technology, Hilton Head, South Carolina, November 1991. [12] GLOBECOM'91 Conference, Phoenix, Arizona, 1991. IEEE Computer Society Press. [13] IEEE INFOCOM '91 Conference on Computer Communications, Bal Harbour, Florida, 1991. IEEE Computer Society Press. [14] IEEE International Conference on Communications, Denver, Colorado, June 1991. [15] International Workshop on CSCW, Berlin, Germany, April 1991. [16] Third ACM Conference on Hypertext, San Antonio, Texas, December 1991. ACM Press. [17] 11th Symposium on Reliable Distributed Systems, Houston, Texas, 1992. IEEE Computer Society Press. [18] 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992. [19] Fourth ACM Conference on Hypertext, Milano, Italy, November 1992. ACM Press. [20] GLOBECOM'92 Conference, Orlando, Florida, December 1992. IEEE Computer Society Press. http://github.com/dret/biblio (August 29, 2018) 1 dretbiblio [21] IEEE INFOCOM '92 Conference on Computer Communications, Florence, Italy, 1992.
  • Digital Filter Graphical User Interface

    Digital Filter Graphical User Interface

    University of Southern Maine USM Digital Commons Thinking Matters Symposium Archive Student Scholarship Spring 2018 Digital Filter Graphical User Interface Tony Finn University of Southern Maine Follow this and additional works at: https://digitalcommons.usm.maine.edu/thinking_matters Recommended Citation Finn, Tony, "Digital Filter Graphical User Interface" (2018). Thinking Matters Symposium Archive. 135. https://digitalcommons.usm.maine.edu/thinking_matters/135 This Poster Session is brought to you for free and open access by the Student Scholarship at USM Digital Commons. It has been accepted for inclusion in Thinking Matters Symposium Archive by an authorized administrator of USM Digital Commons. For more information, please contact [email protected]. By Tony Finn Digital Filter Graphical User Interface EGN 402 Fall 2017 Problem Statements - Digital FIR (finite impulse response) filter design Results requires tedious computations, with each requiring Illustrated in Figure 3 is the final design of the user interface, truncation of an impulse response (seen in Figure 1.) one will find buttons to change design type and filter type as - In order to obtain the desired effects from a filter, one well as clickable buttons to give the user feedback or an output. may need to try multiple filters, so many computations - Play Original Audio: emits the input audio as is; unfiltered. would be necessary. - Play Filtered Audio: emits the input audio with the designed Therefore the desire to simplify the digital filter design filter applied. process is necessary to provide users an easier, more intuitive method for design. - Return Filtered Audio: returns the filtered audio. - Print Filter: returns the filter specifications.
  • Functional Javascript

    Functional Javascript

    www.it-ebooks.info www.it-ebooks.info Functional JavaScript Michael Fogus www.it-ebooks.info Functional JavaScript by Michael Fogus Copyright © 2013 Michael Fogus. 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 Treseler Indexer: Judith McConville Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Jasmine Kwityn Interior Designer: David Futato Proofreader: Jilly Gagnon Illustrator: Robert Romano May 2013: First Edition Revision History for the First Edition: 2013-05-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449360726 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Functional JavaScript, the image of an eider duck, 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 trade‐ mark 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 author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
  • Automating Testing with Autofixture, Xunit.Net & Specflow

    Automating Testing with Autofixture, Xunit.Net & Specflow

    Design Patterns Michael Heitland Oct 2015 Creational Patterns • Abstract Factory • Builder • Factory Method • Object Pool* • Prototype • Simple Factory* • Singleton (* this pattern got added later by others) Structural Patterns ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy Behavioural Patterns 1 ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento Behavioural Patterns 2 ● Null Object * ● Observer ● State ● Strategy ● Template Method ● Visitor Initial Acronym Concept Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the S SRP software's specification should be able to affect the specification of the class) Open/closed principle: “Software entities … should be open O OCP for extension, but closed for modification.” Liskov substitution principle: “Objects in a program should be L LSP replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle: “Many client-specific I ISP interfaces are better than one general-purpose interface.”[8] Dependency inversion principle: One should “Depend upon D DIP Abstractions. Do not depend upon concretions.”[8] Creational Patterns Simple Factory* Encapsulating object creation. Clients will use object interfaces. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Inject the factory into the object. Dependency Inversion Principle Depend upon abstractions. Do not depend upon concrete classes. Our high-level components should not depend on our low-level components; rather, they should both depend on abstractions. Builder Separate the construction of a complex object from its implementation so that the two can vary independently. The same construction process can create different representations.
  • MATLAB Creating Graphical User Interfaces  COPYRIGHT 2000 - 2004 by the Mathworks, Inc

    MATLAB Creating Graphical User Interfaces  COPYRIGHT 2000 - 2004 by the Mathworks, Inc

    MATLAB® The Language of Technical Computing Creating Graphical User Interfaces Version 7 How to Contact The MathWorks: www.mathworks.com Web comp.soft-sys.matlab Newsgroup [email protected] Technical support [email protected] Product enhancement suggestions [email protected] Bug reports [email protected] Documentation error reports [email protected] Order status, license renewals, passcodes [email protected] Sales, pricing, and general information 508-647-7000 Phone 508-647-7001 Fax The MathWorks, Inc. Mail 3 Apple Hill Drive Natick, MA 01760-2098 For contact information about worldwide offices, see the MathWorks Web site. MATLAB Creating Graphical User Interfaces COPYRIGHT 2000 - 2004 by The MathWorks, Inc. The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or repro- duced in any form without prior written consent from The MathWorks, Inc. FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or other entity acquiring for or through the federal government) and shall supersede any conflicting contractual terms or conditions.
  • XML Pipeline Performance

    XML Pipeline Performance

    XML Pipeline Performance Nigel Whitaker DeltaXML Ltd <[email protected]> Tristan Mitchell DeltaXML Ltd <[email protected]> Abstract This paper considers XML pipeline performance of a case study constructed from real code and data. It extends our original small study into 'Filter Pipeline Performance' on the saxon-help email list. The system used in this case study is a comparison tool for OASIS OpenDocument Text or '.odt' files. We will not describe the code in detail, but rather concentrate on the mechanisms used to interlink the various pipeline components used. These components include XML parsers, XSLT filter stages, XML comparison, Java filters based on the SAX XMLFilter interface and serialization. In the previous study we compared two pipelining techniques; this paper will extend this to consider three mechanisms which can be used to construct pipelines; these are: • The Java API for XML Processing (JAXP) included in Java Standard Edition 1.4 and subsequent releases • The s9api package provided by the Saxon XSLT processor 9.0 and sub- sequent releases • The Calabash implementation of the XProc XML pipeline language Our primary focus is performance and we will look at run times and memory sizes using these technologies. The overall runtime of the complete system will be described, but we will then concentrate on the performance of running a chain of filters (XSLT and Java based) as this is likely to be of moregeneral interest. We will also discuss some optimization techniques we have implemen- ted during the development process and further ideas for future performance improvement work. 1. Introduction In this section we will introduce the system being studied, briefly describe the data and also some aspects of the experimental approach.
  • Designpatternsphp Documentation Release 1.0

    Designpatternsphp Documentation Release 1.0

    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
  • Access Control Models for XML

    Access Control Models for XML

    Access Control Models for XML Abdessamad Imine Lorraine University & INRIA-LORIA Grand-Est Nancy, France [email protected] Outline • Overview on XML • Why XML Security? • Querying Views-based XML Data • Updating Views-based XML Data 2 Outline • Overview on XML • Why XML Security? • Querying Views-based XML Data • Updating Views-based XML Data 3 What is XML? • eXtensible Markup Language [W3C 1998] <files> "<record>! ""<name>Robert</name>! ""<diagnosis>Pneumonia</diagnosis>! "</record>! "<record>! ""<name>Franck</name>! ""<diagnosis>Ulcer</diagnosis>! "</record>! </files>" 4 What is XML? • eXtensible Markup Language [W3C 1998] <files>! <record>! /files" <name>Robert</name>! <diagnosis>! /record" /record" Pneumonia! </diagnosis> ! </record>! /name" /diagnosis" <record …>! …! </record>! Robert" Pneumonia" </files>! 5 XML for Documents • SGML • HTML - hypertext markup language • TEI - Text markup, language technology • DocBook - documents -> html, pdf, ... • SMIL - Multimedia • SVG - Vector graphics • MathML - Mathematical formulas 6 XML for Semi-Structered Data • MusicXML • NewsML • iTunes • DBLP http://dblp.uni-trier.de • CIA World Factbook • IMDB http://www.imdb.com/ • XBEL - bookmark files (in your browser) • KML - geographical annotation (Google Maps) • XACML - XML Access Control Markup Language 7 XML as Description Language • Java servlet config (web.xml) • Apache Tomcat, Google App Engine, ... • Web Services - WSDL, SOAP, XML-RPC • XUL - XML User Interface Language (Mozilla/Firefox) • BPEL - Business process execution language
  • Reference Manual

    Reference Manual

    Reference Manual Command Line Interface (CLI) HiLCOS Rel. 9.12 RM CLI HiLCOS Technical Support Release 9.12 05/16 https://hirschmann-support.belden.eu.com The naming of copyrighted trademarks in this manual, even when not specially indicated, should not be taken to mean that these names may be considered as free in the sense of the trademark and tradename protection law and hence that they may be freely used by anyone. © 2016 Hirschmann Automation and Control GmbH Manuals and software are protected by copyright. All rights reserved. The copying, reproduction, translation, conversion into any electronic medium or machine scannable form is not permitted, either in whole or in part. An exception is the preparation of a backup copy of the software for your own use. The performance features described here are binding only if they have been expressly agreed when the contract was made. This document was produced by Hirschmann Automation and Control GmbH according to the best of the company's knowledge. Hirschmann reserves the right to change the contents of this document without prior notice. Hirschmann can give no guarantee in respect of the correctness or accuracy of the information in this document. Hirschmann can accept no responsibility for damages, resulting from the use of the network components or the associated operating software. In addition, we refer to the conditions of use specified in the license contract. You can get the latest version of this manual on the Internet at the Hirschmann product site (www.hirschmann.com.) Hirschmann Automation and Control GmbH Stuttgarter Str. 45-51 Germany 72654 Neckartenzlingen Tel.: +49 1805 141538 Rel.