CS551 Object Oriented Middleware VII Advanced Topics Chap' 1012 of EDO

1
CS551 Object Oriented Middleware (VII)Advanced
Topics (Chap. 10-12 of EDO)

• Yugi Lee
• STB 555
• [phone]
• yugi_at_cstp.umkc.edu
• www.cstp.umkc.edu/yugi

2
Distributed Object Transaction (Chap 10)

• What happens if a failure occurs during
  modification of resources?
• Which operations have been completed or not (and
  have to be done again)? In which states will the
  resources be?
• Atomicity either performed completely or no
  modification, Start of a transaction/End of
  transaction
• Consistency Shared resources should always be
  consistent Transactions can be aborted if they
  cannot resolve them
• Isolation Each transaction accesses resources as
  if there were no other concurrent transactions.
• DurabilityA completed transaction is always
  persistent

3
Transaction Commands

• Begin
• Start a new transaction.
• Commit
• End a transaction.
• Store changes made during transaction.
• Make changes accessible to other transactions.
• Abort
• End a transaction.
• Undo all changes made during the transaction.

4
Flat Transactions
Flat Transaction
Crash
Flat Transaction
Flat Transaction
5
Central vs. Distributed Transactions

• Transactions in a Database
• Centralized
• DBMS controls transaction execution
• DBMS implements concurrency control
• Transaction processing transparent to application
  developers
• Problem occurs if
• Data kept in different databases or
• Distributed objects do not use a database
• Transaction processing not transparent to
  application developers

6
Concurrency Control (Chap 11)

• Components of distributed systems use shared
  resources concurrently
• Hardware Components, Operating system resources,
  Databases, Objects
• Resources may have to be accessed in mutual
  exclusion.
• Concurrent access and updates of resources may
  lead to
• lost updates (e.g. Cash withdrawal from ATM and
  concurren)
• inconsistent analysis (e.g. Funds transfer
  between accounts of a customer)

7
Two Phase Locking (2PL)

• The most popular concurrency control technique.
• RDBMSs (Oracle, Ingres, Sybase, DB/2, etc.)
• ODBMSs (O2, ObjectStore, Versant, etc.)
• Transaction Monitors (CICS, etc)
• Concurrent processes acquire locks on shared
  resources from lock manager.
• A lock is a token that indicates that a process
  accesses a resource in a particular mode (read
  and write).
• Locks are used to indicate to concurrent
  processes the current use of that resource.
• Guarantees serialisability

8
Lock Compatibility/Conflict

• Lock manager
• Grants locks depending on compatibility of
  acquisition request with modes of already granted
  locks.
• Compatibility defined in lock compatibility
  matrix.
• Locking conflict
• Lock requests cannot be granted if incompatible
  locks are held by concurrent processes
• To handle conflicts
• Force requesting process to wait until
  conflicting locks released
• Tell process or thread that lock cannot be
  granted.

9
Deadlocks

• 2PL may lead to processes waiting for each other
  to release locks.
• Deadlocks have to be detected by the lock
  manager.
• Deadlocks have to be resolved by aborting one or
  several of the processes involved.
• This requires to undo all the actions that these
  processes have done.
• Abort Transactions that consumed least processor
  time/with most dependencies
• Trade-off between degree of concurrency and
  locking overhead. Hierarchical locking as a
  compromise.

10
Transparency of Locking

• Who is acquiring locks?
• Concurrency control infrastructure
• Implementation of components
• Clients of components
• First option desireable but not always possible
• Infrastructure must manage all resources
• Infrastructure must know all resource accesses.
• Last option is undesirable and avoidable!

11
Two-Phase Commit Protocol

• Distributed system components involved in
  transactions can take role of
• Transactional Client
• Transactional Server
• Coordinator
• Two phases are needed
• Phase one Voting
• Phase two Completion.

12
Security (Chap 12)

• Security Attacks
• Encryption
• Higher-level Security Services
• Firewalls
• Authentication
• Access Control
• Non-Repudiation
• Security Auditing
• Security Services in Object-Oriented Middleware

13
Motivation Security Attack

• More vital/secret data handled by distributed
  components.
• Security protecting data stored in and
  transferred between distributed components from
  unauthorised access.
• Security is a non-functional requirement that
  cannot be added as a component but has to be
  built into all components.

14
Why are Distributed Systems Insecure?

• Distributed components rely on messages sent and
  received from network
• Public Networks are insecure!
• Is client component secure?
• Is client component who it claims to be?
• Are users of calling components really who they
  claim to be?

15
Effects of Insecurity

• Confidential Data may be stolen, e.g.
• corporate plans.
• new product designs.
• medical/financial records (e.g. Access
  bills....).
• Data may be altered, e.g.
• finances made to seem better than they are.
• results of tests, e.g. on drugs, altered.
• examination results amended (up or down).

16
Need for Security

• Loss of confidence above effects may reduce
  confidence in systems.
• Claims for damages legal developments may allow
  someone to sue if data on computer has not been
  guarded according to best practice.
• Loss of privacy data legally stored on a
  computer may well be private to the person
  concerned (e.g. medical/personnel) record.

17
Whats needed for secure requests?

• Firewalls Separating public and private networks
  
• Authentication Establishing security association
  between client server
• Access control Deciding whether principal may
  perform this operation
• Auditing Making the principal accountable for
  having requested the operation
• Encryption Protecting request and response from
  eavesdropping in transit
• Non-repudiation Proving that you have delivered
  a particular service