Applications and Infrastructure The SQL

1
Applications and InfrastructureThe SQL
2
Agenda

• HW2 Comments
• Concluding remarks on Transactions
• Summary of Last Class
• Transaction Processing Monitor (continued)
• Object Request Broker
• Object Transaction Monitor

3
Summary of Last Class

• Architects consider the environment in which the
  entity will be placed or used.
• Software is architected to run in an environment.
• Other than the OS itself, shared/dynamic link
  libraries are the primary components of current
  desktop runtime environments.
• Java provides a shared class library plus a
  virtual machine as its environment.
• EA environments are another matter...

4
Enterprise App. (EA) Environment

• Historically
• big companies thin clients (terminals) and fat
  servers
• depts/small companies fat clients and DBMS
  servers
• why?
• as depts/companies grow thin clients and fat
  servers
• why?
• Implication EA environment is primarily where?

5
TP Monitor Importance

• Underlies e-commerce
• Used for production systems in medium to large
  enterprises -- mission critical
• Big part of the computer systems market

6
TP 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

7
TP Monitor Bernstein's Model

• primary function of TPM
• "control flow of transaction requests between
  terminals or other devices and the application
  program that can process those requests"
• Message Manager (MM)
• manages display to and input from terminals
• Request Control (RC)
• manages transaction and starts app
• Application Server (AS)
• determines app, interfaces with DBMS

8
TP Monitor Control Flow

• 1.Interact with user to collect input (MM)
• 2.Translate input into request format (MM)
• 3.Start transaction (RC)
• 4.Examine request type to determine app (AS)
• 5.Execute appropriate app (RC)
• 6.Commit transaction (RC)
• 7.Send output to terminal (MM)

9
TP Monitor Message Manager

• collects input and displays output
• formats requests for RC (standardizes interface)
• manages forms (maps requests to terminal's
  format)
• validates input
• displays output
• or, interprets device command (e.g., issue cash)
• checks security (user id is embedded in each
  request)
• application developer tasks
• write forms definitions
• TPM compiles definitions into requirements
• write data validation routines

10
TP Monitor Request Control

• sends request to AS
• binds request id to AS
• passes parms from request to app
• application developer tasks
• provide mapping of request type to app id
• dynamic mapping of request type to id
• helps fault tolerance
• allows system manager to manually remap to other
  ids for performance
• can use global name service to allow forwarding
  of requests by AS no need for RC

11
TP Monitor Application Server

• one or more apps that typically access a shared
  DB
• TPM
• links RC to an AS
• provides app access to terminal
• may provide process management and communication
  to app as some kind of service

12
TP Monitor Process Management

• Process
• address space, processor state and a set of
  resources
• MMs, RCs, ASs created and managed either as
• one address space
• split into multiple address spaces
• separate processes with more than one thread of
  control
• What is this splitting approach called?

13
TPM Process Management --Single Address Space

• one process per terminal
• all components linked together
• communication via local procedure calls
• advantages speed
• disadvantages
• doesn't scale well due to OS inefficiencies
• lengthy process table searches
• context switching (preserve state and flush
  caches)
• big consumption of fixed memory
• possibly too much paging
• can't control load well
• not fine-grained enough -- can't prioritize by
  request types

14
TPM Process Management --Multi-threading
Overview

• one process per group of terminals
• each terminal has own thread and shares address
  space
• TPM or OS manages threads
• Disadvantages
• weaker storage protection than single address
  space
• what can mitigate this?
• two levels of scheduling make priority
  adjustments harder

15
TPM Process Management --Multi-threading
Approaches

• TPM-managed
• must subdivide process's memory space
• must store thread id in service call
• must handle routing to correct thread after
  service call
• synchronous call can cause all threads in process
  to block
• OS-managed
• knows about threads
• only thread needing resource will be blocked
• threads can be assigned to other processors

16
TP Monitor Communication Management

• message passing
• establish connection
• pass message
• remote procedure call (RPC)
• call stub that connects to skeleton, marshals
  parameters, sends to skeleton
• skeleton unmarshals parameters, calls procedure,
  marshals results, sends to stub
• stub unmarshals results, returns to caller
• Advantages? Disadvantages?

17
TPM Communication Management -- Message Passing

• example SNA "conversation"
• half-duplex (one way at a time)
• each process can send/recv over the conversation
• when finished sending, explicitly tells other
  process OK to send

18
RPC vs. LPC

• LPC -- procedure executes exactly once
• idempotent
• executable any number of times without side
  effects
• RPC semantics
• exactly once
• hard to achieve, due to server crashes
• at most once
• not at all or one time at most
• error return means uncertain if procedure
  executed once or not
• at least once
• but perhaps more than once typical of idempotent
  procedures

19
Availability

• fraction of time system is available to do work
• downtime
• due to environment, system management, hardware,
  and software failures
• one hour per day
• 23 hrs /24 hrs 95.83 of the time system is
  available
• What is one hour per year availability?
• When do you recall downtime being reported
  nationally?
• How to address hw/sw failures? Overloading?

20
TP Monitor Queuing

• put requests and responses on stable storage
• each transaction that executes a request dequeues
  request within itself
• increases reliability -- dequeued request also
  gets rolled back
• log requests to aid in recovery
• responses under transaction control guarantees
  delivery
• requests with multiple transactions
• can use queue to communicate amongst transactions
  
• including scheduling info can help prioritize
• length of request queues is good measure of
  performance (requests not processed)
• disadvantage more expensive to enqueue/dequeue
  than to send message directly

21
TP Monitor Configuration/System Management

• each MM's terminals and forms
• user authorization information
• what requests get routed by each RC
• what programs get managed by each AS
• name of nodes where each process executes
• System manager can
• create/destroy processes
• move processes between nodes
• alter sets of forms and programs used by each
  process
• adjust configuration to improve response time and
  throughput

22
TP Monitor Reporting and Recovery

• TPM can
• report transaction rates
• report response times
• manage failures automatically due to its
  knowledge of configuration
• i.e., transparent recovery
• report on accounting, security and capacity
  planning issues

23
TP Monitor Performance Issues

• Characteristics
• 1-100 transaction types per app
• transaction activity in terms of hardware
  operations varies
• 0-30 disk accesses, 10K-1M instructions, 2-20
  messages
• Metrics
• response time
• for clients to receive response to a request
• throughput
• number of transactions per second

24
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

25
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
• separates application services from system
  details
• ORB TPM using objects
• also called Component Transaction Monitor(CTM)