Microsoft .NET: Architecting Applications for the Enterprise

Total Page:16

File Type:pdf, Size:1020Kb

Microsoft .NET: Architecting Applications for the Enterprise User Developmentexperience first and . design. vectors. .. .. .. 138 64 Table ofFocusSOLID onContents interactions principles .. .. .. .. .. .. .. .. .. .. .. .138 64 UX isPatterns not UI . for . handling . dependencies. .. .. .. .. 140 69 HowCoding to create vectors an effective . .experience . .. .. .. .. .. .. 143 72 Realistic scenariosUse of patterns . .. .. .. .. .. .. .. .. 147 75 ASP .NETRefactoring websites . .. .. .. .. .. .. .. .. .. .. 147 77 Introduction xiiiDefensiveWeb Forms programming vs . ASP .NET .MVC . .. .. .. .. 152 78 Errata,Adding updates,The device If-Then-Throw & booksupport support topattern websites . .. .. .. .. .. .. .. .. 155xviii78 FreeSingle-page ebooksSoftware from applications contractsMicrosoft . Press . .. .. .. .. ... 160xix79 Desktop rich client . 164 WeSummary want to hear. from . you . .. .. .. .. .. .. xix . .83 Summary . .166 StayFinishing in touch with . .a . smile . .. .. .. .. .. .. .. .. .. xix84 Finishing with a smile . 166 FoundationWriting software 1 of quality 85 The mythical businessThe art of layer writing testable code . 167 86 Architects Patternsand architecture forWhat organizing is testability, today the business anyway? logic . .. .. .. .. 167 386 What’sThe softwarefairytaleTesting your architecture,of CRUD software and anyway? an . architecture . .. .. .. .Prince. .. .. .. .Charming .. 168 488 Microsoft .NET: TheApplying TransactionCommon architectural practices Script pattern of principles software .. to. testing. software. .. .. 169 496 TheThe Acknowledgingpractice Domain of Model code requirements extensibilitypattern . .. .. .. .. .. .. .. .. .. .. 172 1017 Architecting Applications TheWhat’s AnemicInterface-based architecture Domain designModel and what’s (anti-)pattern. not . .. .. .. .. .. 17411102 Moving theThePlugin focusarchitecture architecturefrom data process to . .tasks . .. .. .. .. .. .. 17614103 for the Enterprise, Who’sTask the Stateorchestration architect, machines anyway? in .ASP . .NET. MVC. .. .. .. .. .. .. .. 17717103 WritingOrchestratingAn architect’s code that tasks responsibilitiesothers within can the read domain . .. .. .. .. .. .. 18018104 Second Edition Moving dataTheReadability roleacross of the as architectboundaries a software . attribute .. .. .. .. .. .. .. .. ... .. .. 18220105 DataCommonSome flow inpractical misconceptions layered rules architecture for aboutimproving . architects . readability . .. .. .. 182 . 21 .107 SummarySummarySharing . the . .. .. Domain .. .. .Model. .. entities. .. .. .. .. .. .. .. .. .. .. 184. 24 .109 Using data-transfer objects . 185 FinishingFinishing with with a smilea smile . .. 25110 Summary . .187 DesigningDevising Finishingforthe successarchitecture with a smile . 18827111 Supporting architecturesThe “Big Ball of Mud” . .. 28 Discovering theCauses domain of the architecture “Big Ball of Mud” . 11328 Dino Esposito Introducing DomainThe Symptomsreal Model added of value the “Bigof domain-driven Ball of Mud” design. .. .. .. 19132114 Andrea Saltarello The data-to-behaviorUsingWhat’s metrics in DDD shiftto detectfor . me?. a. BBM.. .. .. .. .. .. .. .. .. .. .. .. .. .. 19134114 Rationale behind models and domains . 192 MechanicsConducting of software analysis projects using . DDD . .. 35115 Database is infrastructure . 195 OrganizationalStrategic model culture design. .. .. .. .. .. .. .. .. .. .. 35116 InsideThe the Helpingubiquitous domain the layer language team . write . .better .. .. .code . .. .. .. .. .. 19638118 Domain model . 196 Getting Purposeout of the of mess the ubiquitous . language. .. 43118 Aggregates . 199 ThatStructure odd thing of the called ubiquitous “legacy languagecode” . .. .. .. .. .44119 Domain services . 205 CheckmateHow to define in three the moves ubiquitous . language . .. 45119 Domain events . 209 DecidingKeeping whether language or andnot tomodel add manpowerin sync . .. .. .. .. 49121 Cross-cutting concerns . 212 SummaryBounded . contexts. .. .. .. .. .. .. .. .. .. .. .. .. .50122 Summary . Discovering . contexts. .. .. .. .. .. .. .. .. .215 122 Finishing with a smile . .. 51 Finishing withContext a smile mapping . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 215 125 Principles of softwareGiving design each context its own architecture . 53127 Implementing DomainThe layered Model architecture . 217 129 Universal principles of software design . 54 The online Originsstore sample of the projectlayered . architecture . .. .. 218 129 From spaghetti code to lasagna code . 54 SelectedPresentation use-cases layer . .. .. .. .. .. .. .. 218 131 Separation of concerns . 57 SelectedApplication approach layer . .. .. .. .. .. .. 219 132 Isolation . 57 StructureDomain of the layer I-Buy-Stuff . .project . .. .. 220 134 Object-oriented design . 57 SelectedInfrastructure technologies layer .. .. .. .. .. .. .. .. .. .. .. .. .. 222 134 Pertinent classes . 58 SummaryBounded . contexts . for . an . online . store . .. .. .. .. 222. .135 Program to an interface . .59 Context map of the I-Buy-Stuff application . .. 224 FinishingComposition with a smile vs . inheritance . .. .. .. 61135 A second pass at object-orientation . 63 The presentation layer 137 PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2014 by Dino Esposito and Andrea Saltarello All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. Library of Congress Control Number: 2014940680 ISBN: 978-0-7356-8535-2 Printed and bound in the United States of America. Second Printing: January 2015 Microsoft Press books are available through booksellers and distributors worldwide. If you need support related to this book, email Microsoft Press Book Support at [email protected]. Please tell us what you think of this book at http://aka.ms/tellpress. Microsoft and the trademarks listed at http://www.microsoft.com/en-us/legal/intellectualproperty/Trademarks/ EN-US.aspx are trademarks of the Microsoft group of companies. All other marks are property of their respective owners. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fi ctitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred. This book expresses the author’s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. Acquisitions and Developmental Editor: Devon Musgrave Project Editor: Carol Dilllingham Editorial Production: Waypoint Press, www.waypointpress.com Peer Reviewer: Cesar De la Torre Llorente Copyeditor: Roger LeBlanc Indexer: Christina Yeager Cover: Twist Creative • Seattle and Joel Panchot To my wife Silvia. You make me feel sandy like a clepsydra. I get empty and filled all the time; but it’s such a thin kind of sand that even when I’m full, without you, I just feel empty. —DINO To Laura, mum, and Depeche Mode. Moved, lifted higher. Moved, by a higher love. —ANDREA This page intentionally left blank Contents at a glance PART I FOUNDATION CHAPTER 1 Architects and architecture today 3 CHAPTER 2 Designing for success 27 CHAPTER 3 Principles of software design 53 CHAPTER 4 Writing software of quality 85 PART II DEVISING THE ARCHITECTURE CHAPTER 5 Discovering the domain architecture 113 CHAPTER 6 The presentation layer 137 CHAPTER 7 The mythical business layer 167 PART III SUPPORTING ARCHITECTURES CHAPTER 8 Introducing Domain Model 191 CHAPTER 9 Implementing Domain Model 217 CHAPTER 10 Introducing CQRS 255 CHAPTER 11 Implementing CQRS 291 CHAPTER 12 Introducing event sourcing 311 CHAPTER 13 Implementing event sourcing 325 PART IV INFRASTRUCTURE CHAPTER 14 The persistence layer 353 This page intentionally left blank Contents Introduction . xiii PART I FOUNDATION 1 Chapter 1 Architects and architecture today 3 What’s software architecture, anyway?. 4 Applying architectural principles to software . 4 Acknowledging requirements . 7 What’s architecture and what’s not . .11 The architecture process . 14 Who’s the architect, anyway? . 17 An architect’s responsibilities . 18 The role of the architect . .20 Common misconceptions about architects . 21 Summary . 24 Finishing with a smile . 25 Chapter 2 Designing for success 27 The “Big Ball of Mud” . 28 Causes of the “Big Ball of Mud” . 28 Symptoms of the “Big Ball of Mud” . .32 Using metrics to detect a BBM . .34 Mechanics of software projects . ..
Recommended publications
  • Chatbot on Serverless/Lamba Architecture Nandan.A Prof.Shilpa Choudary Student, Reva University Professor, Reva University
    SECOND NATIONAL CONFERENCE ON ADVANCES IN COMPUTING AND INFORMATION TECHNOLOGY ISSN:2347-7385 Chatbot on Serverless/Lamba Architecture Nandan.A Prof.Shilpa Choudary Student, Reva University Professor, Reva University Abstract—The OpenLambda, a new, opensource The logic tier contains the code required to translate platform for building next-generation web services user actions at the presentation tier to the and applications on serverless computation. The functionality key aspects of serverless computation and that drives the application’s behavior. The data tier present numerous research challenges that consists of storage media (databases, object stores, must be, addressed in the design and caches, file systems, etc.) that hold the data relevant implementation of such systems. The study of to the application. Figure 1 shows an example of a current web applications, so as to better motivate simple three-tier application. some aspects of serverless application construction. Chatbots platform are used by consumers worldwide for integrating it with backend services . It is still difficult to build and deploy chatbots developers need to handle the coordination of the backend services to build the chatbot interface, integrate the chatbot with external services, and worry about extensibility, scalability, and maintenance. The serverless architecture could be ideal platform to build the chatbot. Figure 1: Architectural pattern for a simple three- tier application Keywords: Lambda Architecture, Chat-bot, Multitier Architecture, Microservices. In Serverless Multi-Tier Architectures a backend remains private and secure. The benefits of this powerful pattern across each tier of a multi-tiered I. INTRODUCTION architecture. Example of a multitiered architecture is The multi-tier application has been a well- a three-tier web application.
    [Show full text]
  • Download Vol 11, No 1&2, Year 2018
    The International Journal on Advances in Internet Technology is published by IARIA. ISSN: 1942-2652 journals site: http://www.iariajournals.org contact: [email protected] Responsibility for the contents rests upon the authors and not upon IARIA, nor on IARIA volunteers, staff, or contractors. IARIA is the owner of the publication and of editorial aspects. IARIA reserves the right to update the content for quality improvements. Abstracting is permitted with credit to the source. Libraries are permitted to photocopy or print, providing the reference is mentioned and that the resulting material is made available at no cost. Reference should mention: International Journal on Advances in Internet Technology, issn 1942-2652 vol. 11, no. 1 & 2, year 2018, http://www.iariajournals.org/internet_technology/ The copyright for each included paper belongs to the authors. Republishing of same material, by authors or persons or organizations, is not allowed. Reprint rights can be granted by IARIA or by the authors, and must include proper reference. Reference to an article in the journal is as follows: <Author list>, “<Article title>” International Journal on Advances in Internet Technology, issn 1942-2652 vol. 11, no. 1 & 2, year 2018, <start page>:<end page> , http://www.iariajournals.org/internet_technology/ IARIA journals are made available for free, proving the appropriate references are made when their content is used. Sponsored by IARIA www.iaria.org Copyright © 2018 IARIA International Journal on Advances in Internet Technology Volume 11, Number 1 & 2, 2018 Editors-in-Chief Mariusz Głąbowski, Poznan University of Technology, Poland Editorial Advisory Board Eugen Borcoci, University "Politehnica"of Bucharest, Romania Lasse Berntzen, University College of Southeast, Norway Michael D.
    [Show full text]
  • Automated Improvement of Software Architecture Models for Performance and Other Quality Attributes
    Automated Improvement of Software Architecture Models for Performance and Other Quality Attributes Zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften von der Fakultät für Informatik des Karlsruher Instituts für Technologie (KIT) genehmigte Dissertation von Anne Koziolek geb. Martens aus Oldenburg Tag der mündlichen Prüfung: 14.07.2011 Erster Gutachter: Prof. Dr. Ralf Reussner Zweiter Gutachter: Prof. Dr. Andreas Oberweis KIT – Universität des Landes Baden-Württemberg und nationales Forschungszentrum der Helmholtz-Gemeinschaft www.kit.edu Automated Improvement of Software Architecture Models for Performance and Other Quality Attributes PhD thesis to gain the degree “Doktor der Ingenieurwissenschaften” at the Department of Informatics of the Karlsruhe Institute of Technology (KIT) Dissertation by Anne Koziolek neé Martens Oldenburg Day of defence: 14.07.2011 Referees: Prof. Dr. Ralf Reussner Prof. Dr. Andreas Oberweis KIT – University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association www.kit.edu Contents Abstract xi Zusammenfassung xiii Danksagungen xvii 1. Introduction 1 1.1. Motivation . 1 1.2. Problem . 4 1.3. Existing Solutions . 5 1.4. Contributions . 6 1.5. Outline . 9 I. Foundations and Related Work 11 2. Component-based Software Architectures and Quality 13 2.1. Component-based Software Architecture . 13 2.1.1. Definitions . 13 2.1.2. Component-based Software Development Process . 17 2.2. Quality of Software Architectures . 18 2.2.1. Quality Attributes of Software Architecture . 18 2.2.2. Quantitative Quality Properties . 21 2.3. Modelling Concepts . 24 2.3.1. Models and Metamodels . 24 2.3.2. Essential Meta Object Facility . 26 2.4. Model-based Quality Prediction .
    [Show full text]
  • The Role of an Architect
    Learn the discipline, pursue the art, and contribute ideas at www.ArchitectureJournal.net Resources you can build on. Journal 15 The Role of an Architect We Don’t Need No Architects! Becoming an Architect in a System Integrator Architecture Journal Profi le: Paul Priess The Open Group’s Architect Certifi cation Programs The Need for an Architectural Body of Knowledge A Study of Architect Roles by IASA Sweden The Softer Side of the Architect An A-Z Guide to Being an Architect ® Contents TM Journal 15 Foreword 1 by Simon Guest We Don’t Need No Architects 2 by Joseph Hofstader What does an architect do? What should an architect do? Join Joseph Hofstader as he examines the role of an architect. Becoming an Architect in a System Integrator 7 by Amit Unde In this article, Amit Unde explores the skills that aspiring architects need in a leading System Integrator. Architecture Journal Profi le: Paul Preiss 10 We chat with Paul Preiss, founder of a nonprofi t group called IASA (International Association of Software Architects). The Open Group’s Architect Certifi cation Programs 13 by Leonard Fehskens Join Leonard Fehskens as he outlines one of the industry’s architect certifi cation programs, Open Group’s ITAC (IT Architect Certifi cation). The Need for an Architectural Body of Knowledge 17 by Miha Kralj Miha Kralj covers an Architectural Body of Knowledge, an effort led by the Microsoft Certifi ed Architect community. A Study of Architect Roles by IASA Sweden 22 by Daniel Akenine Discover a perspective of architect roles through a recent study conducted by the local IASA chapter in Sweden.
    [Show full text]
  • Web-Based Content Management System
    Maciej Dobecki, Wojciech Zabierowski / Computing, 2010, Vol. 9, Issue 2, 127-130 [email protected] ISSN 1727-6209 www.computingonline.net International Journal of Computing WEB-BASED CONTENT MANAGEMENT SYSTEM Maciej Dobecki, Wojciech Zabierowski Technical University of Lodz, al. Politechniki 11, 90-924 Łódź, Poland, e-mail: [email protected], [email protected] http://www.dmcs.p.lodz.pl Abstract: This paper describes how to design content management system using the newest web-based techniques. It contains helpful information that can be used during selecting programming language. It introduces multi layer architecture with description and functionality of each layer. It provides description of Model View Controller pattern and how to use it in multi-layer application design. It shows the most powerful Java frameworks that can be applied for each layer and how to connect them in simple way, using Inversion of Control container. It shows power of Spring Framework as business layer, Hibernate as integration layer and ZK Ajax as presentation layer. It proves, that Java combined with applicable libraries can be very powerful tool in good hands. Keywords: CMS, JEE, Spring, Hibernate, AJAX. 1. INTRODUCTION CMS is prepared through a simple-to-use user interface. Usually it is a set of web pages containing The Internet – today is the most powerful and complex forms and modules. popular information media. What was impossible The primary task of the CMS platform is even few years ago is now available by “clicking separation of data content from presentation (the the mouse”. Both small firms and global giants do way of its look).
    [Show full text]
  • MV* Design Patterns
    MV* Design Patterns Alexander Nelson August 30, 2021 University of Arkansas - Department of Computer Science and Computer Engineering Reminders Course Mechanics Course Webpage: https://ahnelson.uark.edu/courses/ csce-4623-mobile-programming-fall-2021/ Syllabus is on the website. Course Communication: https://csce4623-uark.slack.com/ This slack channel is to be the primary mode of communication Projects Choose a project idea and team for the final project ASAP First project report is due September 10th Multitier Architectures What is a multitier architecture? Physical separation of data concerns Examples: • Presentation (UI) • Application Processing • Data Management Why split into layers? OSI Model Why split into layers? Separation of concerns! A change to one layer can have no bearing on the rest of the model e.g. Fiberoptic instead of Coax at the PHY layer OSI Model How does this apply to mobile? Application designers often want separation of UI and logic! Three tier architecture These software engineering abstractions relate to the MV* architectures that are common in mobile computing systems Model View Controller (MVC) Model View Controller 1 1Krasner 1988 Definitions Model: Models are those components of the system application that actually do the work View: Display aspects of the models Controller: Used to send messages to the model, provide interface between model, views, and UI devices. Models Models enable encapsulation Model encapsulates all data as well as methods to change them • Can change the underlying data structures without
    [Show full text]
  • Electronic Commerce Basics
    Electronic Commerce Principles and Practice This Page Intentionally Left Blank Electronic Commerce Principles and Practice Hossein Bidgoli School of Business and Public Administration California State University Bakersfield, California San Diego San Francisco New York Boston London Sydney Tokyo Toronto This book is printed on acid-free paper. ∞ Copyright © 2002 by ACADEMIC PRESS All Rights Reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording, or any information storage and retrieval system, without permission in writing from the publisher. Requests for permission to make copies of any part of the work should be mailed to: Permissions Department, Harcourt Inc., 6277 Sea Harbor Drive, Orlando, Florida 32887-6777 Academic Press A Harcourt Science and Technology Company 525 B Street, Suite 1900, San Diego, California 92101-4495, USA http://www.academicpress.com Academic Press Harcourt Place, 32 Jamestown Road, London NW1 7BY, UK http://www.academicpress.com Library of Congress Catalog Card Number: 2001089146 International Standard Book Number: 0-12-095977-1 PRINTED IN THE UNITED STATES OF AMERICA 010203040506EB987654321 To so many fine memories of my brother, Mohsen, for his uncompromising belief in the power of education This Page Intentionally Left Blank Contents in Brief Part I Electronic Commerce Basics CHAPTER 1 Getting Started with Electronic Commerce 1 CHAPTER 2 Electronic Commerce Fundamentals 39 CHAPTER 3 Electronic Commerce in Action
    [Show full text]
  • Client Server Communications Middleware Components
    1 Assistant lecturer Ahmed S. Kareem CLIENT SERVER COMMUNICATIONS MIDDLEWARE COMPONENTS The communication middleware software provides the means through which clients and servers communicate to perform specific actions. It also provides specialized services to the client process that insulates the front-end applications programmer from the internal working of the database server and network protocols. In the past, applications programmers had to write code that would directly interface with specific database language (generally a version of SQL) and the specific network protocol used by the database server. Multitier architecture In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client–server architecture in which the presentation, the application processing, and the data management are logically separate processes. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of multi-tier architecture is the three-tier architecture. N-tier application architecture provides a model for developers to create a flexible and reusable application. By breaking up an application into tiers, developers only have to modify or add a specific layer, rather than have to rewrite the entire application over. There should be a presentation tier, a business or data access tier, and a data tier. The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.
    [Show full text]
  • Design Patterns Past and Future
    Proceedings of Informing Science & IT Education Conference (InSITE) 2011 Design Patterns Past and Future Aleksandar Bulajic Metropolitan University, Belgrade, Serbia [email protected]; [email protected] Abstract A very important part of the software development process is service or component internal de- sign and implementation. Design Patterns (Gamma et al., 1995) provide list of the common pat- terns used in the object-oriented software design process. The primary goal of the Design Patterns is to reuse good practice in the design of new developed components or applications. Another important reason of using Design Patterns is improving common application design understand- ing and reducing communication overhead by reusing the same generic names for implemented solution. Patterns are designed to capture best practice in a specific domain. A pattern is supposed to present a problem and a solution that is supported by an example. It is always worth to listen to an expert advice, but keep in mind that common sense should decide about particular implemen- tation, even in case when are used already proven Design Patterns. Critical view and frequent and well designed testing would give an answer about design validity and a quality. Design Patterns are templates and cannot be blindly copied. Each design pattern records design idea and shall be adapted to particular implementation. Using time to research and analyze existing solutions is recommendation supported by large number of experts and authorities and fits very well in the pattern basic philosophy; reuse solution that you know has been successfully implemented in the past. Sections 2 and 3 are dedicated to the Design Patterns history and theory as well as literature sur- vey.
    [Show full text]
  • Firewall Deployment for Multitier Applications by Lenny Zeltser
    Firewall Deployment for Multitier Applications By Lenny Zeltser This article examines considerations for deploying firewalls as part of a network perimeter around Internet-facing servers. The discussion focuses on situations that may warrant strict separation of network resources into dedicated subnets, and explains how to enforce access restrictions using firewalls in a way that matches business and technical requirements of multitier applications. The article introduces several network architectures that use a single firewall as well as firewalls deployed one behind another in series, and addresses the strengths and weaknesses of each approach. Partitioned network architectures can be used to protect multitier applications accessible over the Web. Following the trend of designing applications in an expandable and scalable manner, these applications are often created by using modules that run on different servers and that typically form three distinct groups: presentation, middleware, and data tiers. Let’s begin by examining how the architecture of such applications may influence the design the network’s security perimeter. Multitier Applications By segmenting a Web-based application into several logical tiers, software architects isolate core functional areas into groupings that can be designed, developed, and maintained somewhat independently of each other. The following tiers are present in some way in most Web-facing applications of moderate complexity: • Presentation components are usually adjacent to the Internet and are the only modules directly accessed by end users. Such publicly accessible services are often implemented using Web, DNS, and mail servers. Software running on these servers, operating as part of a unified system, presents the application to users and handles interactions between users and back-end components.
    [Show full text]
  • State of Washington Department of Labor and Industries
    State of Washington Department of Labor and Industries Centers of Occupation Health and Education Occupational Health Management System (OHMS) Feasibility Study March 5, 2012 FINAL (Version 4.0) Washington Department of Labor & Industries Occupation Health Management System (OHMS) Feasibility Study Status: FINAL Date: March 5, 2012 Document Control This document represents the feasibility study analysis of the information system required to support the Department of Labor and Industries (L&I) Centers of Occupational Health and Education (COHE) as part of the state Workers’ Compensation insurance reform. The study complies with the state Office of the Chief Information Officer (OCIO) requirement for a feasibility study for level 3 projects. Version Date Description/Changes 1.0 1/20/2012 Initial working draft of chapters I–V and initial appendices for review and comment. Preliminary, NOT EDITED version. 2.0 2/7/2012 Incorporated comments on version 1.0 draft. Updated Work Breakdown Structure. Added new chapters VI–X, XIII. Added new appendices for Vendor Survey, Washington HIE, and Risk Factor Analysis. Preliminary, NOT EDITED version. 3.0 2/20/2012 Incorporated comments on version 1.0 draft. Updated Alternatives Comparison chapter. Updated Major Alternatives Considered chapter. Added Estimated Timeframe and Work Plan chapter. Added Cost-Benefit Analysis chapter. Full Draft. EDITED, except Chapter XII – Cost Benefit Analysis 4.0 3/5/2012 Incorporated comments from version 3.0 draft. Incorporated Executive Summary. Incorporated Alternatives vs. Scope Analysis Appendix. The anticipated audience for this report includes L&I, the OCIO, the Technology Advisory Board, and other interested stakeholders. 4016.001\OHMS Feasibility Study\4.0 i FINAL sooscreekconsulting.com 3/5/2012 Washington Department of Labor & Industries Occupation Health Management System (OHMS) Feasibility Study TABLE OF CONTENTS Page I.
    [Show full text]
  • Chapter 4 INTERNET ARCHITECTURES FOR
    Chapter 4 INTERNET ARCHITECTURES FOR APPLICATION SERVICE PROVIDERS Borko Furht, Chris Phoenix, John Yin, and Zijad Aganovic Abstract In recent years, business on the Internet has exponentially increased. Consequently, the deployment and management of business applications on the Internet is becoming more and more complex, which requires the development of new Internet architectures suitable to efficiently run these business applications. In this chapter we present and evaluate several computing models and related Internet architectures for application service providers. We also introduce the server-based model and the corresponding Internet architecture and two case studies, which use the proposed architecture for application deployment. 1. INTRODUCTION 1.1 COMPUTING MODELS FOR INTERNET-BASED ARCHITECTURES The increasingly competitive, global marketplace puts pressure on companies to create and deliver their products faster, with high quality and greater performance. To get the new products and technologies to consumers is through a new industry called Application Service Providers (ASPs). Similarly to Internet Service Providers, that linked businesses and consumers up to the Internet, ASPs lease software applications to businesses and consumers via the Internet. These applications range from word processing programs to payroll management software, document management systems, and many others. The major challenge is to develop an efficient Internet-based architecture, which will efficiently provide access to these software applications over the Internet. Application architectures have traditionally followed software development architectures. The software development architectures can be classified into: · Traditional desktop computing model · Client-server computing model 68 Chapter 4 · Network computing model · Server-based computing model Traditional desktop computing model assumes that the whole application is on the client and the application is executed locally.
    [Show full text]