small logo PRACTICAL ARCHITECTURAL APPROACH FOR COMPOSING EGOCENTRIC TRUST

subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link
subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link
subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link
subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link
subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link
subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link
subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link
subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link

The PACE Project

Peer Architecture in PACE

We have identified four functionalities intrinsic to every peer: Communication, Information, Trust and Application. Communication handles the interaction with other peers in the system and is responsible for transmitting and receiving messages. Information is responsible for storing all data, including application and trust-related. Trust is responsible for computing trust values of receiving messages and peers in the system. Application houses application-specific functionality.

PACE is based on the C2 style. C2 is a layered event-based architectural style that uses requests and notifications for communication between components. C2 imposes visibility rules - components on top are not aware of components below whereas components below are aware of components above them. The architecture of a peer in the PACE style is explained below as well as illustrated in the diagram below.

The Communication layer is responsible for performing data collection and transmitting data to other external peers. PACE requires that all external communication must be performed through this layer. However, since the activity of data collection does not depend upon data storage or analysis, this layer can reside at the top of a C2-based architecture. Externally received data can then be sent as notifications and data to be sent can be treated as requests.

All notifications emitted from the Communication layer and all data must be stored within the Information layer. Data may be selectively queried, updated, and deleted from this layer. The next layer is the Trust layer which is responsible for evaluating the received messages and updating the Information layer with the results of these evaluations. Since the Trust layer depends on internal data for its evaluations, it must be below the Information layer due to the C2 visibility rules.

While the layers described above are generic and may be implemented in an application-independent fashion, the Application layer is domain-specific. It is responsible for controlling the local behavior of the peer and can build upon the services provided by the generic layers. Therefore, an application developer is responsible primarily for implementing the Application layer. Thus, the arrangement of these layers is influenced both by their explicit interaction and C2’s visibility rules.

"Peer Architecture in PACE"

It should be pointed out that one of PACE's guiding principles is that it assumes implicit trust of components that constitute the internal architecture except for components that belong to the Communication layer. This is because Communication components are not responsible for validating the messages from other peers. So any notification sent by the Communication layer cannot be trusted. Therefore, these notifications require an explicit trust value. Since the Communication layer is the only one that can have external communications and is situated at the top of the architecture, it cannot, by definition, issue requests to other layers. Rather, requests can originate only from components below the Communication layer. Since these components are internal and thereby trusted, requests originating from them are implicitly trusted.

Consequently, components within the architecture treat requests and notifications differently. For example, the Information layer only allows requests to query, update or delete stored information, and prevents notifications from external peers received through the Communication layer to do the same.

A detailed description of components of each layer can be found in this paper.

Home | Institute for Software Research | UC Irvine | Contact Us |
This material is based upon work supported by the National Science Foundation under Grant No. 0205724, 0438996, and 0524033. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.