Designing Dependable P2P Systems

1
Designing DependableP2P Systems

• James Walkerdine

2
Overview

• P2P ARCHITECT
• Architecting dependable P2P systems
• Oct02 - June04
• ATC, Engineering, UoA, Lancaster, Siceas, TOP AD
• PEPERS
• Architecting secure mobile P2P systems
• Jan06 - Dec08
• ATC, Engineering, City, Lancaster, SYMBIAN,
  Wackenhut, Phileleftheros

3
Background

• Bulk of P2P research/development has focused on
  the underlying technology
• Research on actual P2P system design is largely
  non-existent
• In reality, the two influence one another

4
System Dependability

• A systems dependability can be thought of as
  being its trustworthiness
• Multi-dimensional
• Availability, Reliability, Responsiveness,
  Safety, Security, etc
• Dependability can be influenced at all stages of
  system development
• Technical/company policy can impact on security
  requirements
• The choice of software architecture can impact on
  how these requirements are met
• The 3rd party encryption component that is to be
  used can further impact on how these are met
• etc

5
Overview of P2P ARCHITECT

• Develop methods and tools to support dependable
  P2P system development
• DISCOS method
• P2P Dependability knowledge base
• Application Reference Architectures
• UML notations
• Tool support
• Evaluated via user partner pilots

6
DISCOS

• Methodology that can assist in the
  specifying/designing of dependable P2P systems
• Spiral method consisting of four stages
• Iterative stages will be visited repeatedly
• Flexible can be adapted to suit different SE
  techniques (e.g, component based, service based,
  etc)
• Generic does not force the designer to use
  specific approaches or tools (e.g. viewpoint
  based, use-cases, etc)

7
(No Transcript)
8
Stages of the DISCOS method

• Establish business and dependability requirements
• What the system has to provide for the business
  and the operating requirements of the system
• Define system requirements
• The functionality provided by the system and the
  constraints on the system development and
  operation
• Propose system architecture
• Define an organisation for the different entities
  (e.g. objects, components, etc) that makes up the
  system
• Propose sub-system design
• Specify the entities that make up the design
  (interfaces, relationships, etc)
• The outcome of the method application is a system
  architecture/design and specification document

9
DependabilityKnowledgeBase
DISCOSTool
Application ReferenceArchitectures
P2P UMLNotations
DesignTool
10
Dependable P2P SystemDesign Issues

• P2P Dependability Properties
• Network evolution, legacy versions, connection
  bandwidth, intermittent peer connectivity, etc
• Logical network architectures (topology) and
  system dependability
• Choice of architecture can influence system
  dependability
• Semi-centralised
• Better for monitoring/controlling the network
• Critical systems, high security systems, etc
• Single point of failure
• Decentralised
• Good for aspects such as survivability, fault
  tolerance
• Distributed data storage, etc
• Bad for aspects such as monitoring or controlling
  the network
• Adopting an architectural driven design approach
• Logical and application architectures are central
  to P2P system design
• These issues can be important at all stages of a
  design

11
Method Breakdown and Scenario

• Distributed Box Office system
• Currently, individually managed Box Office
  systems scattered around a number of physical
  locations
• Utilise P2P technology to have a near real-time
  view of all Box Office systems
• Establish Business and Dependability Requirements
• Establish critical functionality and constraints
• Identify dependability requirements
• Consider how the different types of P2P
  architecture can meet these requirements
• Scenario
• The system should provide a distributed backup of
  all data on the Box Office PCs at least once a
  week
• The system should integrate with the companies
  existing systems
• It should be possible for all Box Office PCs to
  be monitored if required
• Information interchanges should be secure

12
Method Breakdown and Scenario

• Define System Requirements
• Requirements elicitation and analysis phase
• A viewpoint-based method has been used, but
  DISCOS is flexible enough to allow other methods
• Again, consider the effect the different types of
  P2P architecture can have on these requirements
  (and vice versa)
• Scenario
• Initial viewpoints and requirements are
  identified
• V Backup Manager
• R Data exchange monitoring the backup manager
  must be able to monitor the system as backup data
  is being exchanged between peers
• R Distributed maintenance the backup manager
  must be able to maintain all peers within the
  system, remotely

13
(No Transcript)
14
Method Breakdown and Scenario

• Propose System Architecture
• Architectures should be designed from an early
  stage for P2P systems
• Activities involved
• Selecting suitable logical network architectures
• Derive system functional capabilities
• Select application reference architectures
• Establish architectural model
• Identify sub-systems
• Allocate requirements to sub-systems
• Evaluate architecture
• Scenario
• A semi-centralised logical network architecture
  structure was deemed to be the most suitable
• The document management reference architecture
  was also found to be relevant
• Using these as input, an architectural model for
  the system is designed
• Sub-systems are identified

15
(No Transcript)
16
Document Manager Reference Architecture
17
(No Transcript)
18
(No Transcript)
19
Method Breakdown and Scenario

• Propose sub-system design
• Specifying the entities that make up the system
  architecture and its sub-systems
• Specifying interfaces, attributes, and
  functionality, etc
• Specifying the relationships that may exist
  between these entities
• Specifying the allocation of system requirements
  to entities
• Implementation details and re-use also need to be
  considered within the design (for example, the
  type of P2P technology that is to be used)
• Scenario
• Sub-systems are designed in detail
• Components, interfaces and ports identified
• Class definitions
• Attributes and methods defined

20
(No Transcript)
21
(No Transcript)
22
Output and Evaluation

• End results
• Requirements specification
• P2P system architecture and design
• Evaluation
• Two pilots were built using this method
• 2nd pilot being a system to support journalists
• In both cases the methodology and tools were well
  received
• Final word
• Industry likes its servers!
• At the moment a hybrid of P2P and Client/Server
  technologies is what industry is interested in

23
Overview of PEPERS

• Extends parts of P2P ARCHITECT
• Focus on supporting the development of secure
  mobile P2P systems
• Aim is to design a generic secure mobile P2P
  framework
• Comprised of a set of modules
• Designers select the relevant modules for use in
  their design
• An implementation of this will be developed for
  use with Symbian OS
• Evaluated with the development of user pilots

24
Modules and Reference Architectures
ReferenceArchitecture 1
ReferenceArchitecture 2
ReferenceArchitecture 3
25
Guidance Tool Support
Recommends
Product Security, Mobile and P2PRequirements
ReferenceArchitecture 1
Tool
Recommends
Logical NetworkArchitecture C
The tool also provides guidance on
instantiating the recommended architectures
26
Summary

• Overview of two EU projects
• P2P ARCHITECT
• PEPERS
• Focus on P2P system design and how to support
  this process