Download Kapitel 13 - uni

Universität
Karlsruhe (TH)
Information System Architectures:
From Art to Science
Peter C. Lockemann
© 2003 IPD, Prof. Lockemann
BTW03
Agenda
‹#›
requirements
specification
architectural design =
programming-in-thevery-large
systems
architecture
S/H system
© 2003 IPD, Prof. Lockemann

Requirements = services

Well ... what is a service?

Our design hypothesis

Classical DBMS as our testbed

... and newer DBMS

From analysis to construction

Layers and components

The hypothesis under stress: components

Tier-architectures

Conclusion
BTW03
Shared resources and services
‹#›
business
process
service client
work unit 1
service
provider
resource manager 1
work unit 1
work unit 2
work unit 3
resource manager 2
work unit 2
work unit 4
resource manager 3
work unit 3
work unit 5
information
process 1
resource manager 4
work unit 4
information
process 2
© 2003 IPD, Prof. Lockemann
BTW03
What’s a service?
‹#›
service client
work unit
work unit
requirements
service level agreement
service = obligation
competence
resource manager
Service design:
service provider
 Determine the competences
needed by a broad clientele
 Settle which obligations
work unit
work unit
(responsibilities) to accept
© 2003 IPD, Prof. Lockemann
BTW03
What’s in a service?
‹#›
service client
work unit
work unit
The core:
Functionality
Qualities of
service:
Ubiquity
Durability
Interpretability
Robustness
Security
Performance
Scalability
service = obligation
resource manager
service provider
work unit
© 2003 IPD, Prof. Lockemann
work unit
BTW03
Characterization of a service
‹#›
The core:
Functionality: Collection of functions
Qualities of service:
 Ubiquity: Unrestricted access in space (data comm.)
 Durability: Unlimited access in time (data storage)
 Common Interpretability in space and time: Consistency as
best-effort
 Robustness: Guarantees under all circumstances: failure
resilience, conflict resilience, function persistence
 Security: No effects other than those guaranteed
 Performance: Service level at cost, e.g., throughput,
response time
 Scalability: Guaranteed service level under growth
© 2003 IPD, Prof. Lockemann
BTW03
The design goal: service hierarchies
‹#›
The basics of architectural design: divide-and-conquer
higher-level responsibility
service
functionality
service
functionality
qualities
qualities
service
functionality
qualities
service
functionality
qualities
lower-level responsibilities
© 2003 IPD, Prof. Lockemann
BTW03
Our design hypothesis
‹#›
1. Functional decomposition
higher-level responsibility
service
functionality
qualities
decomposition:
divide higher-level
responsibility
service
?
functionality
qualities
composition:
assemble higherlevel responsibility
service
?
functionality
qualities
service
?
functionality
qualities
lower-level responsibilities
© 2003 IPD, Prof. Lockemann
BTW03
Our design hypothesis
‹#›
1. Functional decomposition
2. Propagation of service qualities
higher-level responsibility
service
functionality
qualities
Partial control:
shared responsibility,
partial propagation
service
?
functionality
qualities
Exclusive control:
sole responsibility,
no propagation
Complete delegation:
full propagation
service
?
functionality
qualities
service
?
functionality
qualities
lower-level responsibilities
© 2003 IPD, Prof. Lockemann
BTW03
Our design hypothesis
1. Functional decomposition
2. Propagation of service qualities
3. Priority of service qualities
higher-level responsibility
service
functionality
qualities
‹#›
Exclusive control:
sole responsibility,
no propagation
Partial control:
shared responsibility,
partial propagation
Complete delegation:
full propagation
Choose one as the primary quality
Refine decomposition
Consider others as orthogonal
service
service
?
functionality
qualities
?
functionality
qualities
service
?
functionality
qualities
lower-level responsibilities
© 2003 IPD, Prof. Lockemann
BTW03
Relational DBMS as our testbed
‹#›

Functional decomposition


Propagation of service qualities


Relational functionality as the service.
QoS to be considered: durability, consistency, robustness,
performance, scalability.
Priority of service qualities

Durability requires non-volatile storage medium: Slow
magnetic disk as the physical bottleneck.

Thesis 1: Performance is primary QoS.
Question: Are the
remaining QoS orthogonal?
© 2003 IPD, Prof. Lockemann
Thesis 2: Observe performance
on all levels  partial control
BTW03
Performance as a shared responsibility
‹#›
Data model
more expressive
data model
Data model
mapping
less expressive
data model
data model Di
Data
staging wider usage
context
access profile
resource manager i
data model Di-1
narrower
usage context
Performance
© 2003 IPD, Prof. Lockemann
BTW03
DBMS reference architecture
Data model
Data types:
Sets of records
Operators:
Set operators
Data types:
Records and sets of records
Operators:
Record operators
Data types:
Lists, Trees, Hash tables,...
Operators:
Lists: seq. navigation
Trees: seq. navigation, key search
Hash tables: key search
© 2003 IPD, Prof. Lockemann
‹#›
Data staging
Static data structure
External data model
Data rearrangement
Query processing
Internal data model
Management of sets of records
Assignment of physical data structs
Access density
Access patterns
Physical data structures
BTW03
DBMS reference architecture
Data model
Data types:
Sets of records
Operators:
Set operators
Data types:
Records and sets of records
Operators:
Record operators
Data types:
Lists, Trees, Hash tables,...
Operators:
Lists: seq. navigation
Trees: seq. navigation, key search
Hash tables: key search
Data types:
Page = fixed number of Bytes
Segment = variable number of pages
Operators:
Request/release of pages
Create/open/close of segments
Data types:
Block = fixed number of Bytes
File = variable number of blocks
Operators:
Create/open/close of files
Read/write of blocks
‹#›
Data staging
Static data structure
External data model
Data rearrangement
Query processing
Internal data model
Management of sets of records
Assignment of physical data structs
Access density
Access patterns
Physical data structures
Pages and segments
Segment and buffer management
Mapping pages to blocks
Blocks and files
File management
Parameter control
Device interface
Timely provision of data in
main memory
Transparency of peripheral
storage
Physical proximity
Storage structure
Device I/O
© 2003 IPD, Prof. Lockemann
BTW03
DBMS reference architecture
Data model
Data types:
Sets of records
Operators:
Set operators
Data types:
Records and sets of records
Operators:
Record operators
Data types:
Lists, Trees, Hash tables,...
Operators:
Lists: seq. navigation
Trees: seq. navigation, key search
Hash tables: key search
Data types:
Page = fixed number of Bytes
Segment = variable number of pages
Operators:
Request/release of pages
Create/open/close of segments
Data types:
Block = fixed number of Bytes
File = variable number of blocks
Operators:
Create/open/close of files
Read/write of blocks
‹#›
Data staging
Static data structure
External data model
Data rearrangement
Query processing
Internal data model
Management of sets of records
Assignment of physical data structs
Access density
Access patterns
Physical data structures
Implementation on pages
Pages and segments
Segment and buffer management
Mapping pages to blocks
Blocks and files
File management
Parameter control
Device interface
Record clustering
Timely provision of data in
main memory
Transparency of peripheral
storage
Physical proximity
Storage structure
Device I/O
© 2003 IPD, Prof. Lockemann
BTW03
Relational DBMS as our testbed
‹#›

Functional decomposition


Propagation of service qualities


Relational functionality as the service.
QoS to be considered: durability, consistency, robustness,
performance, scalability.
Priority of service qualities

Durability requires non-volatile storage medium: Slow
magnetic disk as the physical bottleneck.

Thesis 1: Performance is primary QoS.
Question: Are the
remaining QoS orthogonal?
© 2003 IPD, Prof. Lockemann
Thesis 2: Observe performance
on all levels  partial control
BTW03
The remaining qualities
consistency
robustness
durability
‹#›
logical data model
data rearrangement
query translation and optimization
internal data model
management of sets of records
assignment of physical data structs
metadata model
metadata management
physical data structures
implementation on pages
transaction management
segment management
archive management
scheduling
logging
recovery
mapping pages to blocks
buffer management
backup
long-range storage
file management
parameter control
device interface
© 2003 IPD, Prof. Lockemann
BTW03
Semistructured databases (XML)
different data model
less regularity
tree navigation as access
profile
text orientation
performance, performance, ...
 More difficult decomposition!
‹#›
XML structures
structural mapping
query translation and optimization
assignment of physical data structs
to subtrees and media fields
physical data structures
physical data structures
physical data structures
index implementation
subtree implementations
media data to block clusters
segment management
mapping pages to blocks
buffer management
file management
parameter control
Relational front-ends
Native systems
© 2003 IPD, Prof. Lockemann
device interface
BTW03
Construction: What if …
‹#›

Functional decomposition


Propagation of service qualities


Relational functionality as the service.
QoS to be considered: durability, consistency, robustness,
performance, scalability.
Priority of service qualities

Durability requires non-volatile storage medium: Slow
magnetic disk as the physical bottleneck.

Thesis 1: Performance is primary QoS.
Privacy
Motivation: VLDB2002 paper on
Hippocratic databases by R. Agrawal et al.
QoS of purpose
© 2003 IPD, Prof. Lockemann
BTW03
Hippocratic databases: A new try
sets of records
query graphs
purpose descriptions
sets of records with
identical purpose
record-oriented access
data records and
main storage blocks
block-oriented access
The price of privacy
is performance!
© 2003 IPD, Prof. Lockemann
logical data model
query processing
purpose bound data model
query graph transformation with
propagation of query and database
purposes
Database purposes
(rules,
authorizations)
secure internal data model
implementation of physical
data structures for sets and indexes,
operator implementations
secure buffers
protected cache management,
placement of records in segments +
pages, extraction of records from pages
traditional storage engine
Purpose-restricted visibility
sets of records
descriptive queries
purpose descriptions
‹#›
(query, query purpose)
Firewall
Performance
Full visibility
Functionalities (data model)
BTW03
Construction: What if …
‹#›

Functional decomposition


Propagation of service qualities


Relational functionality as the service.
QoS to be considered: durability, consistency, robustness,
performance, scalability.
Priority of service qualities

Durability requires non-volatile storage medium: Slow
magnetic disk as the physical bottleneck.

Thesis 1: Performance is primary QoS.
Consistency
Motivation: Heavy use of constraints to
make the databases a closer model of the
real world
© 2003 IPD, Prof. Lockemann
BTW03
Incorruptible databases
queries, constraints
‹#›
constrained logical data model
routing
compile services
deductive processing of constraint sets into
inference modules and relational queries
just-in-time services
deductive processing of queries using the
inference modules
relational services
application of augmented relational
operators to cached database sections
relational data model
query translation and optimization
operator mapping
physical data structures
implementation on pages
traditional storage engine
© 2003 IPD, Prof. Lockemann
BTW03
From service hierarchy to an architecture
‹#›
component architecture
component 1
layered architecture
service
functionality
qualities
loose coupling
service
functionality
qualities
component 2
© 2003 IPD, Prof. Lockemann
layer 1
close coupling
service
functionality
qualities
service
functionality
qualities
layer 2
BTW03
Coupling, layers, components
‹#›
Candidate criteria for components :

Adjacent services share no resources  loose coupling

No shared responsibilities  loose coupling

Partial control, but by different technical means  loose
coupling

Low traffic density  loose coupling

Broad applicability of a service
Otherwise choose layers.
Actual decision a compromise between several criteria.
© 2003 IPD, Prof. Lockemann
BTW03
Applying the criteria
‹#›
Query engine
logical data model
data rearrangement
query translation and optimization
internal data model
management of sets of records
assignment of physical data structs
?
metadata model
metadata management
physical data structures
implementation on pages
?
scheduling
logging
recovery
Storage
engine
transaction management
?
segment management
archive management
mapping pages to blocks
buffer management
backup
long-range storage
OS
file management
parameter control
device interface
© 2003 IPD, Prof. Lockemann
BTW03
What if components are already given?
‹#›

Much more limited design space!

Hypothetical design hypothesis:
1.
Assign service qualities to each component.
2.
If the component can be influenced, develop it according to
the earlier design hypothesis. local optimum!
3.
For each quality shared between adjacent components and
arranged in order of priority, increase by technical means
the strength of the coupling.
4.
Re-evaluate and adjust the adjacent components in the light
of the coupling technique.
© 2003 IPD, Prof. Lockemann
BTW03
Imposed: 4-tier architecture
‹#›
Application
Presentation
Client
Client
WWW
Server
...
...
Client
WWW
Server
Middleware
Business logic
Resources
© 2003 IPD, Prof. Lockemann
Application
Server
...
Application
Server
Database
Server
...
other
Servers
BTW03
Unconventional idea:
multidimensional architectures
file
management
segment
management
physical data
structs.
internal data
model
logical data
model
middleware
© 2003 IPD, Prof. Lockemann
‹#›
client
middleware
transport
transport
network
network
data link
data link
physical layer
physical layer
BTW03
Performance, performance … and data staging
‹#›
Application
Presentation
Client
Client
WWW
Server
...
...
Client
WWW
Server
Middleware
Business logic
Resources
Application
Server
...
Application
Server
Database
Server
...
other
Servers
Strengthen the coupling for better performance 
data staging
© 2003 IPD, Prof. Lockemann
BTW03
Data staging = caching
‹#›
Client
Cache
WWW
Server
Cache
Application
Server
Cache
Database
Server
© 2003 IPD, Prof. Lockemann
Middleware
Separate component: Non-intrusive
but high communication overhead
Integration
 into middleware: middleware
service, lesser communication
overhead, general-purpose
 into server (which?): intrusive but
tailored to the needs
Migration to the edge
 to middleware: added middleware
service, lesser communication
overhead, general-purpose
 to server (which?): non-intrusive
tailored to the needs, but overhead
BTW03
What about the other qualities?
‹#›
Client
Consistency: Data replication 
Middleware
 Distributed transactions (weakens autonomy)
 Cache invalidation/coherency
Cache
WWW
Server
Cache
Application
Server
Robustness:
 Distributed transactions (weakens autonomy)
 E-commerce qualities, e.g., non-repudiation,
irrevocability
Privacy/purpose: Chain of firewalls?
Cache

Database
Server

© 2003 IPD, Prof. Lockemann
More interdependence / less orthogonality
between QoS, hence optimum more difficult
to find?
More design iterations?
BTW03
Conclusions
‹#›

Experienced designers don’t need a design methodology –
they do it right by common sense … or do they?

But it might help the novice designer.
Services is customer-orientation!
Service qualities act as the guiding principle.




Choice of priorities determines the result.
… and finally: Systematical exploration of the design
space!
© 2003 IPD, Prof. Lockemann
BTW03