DOCSLIB.ORG

A Method for Component-Based and Service-Oriented Software Systems Engineering

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Method for Component-Based and Service-Oriented Software Systems Engineering A Method for Component-Based and Service-Oriented Software Systems Engineering Zoran Stojanović A Method for Component-Based and Service-Oriented Software Systems Engineering PROEFSCHRIFT ter verkrijging van de graad van doctor, aan de Technische Universiteit Delft, op gezag van de Rector Magnificus Prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties, in het openbaar te verdedigen op dinsdag 22 februari 2005 om 15:30 uur door Zoran STOJANOVIĆ diploma engineer en magister computer science van de Universiteit van Niš, Servië en Montenegro geboren te Niš, Servië en Montenegro Dit proefschrift is goedgekeurd door de promotor: Prof. dr. H.G. Sol Toegevoegd promotor: Dr. A.N.W. Dahanayake Samenstelling promotiecommissie: Rector Magnificus, voorzitter Prof. dr. H.G. Sol, Technische Universiteit Delft, promotor Dr. A.N.W. Dahanayake, Technische Universiteit Delft, toegevoegd promotor Prof. dr. ir. A. Verbraeck, University of Maryland, USA Prof. dr. R. Welke, Georgia State University, USA Prof. dr. R.W. Wagenaar, Technische Universiteit Delft Prof. dr. ir. P.J.M. van Oosterom, Technische Universiteit Delft To my parents To Nada Published and distributed by: Zoran Stojanović Oostblok 144 Delft University of Technology 2612 PG Delft Faculty of Technology, Policy and Management The Netherlands Jaffalaan 5 Phone: +31 (0) 6 2850 2188 2628 BX Delft, The Netherlands Email: [email protected] Phone: +31 (0)15 278 8380 Fax: +31 (0)15 278 3429 English editor: Miranda Aldham-Breary Printing: Febodruk BV- www.febodruk.nl, Enschede/Utrecht Cover picture: © AV Bros, www.avbros.com Zoran Stojanović A Method for Component-Based and Service-Oriented Software Systems Engineering Doctoral Dissertation, Delft University of Technology, The Netherlands ISBN: 90-9019100-3 Keywords: Component-Based Development, Model-Driven Architecture, Service-Oriented Software Engineering Copyright © 2005 by Zoran Stojanović All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the written permission of the author. Contents Preface ........................................................................................................................ xi 1 Components and Services ....................................................................................... 1 1.1 Background and Motivation ........................................................................................ 1 1.1.1 Managing Complexity and Changes........................................................................ 1 1.1.2 Methodology Needs................................................................................................. 5 1.2 Research Objective and Questions .............................................................................. 7 1.3 Research Approach..................................................................................................... 12 1.3.1 Research philosophy.............................................................................................. 12 1.3.2 Research strategy................................................................................................... 13 1.3.3 Research instruments............................................................................................. 15 1.4 Thesis Outline..............................................................................................................16 2 The State-of-the-Art of Component-Based Software Systems Development ... 19 2.1 The Roots of CBD........................................................................................................ 19 2.2 Component Basics ....................................................................................................... 21 2.2.1 Component Definitions ......................................................................................... 21 2.2.2 Components and Objects....................................................................................... 23 2.2.3 Component Interface ............................................................................................. 25 2.2.4 Components and Architecture ............................................................................... 26 2.3 Technology Standards for CBD ................................................................................. 29 2.3.1 Microsoft Component Model ................................................................................ 29 2.3.2 Enterprise Java Beans Component Model (EJB)................................................... 30 2.3.3 CORBA Component Model (CCM)...................................................................... 31 2.3.4 Summary of Implementation Models .................................................................... 32 2.4 Component-Based Development Methods and Approaches.................................... 33 2.4.1 Rational Unified Process ....................................................................................... 33 2.4.2 Select Perspective.................................................................................................. 34 2.4.3 Catalysis ................................................................................................................ 35 2.4.4 KobrA.................................................................................................................... 36 2.4.5 UML Components................................................................................................. 37 2.4.6 Business Component Factory ................................................................................ 38 2.4.7 Summary of the Methods ...................................................................................... 39 2.5 Components and Web Services.................................................................................. 40 2.6 Model-Driven Development and Agile Development............................................... 43 2.6.1 Model-Driven Architecture ................................................................................... 43 2.6.2 Agile Development................................................................................................ 44 2.6.3 Model-driven vs. Agile Development ................................................................... 45 2.7 New Developments in Component Modeling............................................................ 46 2.7.1 EDOC Profile ........................................................................................................ 46 2.7.2 UML 2.0................................................................................................................ 47 2.8 State-of-the-Art Survey Findings............................................................................... 49 2.8.1 Analysis of the CBD Methods............................................................................... 50 2.8.1.1 The Way of Thinking...................................................................................... 51 2.8.1.2 The Way of Modeling..................................................................................... 54 2.8.1.3 The Way of Working ...................................................................................... 56 2.8.1.4 The Way of Controlling ................................................................................. 59 2.9 CBD Method Requirements ....................................................................................... 60 2.9.1 Basic Method Requirements.................................................................................. 60 2.9.2 Requirements for Component-Orientation ............................................................ 61 2.9.3 Evaluation of CBD methods.................................................................................. 62 2.9.4 Evaluation Findings............................................................................................... 64 2.9.5 Conclusion............................................................................................................. 66 3 Component-Based Development in Practice....................................................... 67 3.1 Airport Business.......................................................................................................... 67 3.1.1 Airport Strategic Exploration ................................................................................ 67 3.1.2 A Support for Airport Strategic Planning.............................................................. 69 3.2 The Airport Business Suite......................................................................................... 70 3.2.1 The System Structure ............................................................................................ 70 3.2.2 Prototype Implementation ..................................................................................... 71 3.3 Design and Implementation of the ABS .................................................................... 72 3.3.1 The Basic Component Architecture of the ABS.................................................... 72 3.3.2 Decomposition of the Main Model Components................................................... 73 3.3.3 Implementation of the ABS Components.............................................................. 75 3.3.4 The Role of the Researcher ................................................................................... 76
Load more

Recommended publications
  • Stclang: State Thread Composition As a Foundation for Monadic Dataflow Parallelism Sebastian Ertel∗ Justus Adam Norman A
    STCLang: State Thread Composition as a Foundation for Monadic Dataflow Parallelism Sebastian Ertel∗ Justus Adam Norman A. Rink Dresden Research Lab Chair for Compiler Construction Chair for Compiler Construction Huawei Technologies Technische Universität Dresden Technische Universität Dresden Dresden, Germany Dresden, Germany Dresden, Germany [email protected] [email protected] [email protected] Andrés Goens Jeronimo Castrillon Chair for Compiler Construction Chair for Compiler Construction Technische Universität Dresden Technische Universität Dresden Dresden, Germany Dresden, Germany [email protected] [email protected] Abstract using monad-par and LVars to expose parallelism explicitly Dataflow execution models are used to build highly scalable and reach the same level of performance, showing that our parallel systems. A programming model that targets parallel programming model successfully extracts parallelism that dataflow execution must answer the following question: How is present in an algorithm. Further evaluation shows that can parallelism between two dependent nodes in a dataflow smap is expressive enough to implement parallel reductions graph be exploited? This is difficult when the dataflow lan- and our programming model resolves short-comings of the guage or programming model is implemented by a monad, stream-based programming model for current state-of-the- as is common in the functional community, since express- art big data processing systems. ing dependence between nodes by a monadic bind suggests CCS Concepts • Software and its engineering → Func- sequential execution. Even in monadic constructs that explic- tional languages. itly separate state from computation, problems arise due to the need to reason about opaquely defined state.
    [Show full text]
  • APPLYING MODEL-VIEW-CONTROLLER (MVC) in DESIGN and DEVELOPMENT of INFORMATION SYSTEMS an Example of Smart Assistive Script Breakdown in an E-Business Application
    APPLYING MODEL-VIEW-CONTROLLER (MVC) IN DESIGN AND DEVELOPMENT OF INFORMATION SYSTEMS An Example of Smart Assistive Script Breakdown in an e-Business Application Andreas Holzinger, Karl Heinz Struggl Institute of Information Systems and Computer Media (IICM), TU Graz, Graz, Austria Matjaž Debevc Faculty of Electrical Engineering and Computer Science, University of Maribor, Maribor, Slovenia Keywords: Information Systems, Software Design Patterns, Model-view-controller (MVC), Script Breakdown, Film Production. Abstract: Information systems are supporting professionals in all areas of e-Business. In this paper we concentrate on our experiences in the design and development of information systems for the use in film production processes. Professionals working in this area are neither computer experts, nor interested in spending much time for information systems. Consequently, to provide a useful, useable and enjoyable application the system must be extremely suited to the requirements and demands of those professionals. One of the most important tasks at the beginning of a film production is to break down the movie script into its elements and aspects, and create a solid estimate of production costs based on the resulting breakdown data. Several film production software applications provide interfaces to support this task. However, most attempts suffer from numerous usability deficiencies. As a result, many film producers still use script printouts and textmarkers to highlight script elements, and transfer the data manually into their film management software. This paper presents a novel approach for unobtrusive and efficient script breakdown using a new way of breaking down text into its relevant elements. We demonstrate how the implementation of this interface benefits from employing the Model-View-Controller (MVC) as underlying software design paradigm in terms of both software development confidence and user satisfaction.
    [Show full text]
  • Process Scheduling
    PROCESS SCHEDULING ANIRUDH JAYAKUMAR LAST TIME • Build a customized Linux Kernel from source • System call implementation • Interrupts and Interrupt Handlers TODAY’S SESSION • Process Management • Process Scheduling PROCESSES • “ a program in execution” • An active program with related resources (instructions and data) • Short lived ( “pwd” executed from terminal) or long-lived (SSH service running as a background process) • A.K.A tasks – the kernel’s point of view • Fundamental abstraction in Unix THREADS • Objects of activity within the process • One or more threads within a process • Asynchronous execution • Each thread includes a unique PC, process stack, and set of processor registers • Kernel schedules individual threads, not processes • tasks are Linux threads (a.k.a kernel threads) TASK REPRESENTATION • The kernel maintains info about each process in a process descriptor, of type task_struct • See include/linux/sched.h • Each task descriptor contains info such as run-state of process, address space, list of open files, process priority etc • The kernel stores the list of processes in a circular doubly linked list called the task list. TASK LIST • struct list_head tasks; • init the "mother of all processes” – statically allocated • extern struct task_struct init_task; • for_each_process() - iterates over the entire task list • next_task() - returns the next task in the list PROCESS STATE • TASK_RUNNING: running or on a run-queue waiting to run • TASK_INTERRUPTIBLE: sleeping, waiting for some event to happen; awakes prematurely if it receives a signal • TASK_UNINTERRUPTIBLE: identical to TASK_INTERRUPTIBLE except it ignores signals • TASK_ZOMBIE: The task has terminated, but its parent has not yet issued a wait4(). The task's process descriptor must remain in case the parent wants to access it.
    [Show full text]
  • System-Of-Systems Viewpoint for System Architecture Documentation
    System-of-Systems Viewpoint for System Architecture Documentation John Klein∗ and Hans van Vliet† VU University, Amsterdam, Netherlands Revised 11 Nov 2017 Abstract Context: The systems comprising a system of systems (SoS) are inde- pendently acquired, operated, and managed. Frequently, the architecture documentation of these existing systems addresses only a stand-alone perspective, and must be augmented to address concerns that arise in the integrated SoS. Objective: We evaluated an architecture documentation viewpoint to address the concerns of a SoS architect about a constituent system, to support SoS design and analysis involving that constituent system. Method: We performed an expert review of documentation produced by applying the viewpoint to a system, using the active review method. Results: The expert panel was able to used a view constructed using the baseline version of the viewpoint to answer questions related to all SoS architect concerns about a constituent system, except for questions concerning the interaction of the constituent system with the platform and network infrastructure. Conclusions: We found that the expert panel was unable to answer certain questions because the baseline version of the viewpoint had a gap in coverage related to relationship of software units of execution (e.g., processes or services) to computers and networks. The viewpoint was revised to add a Deployment Model to address these concerns, and is included in an appendix. arXiv:1801.06837v1 [cs.SE] 21 Jan 2018 Keywords: architecture documentation; system of systems; viewpoint defi- nition; active review; expert panel; design cycle 1 Introduction A system of systems (SoS) is created by composing constituent systems.
    [Show full text]
  • Scheduling: Introduction
    7 Scheduling: Introduction By now low-level mechanisms of running processes (e.g., context switch- ing) should be clear; if they are not, go back a chapter or two, and read the description of how that stuff works again. However, we have yet to un- derstand the high-level policies that an OS scheduler employs. We will now do just that, presenting a series of scheduling policies (sometimes called disciplines) that various smart and hard-working people have de- veloped over the years. The origins of scheduling, in fact, predate computer systems; early approaches were taken from the field of operations management and ap- plied to computers. This reality should be no surprise: assembly lines and many other human endeavors also require scheduling, and many of the same concerns exist therein, including a laser-like desire for efficiency. And thus, our problem: THE CRUX: HOW TO DEVELOP SCHEDULING POLICY How should we develop a basic framework for thinking about scheduling policies? What are the key assumptions? What metrics are important? What basic approaches have been used in the earliest of com- puter systems? 7.1 Workload Assumptions Before getting into the range of possible policies, let us first make a number of simplifying assumptions about the processes running in the system, sometimes collectively called the workload. Determining the workload is a critical part of building policies, and the more you know about workload, the more fine-tuned your policy can be. The workload assumptions we make here are mostly unrealistic, but that is alright (for now), because we will relax them as we go, and even- tually develop what we will refer to as ..
    [Show full text]
  • (2008). Exploring the Impact of Systems Architecture
    Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity Dr. Rashmi Jaini, Anithashree Chandrasekaran, George Elias, Dr. Robert Cloutier Stevens Institute of Technology [email protected], [email protected], [email protected], [email protected] Abstract development projects in the government The need to perform faster systems sector. integration of complex systems require the Keywords: System Architecture, System architect and design team understand how Integration, Integration Complexity, System the selected architecture and design Requirements components will impact the system Introduction integration processes complexity. System It is necessary to determine if integration process complexity is an integration of the defined physical elements outcome of the interaction between degree and interfaces in system architecture of feasibility and level of effort required to contributes to system integration process understand, describe, implement, manage complexity. Today’s systems are usually and document the system integration process expected to function independently and in for a given system development and cooperation with the existing systems operational environment. This paper (system of systems). The cooperating analyzes the cause and effect relationships systems undergo frequent changes and between the system requirements, interoperability becomes a key factor and a architecture and the system integration major contributor to system integration processes complexity. In order to address process complexity. Interoperability is based systems integration issues upfront in the on the existence of the conceptual view design phase it is necessary to determine if [Carney and Oberndoff, 2004]. The the architecture and design of components, conceptual view can be embodied in sub-systems, processes and interfaces requirements and architecture/design and the impacts (and to what extent) system system architecture determines the level of integration process complexity.
    [Show full text]
  • Scheduling Light-Weight Parallelism in Artcop
    Scheduling Light-Weight Parallelism in ArTCoP J. Berthold1,A.AlZain2,andH.-W.Loidl3 1 Fachbereich Mathematik und Informatik Philipps-Universit¨at Marburg, D-35032 Marburg, Germany [email protected] 2 School of Mathematical and Computer Sciences Heriot-Watt University, Edinburgh EH14 4AS, Scotland [email protected] 3 Institut f¨ur Informatik, Ludwig-Maximilians-Universit¨at M¨unchen, Germany [email protected] Abstract. We present the design and prototype implementation of the scheduling component in ArTCoP (architecture transparent control of parallelism), a novel run-time environment (RTE) for parallel execution of high-level languages. A key feature of ArTCoP is its support for deep process and memory hierarchies, shown in the scheduler by supporting light-weight threads. To realise a system with easily exchangeable components, the system defines a micro-kernel, providing basic infrastructure, such as garbage collection. All complex RTE operations, including the handling of parallelism, are implemented at a separate system level. By choosing Concurrent Haskell as high-level system language, we obtain a prototype in the form of an executable specification that is easier to maintain and more flexible than con- ventional RTEs. We demonstrate the flexibility of this approach by presenting implementations of a scheduler for light-weight threads in ArTCoP, based on GHC Version 6.6. Keywords: Parallel computation, functional programming, scheduling. 1 Introduction In trying to exploit the computational power of parallel architectures ranging from multi-core machines to large-scale computational Grids, we are currently developing a new parallel runtime environment, ArTCoP, for executing parallel Haskell code on such complex, hierarchical architectures.
    [Show full text]
  • Scheduling Weakly Consistent C Concurrency for Reconfigurable
    SUBMISSION TO IEEE TRANS. ON COMPUTERS 1 Scheduling Weakly Consistent C Concurrency for Reconfigurable Hardware Nadesh Ramanathan, John Wickerson, Member, IEEE, and George A. Constantinides Senior Member, IEEE Abstract—Lock-free algorithms, in which threads synchronise These reorderings are invisible in a single-threaded context, not via coarse-grained mutual exclusion but via fine-grained but in a multi-threaded context, they can introduce unexpected atomic operations (‘atomics’), have been shown empirically to behaviours. For instance, if another thread is simultaneously be the fastest class of multi-threaded algorithms in the realm of conventional processors. This article explores how these writing to z, then reordering two instructions above may algorithms can be compiled from C to reconfigurable hardware introduce the behaviour where x is assigned the latest value via high-level synthesis (HLS). but y gets an old one.1 We focus on the scheduling problem, in which software The implication of this is not that existing HLS tools are instructions are assigned to hardware clock cycles. We first wrong; these optimisations can only introduce new behaviours show that typical HLS scheduling constraints are insufficient to implement atomics, because they permit some instruction when the code already exhibits a race condition, and races reorderings that, though sound in a single-threaded context, are deemed a programming error in C [2, §5.1.2.4]. Rather, demonstrably cause erroneous results when synthesising multi- the implication is that if these memory accesses are upgraded threaded programs. We then show that correct behaviour can be to become atomic (and hence allowed to race), then existing restored by imposing additional intra-thread constraints among scheduling constraints are insufficient.
    [Show full text]
  • Fork-Join Pattern
    Fork-Join Pattern Parallel Computing CIS 410/510 Department of Computer and Information Science Lecture 9 – Fork-Join Pattern Outline q What is the fork-join concept? q What is the fork-join pattern? q Programming Model Support for Fork-Join q Recursive Implementation of Map q Choosing Base Cases q Load Balancing q Cache Locality and Cache-Oblivious Algorithms q Implementing Scan with Fork-Join q Applying Fork-Join to Recurrences Introduction to Parallel Computing, University of Oregon, IPCC Lecture 9 – Fork-Join Pattern 2 Fork-Join Philosophy When you come to a fork in the road, take it. (Yogi Bera, 1925 –) Introduction to Parallel Computing, University of Oregon, IPCC Lecture 9 – Fork-Join Pattern 3 Fork-Join Concept q Fork-Join is a fundamental way (primitive) of expressing concurrency within a computation q Fork is called by a (logical) thread (parent) to create a new (logical) thread (child) of concurrency ❍ Parent continues after the Fork operation ❍ Child begins operation separate from the parent ❍ Fork creates concurrency q Join is called by both the parent and child ❍ Child calls Join after it finishes (implicitly on exit) ❍ Parent waits until child joins (continues afterwards) ❍ Join removes concurrency because child exits Introduction to Parallel Computing, University of Oregon, IPCC Lecture 9 – Fork-Join Pattern 4 Fork-Join Concurrency Semantics q Fork-Join is a concurrency control mechanism ❍ Fork increases concurrency ❍ Join decreases concurrency q Fork-Join dependency rules ❍ A parent must join with its forked children
    [Show full text]
  • Toward an Evolutionary System of Systems Architecture Scott A
    Toward an Evolutionary System of Systems Architecture Scott A. Selberg Mark A. Austin Agilent Technologies, Inc. Institute for Systems Research 1400 Fountain Grove Parkway University of Maryland Mailstop 4USE Col 26HH College Park, MD 20742 Santa Rosa, CA 95403 Copyright © 2008 by Institute for Systems Research. Published and used by INCOSE with permission. Abstract. While recent advances in computing/communications technology have enabled the development and managed evolution of large scale system of systems (SoS) applications, lessons learned from industry indicate that these projects are not always successful. A key problem is the lack of a formal framework from which the development and management of SoS architectures can be studied. This paper describes the key ingredients and approaches to formal analysis that we believe will end up in this architectural infrastructure. Introduction The world is full of systems that are being upgraded from industrial- to information-age capability. System upgrades are commonly driven by the need for enhancements, either by expanding functionality or improving performance. Often, present-day systems are limited by their ability to: (1) sense the surrounding environment in which they are operating, (2) look ahead and anticipate events, and (3) control system behavior. In an effort to relax, or even remove, these constraints, next-generation systems are incorporating advances in computing, sensing, and communications. Sensors gather data which is fed to computers for advanced processing. The enriched information leads to better decision making which in turn is fed back to automated control systems. Through this process, the aforementioned barriers are overcome, thereby providing the desired results. The first important consequence of this trend is that over time, present-day reliance on centralized management of operations will be replaced by operations that are partially or fully decentralized.
    [Show full text]
  • An Analytical Model for Multi-Tier Internet Services and Its Applications
    An Analytical Model for Multi-tier Internet Services and Its Applications Bhuvan Urgaonkar, Giovanni Pacificiy, Prashant Shenoy, Mike Spreitzery, and Asser Tantawiy Dept. of Computer Science, y Service Management Middleware Dept., University of Massachusetts, IBM T. J. Watson Research Center, Amherst, MA 01003 Hawthorne, NY 10532 fbhuvan,[email protected] fgiovanni,mspreitz,[email protected] ABSTRACT that is responsible for HTTP processing, a middle tier Java enterprise Since many Internet applications employ a multi-tier architecture, server that implements core application functionality, and a back- in this paper, we focus on the problem of analytically modeling the end database that stores product catalogs and user orders. In this behavior of such applications. We present a model based on a net- example, incoming requests undergo HTTP processing, processing work of queues, where the queues represent different tiers of the by Java application server, and trigger queries or transactions at the application. Our model is sufficiently general to capture (i) the database. behavior of tiers with significantly different performance charac- This paper focuses on analytically modeling the behavior of multi- teristics and (ii) application idiosyncrasies such as session-based tier Internet applications. Such a model is important for the follow- workloads, tier replication, load imbalances across replicas, and ing reasons: (i) capacity provisioning, which enables a server farm caching at intermediate tiers. We validate our model using real to determine how much capacity to allocate to an application in or- multi-tier applications running on a Linux server cluster. Our exper- der for it to service its peak workload; (ii) performance prediction, iments indicate that our model faithfully captures the performance which enables the response time of the application to be determined of these applications for a number of workloads and configurations.
    [Show full text]
  • Systems Architecture: Product Designing and Engineering Social
    Systems Architecture: Product Designing and Social Engineering Rebecca E. Grinter Bell Labs, Lucent Technologies 263 Shuman Blvd Naperville, IL 60566 USA [email protected] http://www.bell-labs.com/-beki ABSTRACT structure - of what was being designed. The role of The production of large and complex systems usually architect evolved to fill that gap. requires the coordination and collaboration of many At the same time as the role of architect was being individuals spread among numerous divisions of a established within some corporations, software architecture corporation. However, much research examining emergedas a researcharea. Software architecture researchers coordination has focused on the subtleties of interactions have focusedon a number of topics including architectural between individuals who may work together in the same description languagesfor expressing the design, codifying department. In this paper, I present a study of systems architectural experienceinto principles, and domain-specific architects and the work that they do to coordinate design frameworks with formal methods for reasoning about acrossorganizational and institutional boundaries. I also architectures[ 13,251. describethe processesand tools that the architects use to support their work. The implications of the social While much of the research in software architecture has processesinvolved in coordinating the design of large focusedon the outcome of the process - the architecture complex systemson the product and those involved in its itself - there is an increasing concern being shown for production are discussed. understandinghow architecturework happensin practice [ 1, 131. One reason why there has been a turn to Keywords understanding practice is it is often the relationship between Systems architecture, empirical studies of design and the design and the organization that presents challenges.
    [Show full text]