Thoughs on “An Architecture for a Service OrientedPeer-to-Peer System (SOPPS)”

I’ll just give some interesting excerpts related to P2P service discovery.


“It is based on p2p structures and offers a generic support of services as well as supply mechanisms to enable market management of those services offered”

“The SOPPS architecture needs to support completely different services, including management of content and other resources. Hence, mechanisms such as service fusion, i.e. the combination of existing services to create new, value-added services, and service description are required.”

“Peers are defined as nodes connected to a network, running the respective SOPPS software. SOPPS consists of peers communicating over a network in order to provide or use services.”

SOPPS architecture is based on 3 models:

  • Use model: a service is the provisioning of resources or the execution of tasks of one or more (temporarily provider) peers on behalf of one or more (temporarily user) peers. On the corresponding peer, it invokes functionality to discover an appropriate service and to determine and contact one or more provider peers offering that particular service.
  • Network model: abstracts the Internet into a overlay model
  • Peer model: Each peer has a number of local resources available at the bottom layer. These resources consist of hardware and software resources and can be used either for providing services to other peers or for support of the Core Functionality.

In order to access a service, the following steps need to be performed:

  • Service search phase: user creates a service description describing the content and his peer sends out a service request containing this description to other peers. This request is forwarded by the peers according to a search protocol.
  • Service negotiation phase: After a user has found one or several possible services he enters a negotiation with their providers to define the exact terms of service usage. This includes the fixing of parameters, e.g., the format the content will be encoded in, the data rate for sending the content, the price the user might have to pay for the service.
  • Service usage phase: the user can start using the service. Especially, this includes the remote invocation of methods offered by services during an initialization phase.
  • Application of rules: Throughout all the processes described above the rules management component watches over the fulfillment of previously defined rules.


Interesting high level view on the architecture. No technical details or solutions are given in the paper.

Paper [pdf]