1 / 22

Applications and Infrastructure

Applications and Infrastructure. Agenda. Architecture and Environments Computing Environments Computing Orientations Transaction Processing Monitor Object Transaction Monitor. Architecture and Environments. Architecture: not just form, function, style

zaynah
Download Presentation

Applications and Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Applications and Infrastructure

  2. Agenda • Architecture and Environments • Computing Environments • Computing Orientations • Transaction Processing Monitor • Object Transaction Monitor

  3. Architecture and Environments • Architecture: not just form, function, style • Also heavily influenced by environment, orientation, history, materials, & technology • environment: the context into which the architected entity is placed or used • for example: building set in the woods, CD player for those who jog, a lively musical piece for dancing • environment: often the source for the parts and tools to be used during construction

  4. Computing Environments • Architecture: state, behavior, paradigm • Environment: "business"/application domain, hardware configuration, reusable software • What resources are available to develop software? • How can the software be deployed? • What environment will support the developed software when it runs?

  5. Computing Environments: Basic Hardware Resources • Hardware: • Processor: instruction set, registers, etc. • Main memory (RAM) • Input/output (I/O) mechanism • what’s missing? • Programming in old microcomputer days • toggle switches for input and lights for output • program persisted only while power was on • tedious; could not save/reload useful programs to re-run without re-toggling in program

  6. Computing Environments: Precursor to Operating Systems • Some kind of secondary, non-volatile storage • Some software to boot up computer • loads just enough instructions and data to be able to read more instructions and data from the secondary storage • now present in the boot sector of a diskette, CDROM disc, or hard disk drive • Some software kept track of fixed locations where other programs were loaded • Bootstrap code was first runtime environment

  7. Computing Environments: Early Operating Systems • Key advances in peripheral hardware... • tele-typewriter console, magnetic media (drum, disk, tape), serial communications • ...as well as operating system software... • process and memory management • device management • ...lead to easier system management of expensive computing resources and assembly programming

  8. Computing Environments: Operating Systems • Faster processors, more RAM, more peripherals • allowed sharing of expensive computing resources • inspired virtual memory management in software • later in hardware for better address range protection/performance • managed file systems to organize data • Trend: • better/more hardware • better/more underlying software to exploit hardware • better programming model: less concerns about hardware • Structured programming; modules used

  9. Computing Environments: Modularization Support • Driving factors: • Relocatable programs supported in OS • As OS size grew and number of users sharing RAM grew, need to efficiently manage expensive RAM increased • Compilers compiled source code to "object code" • Static linker concatenated object code files, resolved external references to relative addresses, created load module file • Loader found available RAM location for load module file, added starting address to all relative addresses, and transferred control to starting address

  10. Computing Environments: Dynamic/Shared Link Libraries • Relocatable load modules optimized memory use • Libraries of useful object code were developed • Static linking of library object code in multiple running load modules caused many copies of code to reside in RAM • Dynamic linking: • references to any shared library's object code can be resolved at runtime • one copy shared by all • Shared object code must be re-entrant and serially reusable

  11. Computing Environments: Desktop Application Environment • Where we are today: • DLLs • Windows OS and GUI are DLL based • Linux has shared libraries • also GNOME/KDE on X Window System • configuration repository (e.g., Windows registry) • deploy by retail or Internet download • user installs and configures • persistence of data: predominantly via files • browsers as clients of external computer systems

  12. Computing Environments: Java Runtime Environment • Java Virtual Machine (JVM) • “java” executable • class loader (like DLL system, plus security) • byte code verifier (for security and integrity) • “standard” class files • native platform interface libraries • plus: • application’s class files

  13. Computing Environments: Enterprise App. Environment • Business environment, not personal environment • need to share resources to minimize cost • mission critical software came from (for example): • competition (e.g., streamline order processing) • internal policy (e.g., consolidate accounting) • best practices (e.g., integrate diverse systems) • Early enterprise apps (for example): • banking, flight reservation • stock ticker feeds • batch processing

  14. Enterprise App. Environment Diagrams from: Building Java Enterprise Systems with J2EE, Perrone & Chaganti, Sams Publishing, 2000.

  15. Computing Orientations • Data oriented • distributed, persistent state • high overhead, high availability, complex development • Process oriented • distributed, volatile state • low overhead, high availability, lack of standardization • Message oriented • one-way, send-and-forget • low/high overhead, low/high availability

  16. Transaction Processing Monitor:Introduction • early client-server development environment • manages applications, load and availability • “operating environment” that monitors and controls transaction processing in and among applications • includes managing: • DB connections • network resources • OS resources

  17. Transaction Processing Monitor:Characteristics • reliable transactions • consistent client response time • maintaining throughput (transactions per second) • large number of terminals and active users • associative and random accesses to files • fine-grained failure handling • intensity of DB and communication management vs. computation • requirement for high availability • business logic in procedural code • proprietary interfaces

  18. Transaction Processing Monitor:Transactions • unit of work (“bracketed” by start…end) • ACID properties • commit or roll back changes • not operations are undoable • multiple DBMSes per transaction are possible • 2 phase commit: • Phase 1: all DBMSes write updates to stable storage • Phase 2: after Phase 1 acks, all DBMSes commit • transactions not restricted to DBMSes

  19. Transaction Processing Monitor:Requests • user-oriented, but may originate from app • may require several transactions to complete • For example, one request may consist of these transactions • enter order • request shipment • issue bill • application developer delimits transaction boundaries of requests

  20. Transaction Processing Monitor:Services • Naming: map application name to app instance • Connection: funnels requests from clients to apps • Resource Routing: request indicates set of resources to use, TPM provides access • Activation: detect and respond to faults by creating and/or utilizing redundant parts

  21. Object Request Brokers • conceptually: • communication bus for object access and interaction • in reality, shared libraries of code used by • client objects to access distributed services • server objects to provide distributed services • client stubs and server skeletons that handle: • marshaling/unmarshaling • method identification and location • object activation (server side) • foundation for object services

  22. Object Transaction Monitor • fueled by need to build enterprise apps: • more rapidly • with higher reliability • high interoperability • better development environments • focus on objects, not application procedures • ORB + TPM using objects • also called Component Transaction Monitor(CTM)

More Related