Post on 21-Feb-2016
description
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 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
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?
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
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
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
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
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
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
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
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
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
Enterprise App. EnvironmentDiagrams from:
Building Java Enterprise Systems with J2EE, Perrone & Chaganti, Sams Publishing, 2000.
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
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
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
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
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
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
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
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)