Applications and Infrastructure

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)