Architecture and Methods for Flexible Content Management in Peer-to-Peer Systems (eBook)

Dr. Udo Bartlang completed his doctoral thesis at the Faculty of Mathematics/Computer Science and Mechanical Engineering (Department of Informatics, Business Information Technology Unit), Clausthal University of Technology. The thesis was conducted at Siemens Corporate Technology, Munich.

Foreword 6
Danksagung 8
Abstract 9
Zusammenfassung 11
Contents 13
List of Figures 17
List of Tables 19
1 Introduction 20
1.1 Sample Scenarios of a Peer–to–Peer-Based Content Repository 22
1.1.1 Cross-Enterprise Business Collaboration 22
1.1.2 Intra-Enterprise Knowledge Management 25
1.2 Problem Statement and Research Challenges 29
1.2.1 Research Challenges Regarding the Content Model 30
1.2.2 Research Challenges Regarding the Content Repository Model 30
1.2.3 Research Challenges Regarding the Peer–to–Peer Model 32
1.3 Main Research Contributions of this Thesis 33
1.4 Publications 35
1.5 Outline 36
2 Background 38
2.1 Content Repositories 39
2.1.1 Content versus Data 41
2.1.2 Content Management 42
2.1.3 Content Management Systems 42
2.2 Distributed Systems, Algorithms, and Methods 44
2.2.1 Node Model 45
2.2.2 Communication Models 45
2.2.3 Failure Models 47
2.2.4 Consensus Algorithms 48
2.2.5 Fault-Tolerant State Machines 50
2.2.6 Group Communication 51
2.2.7 Dynamic Code Loading 51
2.3 Peer–to–Peer Systems 52
2.3.1 Centralised Peer–to–Peer Overlays 53
2.3.2 Unstructured Peer–to–Peer Overlays 54
2.3.3 Structured Peer–to–Peer Overlays 55
2.4 Distributed File Systems 56
2.4.1 Client–Server-Based Systems 57
2.4.2 Peer–to–Peer-Based Systems 59
2.5 Distributed Database Systems 61
2.5.1 Client–Server-Based Systems 62
2.5.2 Peer–to–Peer-Based Systems 64
2.6 Summary 65
3 Analysis of Content Repository Requirements in a Peer–to–Peer Case 67
3.1 Methodology of Analysis 67
3.2 Definition of Functional Building Blocks Using the Content Repository API for Java Technology 68
3.2.1 Content Repository Model 69
3.2.2 Content Repository Functions 71
3.2.3 Operational Scope 79
3.3 Dependence Relationships between Functional Building Blocks 80
3.3.1 Service Functionality Dependence 80
3.3.2 Influence Dependence 82
3.4 Suitability of Peer–to–Peer Overlays for Content Repository Functionality 83
3.4.1 Functional Content Repository Requirements for a Peer–to–Peer Approach 84
3.4.2 Non-Functional Content Repository Requirements for a Peer–to–Peer Approach 84
3.5 Summary 86
4 Design of a Generic Peer–to–Peer Content Repository System Architecture 88
4.1 Architectural Model 89
4.1.1 Logical View 89
4.1.2 Process View 89
4.1.3 Development View 90
4.1.4 Physical View 90
4.1.5 Scenarios 90
4.2 Generic Content Repository Architecture 91
4.2.1 Modular Decomposition 91
4.2.2 Persistent Storage Management 94
4.3 Generic Content Mapping 97
4.3.1 Item Naming Concept 97
4.3.2 Flexible Content Item Policies 100
4.4 Generic Peer Architecture 101
4.4.1 Internal Peer Structure 101
4.4.2 Dynamic Service Integration 104
4.5 Related Work 106
4.6 Summary 108
5 Methods for Flexible Content Repository Functions in Structured Peer–to–Peer Overlays 109
5.1 DhtFlex: A Distributed Algorithm for Flexible Atomic Data Management 109
5.2 System Context of DhtFlex 111
5.2.1 System Model 111
5.2.2 System Architecture 112
5.2.3 System Interface 116
5.3 Functionality of DhtFlex 116
5.3.1 Annotated Data Resources 117
5.3.2 Recast Case 117
5.3.3 Put Case 123
5.3.4 Get Case 125
5.3.5 Overlay Breakup Detection 127
5.4 Flexible Content Repository Functions 128
5.4.1 Content Mapping 128
5.4.2 Persistent Content Storage 130
5.5 Related Work 133
5.6 Summary 135
6 Methods for Flexible Content Repository Functions in Hybrid Peer–to–Peer Overlays 136
6.1 Reconfigurable Peer–to–Peer Service Groups 137
6.2 System Context of Peer–to–Peer Service Groups 139
6.2.1 System Model 139
6.2.2 System Architecture 140
6.2.3 System Interface 144
6.3 Functions of Peer–to–Peer Service Groups 145
6.3.1 Lifecycle Management 145
6.3.2 Decentralised Dynamic Code Loading of Service Functions 149
6.3.3 Consensus-Based Peer–to–Peer Group Communication 154
6.4 Flexible Content Repository Functions 163
6.4.1 Content Mapping 163
6.4.2 Persistent Content Storage 165
6.5 Related Work 168
6.6 Summary 171
7 Evaluation 173
7.1 Methodology 173
7.1.1 Architecture Evaluation 173
7.1.2 Method Evaluation 175
7.2 Peer–to–Peer Content Repository System Architecture 176
7.2.1 Architectural Styles 176
7.2.2 Quality Attributes 177
7.2.3 Scenarios 179
7.3 Methods for Flexible Content Repository Functions in Structured Peer–to–Peer Overlays 181
7.3.1 Reliability 181
7.3.2 Consistency 183
7.3.3 Reconfigurability 192
7.3.4 Scalability 192
7.3.5 Performance 196
7.4 Methods for Flexible Content Repository Functions in Hybrid Peer–to–Peer Overlays 201
7.4.1 Reliability 201
7.4.2 Consistency 202
7.4.3 Reconfigurability 203
7.4.4 Scalability 203
7.4.5 Performance 204
7.5 Summary 208
8 Conclusion and Outlook 210
8.1 Conclusion 210
8.2 Future Work 213
Bibliography 217

4 Design of a Generic Peer–to–Peer Content Repository System Architecture (S. 71-72)

The architecture of a software system may be regarded as its essential description to understand it. For instance, such understanding refers to the role of the major system components and, in particular, their coupling. A “software architecture shall de?ne a simple model of major components and their interactions, it may act as reusable, transferable abstraction of a software system” [55].

An architecture acts as a method to organize and structure a system. An important aim is to reduce the overall complexity to illustrate such system promoting the principles of decomposition and transparency, for example, as functionality is encapsulated within certain system parts, the details should be hidden, turning the focus rather on each part’s characteristics. Hence, architectural design has major impact on a system’s functionality, as it de?nes the degree of modularity a?ecting maintenance and reliability.

In this chapter, the architecture illustrates the responsibilities each system part has and how these parts interact to ful?l functional and non-functional requirements of peer–to–peer (P2P) based content repository functions, as presented in Chapter 3. One key to meet the imposed requirements is ?exibility. This motivates a generic architecture, which is suitable for di?erent communication and storage paradigms. Thereby, the term generality refers to “the degree to which a system or component performs a broad range of functions” [176]: accordingly, the generic architecture needs to support, for example, the introduced concepts of sessions and workspaces, and to integrate di?erent storage back-ends, the latter may comprise the integration of local systems, distributed client–server systems, or decentralised (structured or hybrid) P2P systems.

This chapter is structured as follows: Section 4.1 introduces the applied methodology to present the P2P-based content repository architecture. Then, Section 4.2 describes the generic architecture for the overall content repository system. It introduces a layer model to decompose the system into several parts of responsibility, and illustrates the management to cope with persistent storage. Next, Section 4.3 introduces a method for generic content mapping, which supports transparency at di?erent levels. It explains a concept to bundle items and introduces ?exible content data policies. Subsequently, Section 4.4 shows a generic peer architecture explaining a peer’s basic services and introducing a method to dynamically integrate additional peer services. Section 4.5 discusses related work.

Finally, Section 4.6 concludes and summarises this chapter. 4.1 Architectural Model Overall, a software architecture deals with the design and implementation of a software’s highlevel structure [108]: it is basically the result of composing an amount of architectural elements in some well-determined way to satisfy the major functional and non-functional requirements of the system. The methodology to present the P2P-based content repository architecture is oriented on the “4+1” view model of software architectures [108]: the organisation of the architecture’s description uses multiple, concurrent views—each one addressing a speci?c set of concerns. This allows to cope separately with the functional and non-functional imposed requirements— as introduced in Chapter 1.1 Figure 4.1 [108] illustrates the ?ve main views.