Upload
virginia-montgomery
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
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. Environment
Diagrams 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)