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 [8]. 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. [9]
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 [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.
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
architecture.