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.
Peer-To-Peer Architectures, Web Services, Component–based Software Engineering, Component Orchestration, Semantic Web.
Enterprise application integration is one of the most challenging issues of
Internet computing. Several technologies have been developed to face this
problem such as OMG’s CORBA, Microsoft’s COM/COM+ and Sun’s 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 . Most platforms for Web services development and deployment (i.e. Microsoft’s .Net and IBM’s 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. 
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.
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.
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.
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  and iCal Hybrid-RDF  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.
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.
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