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)