DOCSLIB.ORG

623 a Abfangen Temporärer Fehler, 479 Abgesicherter

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
623 a Abfangen Temporärer Fehler, 479 Abgesicherter Index A allow_url_fopen, 510 allow_url_include, 510 Abfangen temporärer Fehler, 479 Amazon.com, 409 abgesicherter monolithischer Kernel, 135 Ambient Authority, 99, 107, 158, 416, 446 ablaufbasierte Kontrolle, 104 Ambige Interfaces, 476 Abschalten von Javascript, 503 Analysis/Paralysis Pattern, 553 Absichern von Application-Servern, 347 Anfangs- bzw. Endspanne, 571 Absicherung der Ressourcen, 350 Angriffe Absicherung der Verbindungen, 349 Klassifikation, 12 Absicherung von Servern, 169 Angriffsformen Abwehr auf der Netzwerkschicht, 39 lokale, 15 Access Control Context, 95, 203, 214 Anreicherung von Privilegien, 152 Access Control Lists, 108, 118 Antipattern, 99, 473 Access Control Markup Language, 197 API in Form paarweiser Methoden, 509 Access Control Matrix, 564 Append-Only-Recht, 152 Access Control Policies, 195 Application Integration in Acegi, 295 SSO-Infrastruktur, 285 ACL, 108, 118, 291 Application Level Security, 262 Beispiel, 119 Application Server Malware, 119 LTPA, 335 Solitaire, 119 Application Server Security, 313 Active Object, 470 Application Tower, 230 Add-Ons, 445 Application-Server, 330 Administration, 174 Architektur, 318 Administrationsfunktion, 288 Authorisierungscode in der „after the fact“-Sicherheitsmechanismen, Applikation, 329 417 Beispielarchitektur, 320 AJAX, 69 Classloader, 325 Java Script Object Notation, 75 Concurrency, 316 On-Demand JavaScript, 74 Credentials für den Zugriff auf Techniken, 72 Backends, 329 XMLHttpRequest, 72 CSIv2, 318 aktionsintegrierte Sicherheit, 554 Delegation mit Neuerzeugung Alias-Antipattern, 25 des Subjects, 346 Alias-Definition, 475 Entry–Context-Diagramm, 325 „Alles oder Nichts“-Prinzip, 116 Formen der Authentisierung, 324 623 624 Index Identity Assertion, 334 auf Web2.0, 70 Identity Token, 334 Buffer Overflow, 30 initiale Authentisierung, 332 Cross-Site-Request-Forgery (XSRF), JAAS-Framework, 315 20 keine eigenen Threads erzeugen, 316 Cross-Site-Scripting (XSS), 18 Komponentenarchitektur, 316 durch Race Condition, 472 Multithreading, 316 externe, 18 Neuerstellung eines Subjects, 337 Genuine AJAX/Web2.0-Attacken, 79 POLA, 354 Lokale auf Applikationslevel, 30 Probleme mit ClassNotFound- neue Angriffsformen, 17 Exceptions, 327 Shatter Attack, 35 Reverse Proxy, 343 soziale, 67 Security-Context-Diagramm, 321 Surf Jacking, 23 Security-Interfaces, 328 Übersicht, 12 Separation of Concerns, 313 UNIX Shellscript und Utility-Attacken, Separation of Context, 313 36 Sicherheits-Framework, 330 Visual Spoofing, 25 Single-Sign-On, 319 War-Googling, 29 Subject Propagation, 345 XML-basiert, 24 Thread und Requestcontext, 316 Zeichencode, 25 Verwaltung von Credentials, 322 zeitliche Entwicklung, 15 Zertifikate, 339 Attacken im Navigator, 508 Application-Server-Cluster, 319 Aufgabe des Supervisors, 448 Application-Server-Verbund Aufmerksamkeit, 552 Subject-Erzeugung, 342 Ausführungsidentität, 257 Applikationsarchitektur Auslieferungszustand, 348 Aufruf von Sicherheitsprüfungen Aussagen, 403 vergessen, 233 Authentisierung in Web-Applikationen, Aufteilung in System und 278 Businesslogik, 276 Authentisierungscode in der Applikation, Businesslogik, 275 329 Eliminieren von Trusted Code, 479 Authentisierungs-Framework, 315 Eliminieren von Code, 479 Authentisierungsidentität, 257 Eliminieren von Fehlern, 478 Authentisierungsmethoden Multi-Tier, 233 Hierarchie, 16 sicherheitskritische Aspekte, 231 Authentisierungsobjekt, 289 Templates, 274 Authentisierungs-Token, 236 Wartbarkeit der Sicherheit, 233 Authorisierung, 186, 208 Arbeiten im Auftrag, 261 Authority, 433 Architektur Authority Reduction in Vista, 154 des OKWS-Web-Servers, 170 Authorization-Provider, 341 einer paravirtualisierten Lösung, 141 Automatic Processes, 553 eines Application-Servers, 318 automatisches Update, 535 Architekturschwäche, 509 automatisierte Testtools, 60 Argumentation für POLA, 106 Automobilbau, 91 ASLR, 33 Automobilindustrie, 120 Aspekte, 481 Automotive-Bereich Assertion, 404 OSGI, 365 Attacken, 70 Autorisierung, 290 Alias-Problem, 25 Autorisierungsidentität, 257 Angriff auf Password-File, 37 Autorität, 106 Application-DOS, 27 Autorität aus Designation, 556 auf Ebene der Semantik, 61 Autorität und Interaktion, 579 auf REST Architekturen, 21 Autoritäten, 403 Index 625 Autoritäten der Zugriffskontrolle, 197 Bundle, 366 Autoritätstrichter, 449, 455 Business Rule Engine, 196 Businesslogik, 274 B Bypass, 420 Bytecode Verifier, 188 Backend Security Defense in depth, 270 C unterschiedliche Views auf die Datensätze, 271 Caching, 412 Bedeutung der Identität des Ausführenden, Caja-Projekt, 530 207 Caller-Identity, 217 Bedrohungsmodelle für den Renderer, 529 Callgraph, 445 Behavior Rules, 590 Canaries, 32, 33 Behavior Sensitive, 456 Capabilities, 107, 111, 138, 426, 581 Beispiel für eine Closure, 443 Formen, 427 Beispiel OKWS-Web-Server, 169 Objekt Capabilities, 111 Beispielarchitektur eines Capability Applikationsservers, 320 Filedeskriptor, 152 Benutzbarkeit von Techniken und widerrufbar, 451 Mechanismen, 533 Capability Architecture, 526 Bequemlichkeit vs. Sicherheit, 545 Capability Safe, 530 Bestimmung der Gefährlichkeit, 433 Capability-basierte Architektur, Betriebssysteme 519, 524 Capabilities, 152 Capability-System, 437 Confused Deputy, 129 Cap-Browser, 523 durch VMs gesicherter Kernel, 136 Cap-Desk, 523 Isolation durch Trennung der Captcha, 71 Adressräume, 129 Card Reader Kernel-Datenstrukturen, 135 vorinstallierte Schlüssel, 377 Komponenten beim Microkernel, 132 Caretaker, 449 Mittel der Isolation, 129 Modellierung, 576 monolithischer Kernel, 131 Caretaker Sicherheitsbaustein, 576 Sicherheitsarchitektur, 127 CAS, 225 Treiberschema unter C, 136 Casts, 189 Beweisbare Plattformsicherheit, 610 Cell, 352 Bibliotheken Chain-of-Responsibility“-Pattern, 375 Classloader-Positionierung, 355 ChokePoint, 279 BinarySecurityToken, 397 Chroot, 152 bind(UserId, Passwort)-Aufruf, 282 Claim, 404 Blacklist, 420 Classloader, 199, 217 Blind Spot Bias, 550 Beispielcode, 367 Blindheit, 552 Default-Lookup-Policy, 326 breiter Zugang auf Daten, 270 Classloader-Hierarchie für Application- Browser, 504 Server, 327 Same Origin“-Prinzip, 78 Classloader-Vorgang, 188 Sicherheitsmodelle Internet Explorer, ClassNotFound-Exceptions, 327 Mozilla/Firefox, 78 CLDC, 380 Browser Memory Protetions, 32 C-Lists, 145 Browser Sicherheit Closures, 207, 440, 442 bösartiger Renderer, 521 Code Access Control in Application- Browserarchitektur, 504 Servern, 354 Buffer Overflows, 30 Code Access Security, 224 Beispielcode zur Erzeugung, 31 Code Security für Enterprise- Bug oder Architekturschwäche, 510 Applikationen, 223 626 Index Codeanalyse, 433 CSIv2, 255 codebasierte Policies, 203 Delegation, 339 Codepoint, 27 Token, 286 Abbildung auf Fonts, 26 Currying, 452 Abbildung auf Glyphs, 27 cognitive Biases, 550 D „Comet“-Anwendungen, 77 Community Sites, 78 Data Execution Protection, 33 Sicherheitsprobleme, 78 Datenbank-Views, 174 Complete Mediation, 291, 388, 428 Datenbankzugriff durch den Server, 359 Concurrency, 462 DBAccessPrincipal, 358 Concurrency und alternative Verfahren, DB-Proxies, 172 472 Deadlock, 465 Concurrent Constraint Programming, Deadlock-Problem, 465 578 Decentralized Mandatory Access Control, Conditioning, 552 153 Confinement, 447, 495, 570 Decorator, 451 Confirmation Bias, 550 Decorator Pattern, 221 Confused Deputy, 226, 421, 524 Deep Linking, 279 Confused-Deputy-Problem, 421, 580 De-Fakto, 571 Connected Limited Device Configuration „default-is-allow“ Logik, 494 (CLDC), 380 Default-is-deny, 94, 348 Connection Pool, 231 Default-Policy-Implementation, 198 Austauschen des Principals, 359 defensive consistency, 464 Identitätspropagation, 358 defensive correctness, 439 Constraints, 606 Degeneration von Architektur, 475 Container De-Jure, 570 Ausführungskontexte selber erstellen, deklarative Rollendefinition, 263 330 deklarative Security, 248 Container Managed Authentication, 288 deklarative Sicherheit Container Managed Security, 280 Designfragen, 268 Container-Architektur, 314, 317 deklaratives Modell der Zugriffskontrolle, Container-Managed-Authentisierung, 285 266 content-basierte Filterungen, 239 Delegation Continuation Passing, 472 durch Weitergabe von Credentials, 249 Control Sensitive, 456 implizites Vertrauen, 304 Convenience Interface, 447 Delegation mit Propagation des Subjects, Coordination Language, 466 346 Copy-Programm, 107 DEP, 33 CORBA-Infrastruktur, 232 Dependency-Injection-Prinzip, 138 crashme, 60, 145 Deputy Pattern, 593 Credential, 248, 551 Design der Benutzerschnittstelle, 555 Absicherung, 349 Design sicherer Systeme SSO-Schlüssel, 353 Grundprinzipien, 91 Verwaltung, 322 Regeln, 104 Credential-Diagramm, 323 Designation, 557 Cross Domain Proxy, 74 Designation und Autorität, 455 Cross Site Access Control, 23 Deskriptorsysteme, 145 Cross-Cell-Trust, 353 Diagramm, 449 Cross-Cutting Concern, 233 Die Kunst der Täuschung, 61 Cross-Site-Request-Forgery, 21 Diebold, 388 Cross-Site-Scripting Differenzierung des Take/Grant – Attacken, 18 Ansatzes, 574 Merkmale, 21 Digital Rights Management (DRM), 544 Index 627 direkte Authentisierung, 431 Propagation des Zugriffs durch Dirty Assignments, 440, 496 authentisierte User, 244 Discretionary vs. Mandatory, 544 Propagation von Identität, Recht und Diskreditierung von Capability-basierten Aufruf, 245 Systemen, 573 Requestvalidierung, 261 Diskussion der Spring Security Security, Sicherheitsprobleme Beispiel Search, 302 243 Dispatch-Funktion, 443 Endowment, 447 DLL-Hell, 327 End-to-End-Argument, 191 Domain, 258 End-to-End-Security, 229 Dominanz der heute gängigen Systeme, Enterprise Security, 229 418 Access
Load more

Recommended publications
  • 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]
  • Diplomarbeit Im Fachbereich Elektrotechnik & Informatik an Der
    Bachelor Thesis Prannoy Mulmi Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informations- und Department of Information and Elektrotechnik Electrical Engineering Prannoy Mulmi Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Bachelor Thesis based on the study regulations for the Bachelor of Engineering degree programme Information Engineering at the Department of Information and Electrical Engineering of the Faculty of Engineering and Computer Science of the Hamburg University of Applied Sciences Supervising examiner : Prof. Dr. rer. nat. Henning Dierks Second Examiner : Prof. Dr. rer. nat. Thomas Clemen Day of delivery 23. Juli 2018 Prannoy Mulmi Title of the Bachelor Thesis Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Keywords Distributed System, Microservice, Two-Phase commit protocol, Archive, Decentrali- zed data, Multi-Agent Research and Simulation (MARS) Abstract This thesis introduces the design and implementation of an Archive Microservice in the Multi-Agent Research and Simulation (MARS) framework. Due to the distributed architecture of the system, the process of the archive and restore is complex to imple- ment and maintain as there multiple possibilities of failure. This thesis uses different strategies to
    [Show full text]
  • Methods & Tools
    METHODS & TOOLS Practical knowledge for the software developer, tester and project manager ISSN 1661-402X Spring 2011 (Volume 19 - number 1) www.methodsandtools.com The Salesmen/Developers Ratio at Software Vendors Many of us might think that software is a technological industry. Maybe. But maybe not. If you consider Oracle or Microsoft, I suppose that few of us would consider them as technology leaders, but we will all recognize their financial strength and marketing power. Long lasting organizations in the software industry might have more financial strength than technological capabilities. The recent conflict between Oracle and the creator of Hudson, an open source continuous integration server, is just another episode in the opposition between developers- and salesmen-driven software companies. On one side you have Oracle, for which Hudson is just small project inherited from the Sun buyout and that owns the "Hudson" brand. On the other side, you find Kohsuke Kawaguchi, who created Hudson and wants keep some control on its development. Hudson has been "forked", the open source code being used to start another project. You now have a Jenkins CI project that includes most of the active Hudson contributors and a Hudson CI project backed by Oracle and Sonatype, the commercial company behind the Maven project. Everything is however not black and white. Kohsuke Kawaguchi has joined Cloudbees, a company that has some management and financing coming from ex-JBoss managers, people that know how to make money with open source software. These people are not working hard for the only sake of technology evolution. You can judge the main orientation of a company looking at its salesmen/developers ratios.
    [Show full text]
  • Mutable Class Design Pattern Nikolay Malitsky Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2016 Mutable Class Design Pattern Nikolay Malitsky Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Other Computer Sciences Commons, and the Theory and Algorithms Commons Share Feedback About This Item NSUWorks Citation Nikolay Malitsky. 2016. Mutable Class Design Pattern. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (956) https://nsuworks.nova.edu/gscis_etd/956. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Mutable Class Design Pattern by Nikolay Malitsky A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science Graduate School of Computer and Information Sciences Nova Southeastern University 2016 We hereby certify that this dissertation, submitted by Nikolay Malitsky, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Michael J. Laszlo, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Francisco J. Mitropoulos, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Amon B.
    [Show full text]
  • Security Pattern Validation and Recognition
    Security-Pattern Recognition and Validation Dissertation Submitted by Michaela Bunke on 12th December 2018 to the Universit¨atBremen Faculty of Mathematics and Computer Science in partial fulfillment of the requirements for the degree of Doktor der Ingenieurwissenschaften { Dr.-Ing. { Reviewed by Prof. Dr. Hans-J¨orgKreowski Universit¨atBremen, Germany and Dr. Karsten Sohr Universit¨atBremen, Germany In Memorial of Ilse Schlamilch Karl Schlamilch Manfred Friedrichs 21 November 1924 03 March 1927 29 August 1935 09 June 2017 19 June 2018 3 July 2017 ABSTRACT The increasing and diverse number of technologies that are connected to the Internet, such as distributed enterprise systems or small electronic devices like smartphones, brings the topic IT security to the foreground. We interact daily with these technologies and spend much trust on a well-established software development process. However, security vulnerabilities appear in software on all kinds of PC(- like) platforms, and more and more vulnerabilities are published, which compromise systems and their users. Thus, software has also to be modified due to changing requirements, bugs, and security flaws and software engineers must more and more face security issues during the software design; especially maintenance programmers must deal with such use cases after a software has been released. In the domain of software development, design patterns have been proposed as the best-known solutions for recurring problems in software design. Analogously, security patterns are best practices aiming at ensuring security. This thesis develops a deeper understanding of the nature of security patterns. It focuses on their validation and detection regarding the support of reviews and maintenance activities.
    [Show full text]
  • A CASE STUDY by Siegfried Steiner ([email protected])
    BIG DATA PROCESSING THE LEAN WAY – A CASE STUDY by Siegfried Steiner ([email protected]) 19/08/14 – 17/01/21 2 Content 1.Preface.............................................................................................................3 2.Abstract...........................................................................................................3 3.The mission.....................................................................................................4 4.Terminology.....................................................................................................5 5.Constraints......................................................................................................6 6.Approach.........................................................................................................7 7.Technology stack.............................................................................................8 8.Development process....................................................................................10 Excursus: Scrum.....................................................................................10 Excursus: Test-driven development........................................................11 9.Into the cloud: Scalability..............................................................................12 Excursus: IPO Model...............................................................................13 1.Input - Receive requests (and process output)..........................................14 Excursus: Front
    [Show full text]
  • Architectural Styles and Patterns
    Architectural Styles and Patterns Wednesday 13 February 13 Architectural Patterns & Styles Consensus Controversy • Established • Philosophy (context- Solutions problem-solution vs components- Common • connections) vocabulary Granularity (vs Document • • Design patterns) Reason over quality • • Categorization Wednesday 13 February 13 Architectural Patterns (Wikipedia) • Presentation- abstraction- • Peer-to-peer control • Service-oriented • Three-tier architecture • Pipeline • Naked Objects Implicit Invocation • Model-View • Controller • Blackboard Wednesday 13 February 13 Architectural Patterns (Shaw & Garland) • Dataflow Systems -- Batch, Pipes and Filters • Call-and-return systems -- Main program and subroutines, OO systems, Hierarchical Layers • Independent components -- Communicating processes, Event systems • Virtual Machines -- Interpreters, Rule-based systems • Data-Centered Systems -- Databases, Hypertext systems Blackboards Wednesday 13 February 13 Elements of Architecture (Shaw & Garland) Components Connectors • Clients • Procedure calls • Servers • Events broadcast • Filters • Database protocols • Layers • Pipes • Databases - What are the structural patterns permitted? - What is the underlying computational model? - What are the invariants of the style? BUT ... - What are examples of its use? - What are the tradeoffs? - ... Wednesday 13 February 13 Architectural Patterns (Baas, Clements & Kazman) • Dataflow Systems -- Batch, Pipes and Filters • Data-Centered -- Repository, Blackboard • Virtual machine -- Interpreter, Rule-based
    [Show full text]
  • Microservices Antipatterns and Pitfalls
    Microservices AntiPatterns and Pitfalls Mark Richards Beijing Boston Farnham Sebastopol Tokyo Microservices Antipatterns and Pitfalls by Mark Richards Copyright © 2016 O’Reilly Media, Inc. 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://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Brian Foster Interior Designer: David Futato Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Christina Edwards Illustrator: Rebecca Demarest Proofreader: Amanda Kersey July 2016: First Edition Revision History for the First Edition 2016-07-06: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Microservices AntiPatterns and Pitfalls, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limi‐ tation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsi‐ bility to ensure that your use thereof complies with such licenses and/or rights.
    [Show full text]
  • Conceptual Architecture Patterns
    HASSO - PLATTNER - INSTITUT für Softwaresystemtechnik an der Universität Potsdam Conceptual Architecture Patterns Technische Berichte des Hasso-Plattner-Instituts für Softwaresystemtechnik an der Universität Potsdam Technische Berichte des Hasso-Plattner-Instituts für Softwaresystemtechnik an der Universität Potsdam 2 Conceptual Architecture Patterns: FMC-based Representations Bernhard Gröne and Frank Keller (eds.) April 2004 Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Die Reihe Technische Berichte des Hasso-Plattner-Instituts für Softwaresystemtechnik an der Universität Potsdam erscheint aperiodisch. Herausgeber: Professoren des Hasso-Plattner-Instituts für Softwaresystemtechnik an der Universität Potsdam Redaktion Bernhard Gröne und Frank Keller EMail {bernhard.groene, frank.keller}@hpi.uni-potsdam.de Vertrieb: Universitätsverlag Potsdam Postfach 60 15 53 14415 Potsdam Fon +49 (0) 331 977 4517 Fax +49 (0) 331 977 4625 e-mail: [email protected] http://info.ub.uni-potsdam.de/verlag.htm Druck allprintmedia gmbH Blomberger Weg 6a 13437 Berlin email: [email protected] © Hasso-Plattner-Institut für Softwaresystemtechnik an der Universität Potsdam, 2004 Dieses Manuskript ist urheberrechtlich geschützt. Es darf ohne vorherige Genehmigung der Herausgeber nicht vervielfältigt werden. Heft 2 (2004) ISBN 3-935024-98-3 ISSN 1613-5652 Conceptual Architecture Patterns: FMC–based Representations Bernhard Gröne and Frank Keller (editors) Research assistants of the chair “Modeling of Software–intensive Systems” Hasso–Plattner–Institute for Software Systems Engineering P.O. Box 900460, 14440 Potsdam, Germany E-mail: {bernhard.groene, frank.keller}@hpi.uni-potsdam.de Abstract This document presents the results of the seminar “Conceptual Architecture Patterns” of the winter term 2002 in the Hasso–Plattner–Institute.
    [Show full text]
  • Middleware Architecture with Patterns and Frameworks
    Middleware Architecture with Patterns and Frameworks Sacha Krakowiak Distributed under a Creative Commons license http://creativecommons.org/licenses/by-nc-nd/3.0/ February 27, 2009 Contents Preface ix References........................................ x 1 An Introduction to Middleware 1-1 1.1 Motivation for Middleware . 1-1 1.2 CategoriesofMiddleware . 1-6 1.3 A Simple Instance of Middleware: Remote Procedure Call . ......... 1-7 1.3.1 Motivations and Requirements . 1-8 1.3.2 Implementation Principles . 1-9 1.3.3 Developing Applications with RPC . 1-11 1.3.4 SummaryandConclusions. .1-13 1.4 Issues and Challenges in Middleware Design . 1-14 1.4.1 DesignIssues ...............................1-14 1.4.2 Architectural Guidelines . 1-15 1.4.3 Challenges ................................1-17 1.5 HistoricalNote .................................. 1-18 References........................................1-19 2 Middleware Principles and Basic Patterns 2-1 2.1 ServicesandInterfaces . 2-1 2.1.1 Basic Interaction Mechanisms . 2-2 2.1.2 Interfaces ................................. 2-3 2.1.3 Contracts and Interface Conformance . 2-5 2.2 ArchitecturalPatterns . 2-9 2.2.1 Multilevel Architectures . 2-9 2.2.2 DistributedObjects . .. .. .. .. .. .. .. .2-12 2.3 Patterns for Distributed Object Middleware . 2-15 2.3.1 Proxy ...................................2-15 2.3.2 Factory ..................................2-16 2.3.3 Adapter..................................2-18 2.3.4 Interceptor ................................2-19 2.3.5 Comparing and Combining Patterns . 2-20 2.4 Achieving Adaptability and Separation of Concerns . ..........2-21 2.4.1 Meta-ObjectProtocols. 2-21 2.4.2 Aspect-Oriented Programming . 2-23 ii CONTENTS 2.4.3 PragmaticApproaches. .2-25 2.4.4 ComparingApproaches .
    [Show full text]
  • Adaptivity of Business Process
    ICONS 2013 : The Eighth International Conference on Systems Adaptivity of Business Process Charif Mahmoudi Fabrice Mourlin Laboratory of Algorithms, Complexity and Logics, Laboratory of Algorithms, Complexity and Logics, Paris 12th University Paris 12th University Créteil, France Creteil, France [email protected] [email protected] Abstract— Enterprise service bus is a software architecture local services is less costly in a number of messages than a middleware used for implementing the interaction between business process using remote services. Blockings are also software applications in a Service Oriented Architecture. We less numerous, and, therefore, the execution of a business have developed a strategy to dynamically manage business process is more efficient. processes. Administrators of service bus need to reconfigure This remark highlights the dependencies between two sites where the business processes are placed. This evolution concepts, the location of business processes and its own has to be done during execution of service through the bus. We definition. The designer should not consider his work in the ensure the availability of process definition. Moreover, placement constraints. In addition, the administrator cannot business process can also be autonomous. This means a process take into account all the dependencies of a process definition which is able to move from one site to another one, where the to find a better placement. Also, our second point is: how business process engine is installed. This provides another approach to design business process. With our "mobile process separate the two. These conclusions led us to consider an migration" template, we separate two concerns, on one side initial configuration of business processes is not satisfactory.
    [Show full text]
  • Spring and Spring Boot
    Spring and Spring Boot CAS Java Microservice Development Simon Martinelli, [email protected], v2020.02 Overview 2 From Application to Platform Application Application Framework Infrastructure Library Application Code Java Platform Web Container EJB Container Components Components Services 3 Platform Components Components Components Components Components Container Services Application-Oriented Middleware / Java Platform Communication Infrastructure OS / Distributed System 4 Container, Services and Components Platform contains provides Container Service runs in uses Components 5 Principles and Patterns 1. Injection and Factory 2. Context - 3. Proxy 4. Interceptors 6 Martin Fowler, 2004 http://martinfowler.com/articles/injection.html 7 Background ▶ The question is, what aspect of control are [they] inverting? ▶ Martin Fowler asked this question about Inversion of Control (IoC) in 2004 on his website ▶ Fowler made the proposal to rename the Principle “Dependency Injection” so that it is self-explanatory 8 A Naive Approach 9 Traditional Method private MovieFinder finder; public MovieLister() { finder = new ColonDelimitedMovieFinder("movies1.txt"); } ▶ Problems ▶ Strong coupling ▶ Hard to extend 10 Factory Patterns Abstract Factory Factory Method 11 Solution: Factory Method public class MoveFinderFactory() { public static MovieFinder createMovieFinder(String f) { return new ColonDelimitedMovieFinder(f); } } ▶ Problems ▶ Unnecessary code ▶ Problem moved to the factory ▶ How is the factory configured? 12 Solution: Service Locator 13 Solution:
    [Show full text]