A Peer-To-Peer Platform Based on Semantic Web Services

A Peer-To-Peer Platform Based on Semantic Web Services

Francisco Ferreira
PUC-Rio
Rua Marques de So Vicente, 255
Edifcio Padre Leonel Franca, 10o andar
+55 (21) 2540-6915 ext. 110
chico@inf.puc-rio.br
Carlos Jos Pereira de Lucena
PUC-Rio
Rua Marques de So Vicente, 255
Edifcio Padre Leonel Franca, 10o andar
+55 (21) 2540-6915 ext. 103
lucena@inf.puc-rio.br
Daniel Schwabe
PUC-Rio
Rua Marques de So Vicente, 255
Edifcio RDC, 4o andar
+55 (21) 3114-1500 ext. 4356
schwabe@inf.puc-rio.br
 

ABSTRACT

In this poster, we describe Everyware, a platform for peer-to-peer applications based on Web services standards. It is conceived to support personal information sharing among peers using different devices and hardware infrastructure. Using open standards and a completely distributed approach, Everyware allows end users to deploy personal Web services easily without requiring configuration or administration efforts. Support for semantic tagging of Web services content is also provided. A real application based on Everyware is presented and related implementation issues are discussed.

Keywords

Peer-To-Peer Architectures, Web Services, Componentbased Software Engineering, Component Orchestration, Semantic Web.

1. INTRODUCTION

Enterprise application integration is one of the most challenging issues of Internet computing. Several technologies have been developed to face this problem such as OMGs CORBA, Microsofts COM/COM+ and Suns Enterprise JavaBeans. However, with the increasing computing power of different new devices for accessing the Internet, information is more distributed across heterogeneous sources, requiring new approaches to application integration.
Web services and its set of related standards are a promise for a completely platform-independent, open standards-based way of integrating enterprise components using existing software and hardware infrastructure [8]. Most platforms for Web services development and deployment (i.e. Microsofts .Net and IBMs Websphere) provide full integration of Web Services technologies with existing Web Servers and Application Servers. This allows developers and IT managers to make their components available as services that reuse the same hardware and software infrastructure. On the other hand, these platforms rely on application servers that are hard to manage and usually require specialized professionals for corrective maintenance. They also focus on the use of synchronous protocols (mainly HTTP), limiting scalability and computing power. Ordinary users who want to expose their personal data as Web services need simpler platforms with low memory and processor fingerprints and self-tuning, easy to configure capabilities
Semantic Web Services take the current proposal one step further, by adopting data description standards used in the Semantic Web to describe data exchanged by web services. [9]
 

2. EVERYWARE: A PLATFORM FOR P2P SEMANTIC WEB SERVICES

Everyware is a platform for distributed peer-to-peer Semantic Web services coordination. It allows the definition and composition of standard services available over the Internet.
Based on open standards, Everyware encompasses all of the parts needed to set up a peer-to-peer Web services network. There are two basic components: a lightweight semantic web services provider (Everyware LW) and a coordination infrastructure built on Java. Users can deploy personal Web services using the lightweight provider, with very limited configuration or administration effort.
The coordinator infrastructure is responsible for managing the execution of a process by coordinating several distributed web services. Although it could be installed on any peer, it is more straightforward to host it on a separate machine acting as a coordinator peer, providing high-availability and computing power,.
Ordinary peers (i.e. normal PCs or mobile phones) may provide services using only asynchronous protocols. Everyware lightweight server implements a transport layer based on SMTP. It works as a mail proxy for the actual mail server of the user, allowing requests to be sent to the same mail account used for common e-mail messages. Everyware processes service requests, while ordinary mail is forwarded to the mail client program. Synchronous support is also possible with the HTTP transport. Using SMTP and HTTP as standard transport protocols allows Everyware to tunnel through the firewalls and proxy servers, solving several problems typical of current peer-to-peer networks.
 

2.1 Architecture

Everyware uses a coordinator to execute a business process. This means that applications based on Everyware must implement a coordinator service that must be invoked in order to execute more complex business logic. Secondary coordinators can be used to provide performance and failover.
Any peer on the Everyware network can act as a coordinator, as it is implemented as a Web service that could be deployed using Everyware LW. Coordinators can be seen as a variation of synchronizers [1,5].
However, practical experience during the implementation of the calendar service showed that having a coordinator peer installed on a more powerful machine enhances system performance and failover. Although contrary to the more traditional P2P vision, this seems to be more effective since there are considerable performance differences among the devices involved.
 

2.2 Implementation and Design Issues

Everyware was entirely developed in Java. However, each component of the architecture can be developed in a different language, since communication is done using standard Web services protocols. Two components have been developed and are necessary to establish an Everyware peer network:
- A Lightweight stand-alone Web services provider. It can work with both synchronous (HTTP) and asynchronous (SMTP) modes. The second can check-up for mail requests in a fixed time interval or when a user checks for his/her mail. Everyware LW allows users to deploy any kind of Web service. Service can be Java classes, Enterprise JavaBeans or COM components. A semantic extension to the service provider that serializes/deserializes RDF and DAML documents and validates them against corresponding schemas.
- A Coordination API that can manage complex business processes. It allows the execution and coordination of long-running processes using both synchronous and asynchronous calls to services.
Semantic description and integration of data is supported by Everyware,, although current Web services standards offer little support for data description and representation. Data integration involves semantic tagging of content, allowing machines to process it automatically. Semantic Web [2,4,6] initiatives are the most obvious approaches to overcome these limitations. Ontologies that represent data from a specific domain can be used to solve inconsistencies and ambiguities on service requests and responses. Web services implementations based on Everyware are able to receive semantic information (i.e. DAML, RDF) as input, process it using one or more ontologies and send back a response that is also semantically tagged. Security support was not developed in the first version of Everyware. Every peer is trusted by default.
 

2.3 Case study: The EveryCal Calendar Service

To allow simple group calendar management, EveryCal has as a primary requirement the need to integrate different calendar systems such as Microsoft Outlook, IBM Lotus Notes and Macintosh iCal.
After defining a standard Calendar service that was able to setup appointments and to list already defined appointments, it was necessary to expose the standard interfaces provided by software vendors as calendar services. Each service was then deployed using the Everyware Lightweight SOAP Server, which is triggered by requests sent by SMTP or HTTP.
Each service uses semantic descriptions of data to allow automatic processing of service information. DAML Agenda [3] and iCal Hybrid-RDF [7] are currently supported. These descriptions in RDF and DAML can be used by software agents to perform inferences on calendar information.
Finally, a coordination calendar service was written to allow group calendar management. A majority consensus algorithm was used to set up group appointments. Applications may use the coordination framework to instantiate different coordination strategies, varying the algorithm used to setup appointments.
 

3. CONCLUSIONS AND FUTURE WORK

In this poster we presented Everyware, a platform for peer-to-peer Web services orchestration. It overcomes some limitations of most Web services platforms through the use of asynchronous protocols, lightweight components and semantic descriptions of service data.
However, a real-world peer network based on Everyware needs to contain some security mechanisms to avoid malicious behavior from untrustworthy peers. A digital signature infrastructure is being conceived to assure non-repudiation from any part. Message encryption also is expected to guarantee that third parties will not read messages.
 

4. ACKNOWLEDGEMENTS

This work was partially supported by scholarship from CAPES, and grants from CNPq. Special thanks to Frederico Guimaraes for the help on the calendar service implementation and to Gustavo Carvalho for his contribution to the coordinator architecture.

5. REFERENCES

  1. Agha, G. Actors: A Model of Concurrent Computation in Distributed Systems. MIT Press, Cambridge, MA, 1986.
  2. Berners-Lee, T., Hendler, J. and Lassila, O. The Semantic Web. Scientific American, May 2001.
  3. DAML Agenda. http://www.daml.org/2001/10/agenda/
  4. Dumbill, E., The Semantic Web: A Primer http://www.xml.com/pub/a/2000/11/01/semanticweb/
  5. Fr0Lund, S. Coordinating Distributed Objects. An Actor-Based Approach to Synchronization. MIT Press, 1996.
  6. Hendler, J., Agents and the Semantic Web http://www.csumd.edu/users/hendler/AgentWeb.html
  7. iCal Hybrid RDF Ontology http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf#
  8. Kreger, H. Web Services Conceptual Architecture. IBM Software Group White Paper, May 2001.
  9. McIlraith, S., Son, T.C. and Zeng, H. Semantic Web Services, IEEE Intelligent Systems. Special Issue on the Semantic Web. 16(2):46--53, March/April, 2001