applications and infrastructure the sql. agenda " hw2 comments " concluding remarks on...
Post on 12-Jan-2016
215 Views
Preview:
TRANSCRIPT
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)
top related