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
• whats 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
• applications 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 MonitorIntroduction

• 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 MonitorCharacteristics

• 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 MonitorTransactions

• unit of work (bracketed by startend)
• 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 MonitorRequests

• 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 MonitorServices

• 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)