• Concurrency and Coordination
• Lack of global clock (Difficult to synchronize clocks)
• Components can fail independently, leaving other components still running

• Finance and eCommerce
• Information society
• Healthcare
• Transport and logistics
• Science
• Environment

• Pervasive networking
• Mobile commputing
• Cloud Computing

• Internet connects many computer networks of different types
• Devices can be connected at any time and any place
• Internet protocols used as common means of communication
• Enables services like WWW, email, etc
• Intranets

• Portable computing devices as part of distributed systems
• Access to resources while on the move
• Context-aware computing

• Share storage and computing power with networked computers
• Cluster computers provide single integrated storage or high-performace computing

• Synchronous or Asynchronous?
• Stateful or stateless?
• Can survive component failure?
• How does one application know that anotherone exists or is still running?

• Asynchronous messages are sent off without any confirmation that they have arrived
• Synchronous - sender does not proceed until receiver has received

• Server remembers where the file store is and which request it has outstanding, but doesn't remember previous communications. If it fails and recovers, some requests will be lost
• Client remembers which files it is waiting for

• Saves its entire state so that it can be restored in case of event failure

• Heterogeneity
• Openness
• Security
• Scalability
• Failure handling
• Concurrency
• Transparency

• Difference in networks, hardware, operating systems, programming languages, implementations, etc
• Internet protocols mask difference in networks
• Middleware provides progarmming abstraction and masks other differences

• Degree to which new resource-sharing components can be integrated
• Needs component interfaces to be published
• Needs uniform comunication mechanism

• Need to ensure confidentiality, integrity and availability of information
• Denial of service attacks
• Security of mobile code

• System must remain effective when number of users and resources increases significantly
• QUantity of resources needed should be O(Number of users)
• Algorithm performance should scale well with number of users and resources
• Distributed algorithms should be decentralised to avoid performance bottleneck

• Partial failures make handling failures difficult
• Need technique for detecting failures
• Need technique for masking failures
• Need technique for recovering from failures

Must provide concurrent access to shared resources, while maintaining data consistency 

(Needs synchronised accesss to obects representing shared resources)

• Separation of components must be hidden from application programmers
• Access: Local and remote resources accessed using identical operations
• Location: Resources accessed without knowledge of physical location
• Concurrency: No interface between concurrent processes
• Replication: Duplication of resources should not be visible
• Failure: Allow tasks to be completed in spite of failures of components
• Mobility: Resources can be moved without affecting operation
• Performance: Support system reconfiguration to improve performance
• Scaling: allow system to expand without changing structure or algorithms

• Communicating entities
• Communication paradigm
• Roles of specific entities
• How are entities mapped onto the physical distributed infrastructure

• Usually processes/threads (if supported by OS)
• Distributed objects (accessed via interfaces)
• Distributed Components
• Web services

• Low level communication
• Message passing, primitives, socket, multicast
• Remote invocation
• Indirect communication
• Decoupling between senders and receviers, both in time and space
• Includes one-to-many communication (group communication, publish-subscribe systems) and message queues (point-to-point)

• Most widely used
• Clients interact with servers managing resources
• Servers can also be clients
• Poor scalability

• Addresses the need to distribute shared resources among a large number of processes, in order to share computing and communication loads
• All processes play similar roles, no distinction between clients and servers
• Service provided jointly by the peers
• Communication pattern depends on application
• Data is shared between peers (for load distribution) and replicated (for resilence)

• Several servers implement a service
• Increases performance/resilence
• Either distribute service among servers or use replicated copies

• Cache used to store recently used data objects
• Web proxy servers increase availability and performance by providing a shared cache for client machines at site

• Increased performance as code is run locally (but also potential security threat.

E.g.

1. A client requests results in the downloading of applet code
2. Client interacts with applet instead of web server

• Distributed Objects (Java RMI, COBRA)
• Message queues (GMS, Websphere MQ)
• Publish-subscribe systems (JMS, COBRA event service)
• Web services
• Peer-to-peer

• Computation occurs within processes
• Processes interact by message passing, resulting in communication and coordination
• Need distributed algorithms (process steps include transmission of messages)
• Absence of global clock and delays in communication affect accuracy of coordination
• Useful to make explicit assumptions regarding timing, in order to evaluate specific algorithms 

• Describes Failures that can be Exhibited by process and communication channels
• Possible to construct reliable services from unreliable components, based on knowledge of the failure characteristics of process and channels
• Defines reliable communication
• Defines correct processes

• Omission failures - Process/Channel fails to perform intended actions
• Timing Failures: In synchronous systems
• Arbitrary (Byzantine) failures: Wrong process/channel behaviour

• Process/channel fails to perform intended actions
• e.g. process crashes, use timeouts to detect
• Communication omission failures: dropping messages due to lack of buffer space or network transmission errors, use message sequence numbers to detect

• In synchronous systems
• Time limits set on process excecution time and message delivery time

• (Byzantine) failures - wrong process/channel behaviour
• e.g. process steps are ommitted/additional steps taken/combination
• difficult to detect
• Arbitrary communication failures: corrupted messages/delivery of non-existing messages/duplicate messages
• Solutions include checksums/message sequence numbers to detect

• Hiding communication ommission failures through protocol that retransmits lost messages
• Hiding process crashes by replacing a crashed process and restoring its memory
• Use checksums to convert arbitrary communication failure (corrupted message) to omission

• Hiding failures
• Converting to a more acceptable type of failure

• Every message is eventually delivered
• Received message is identical to the one sent
• No message delivered twice