Applications and InfrastructureThe SQL

Agenda

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

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...

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?

TP Monitor: Importance

Underlies e-commerce Used for production systems in medium to large

enterprises -- mission critical Big part of the computer systems market

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

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

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)

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

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

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

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?

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

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

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

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?

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

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

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?

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

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

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

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

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 separates application services from system details

ORB + TPM using objects also called Component Transaction Monitor(CTM)