After merger of Web Services and Semantic Web, Semantic Web Services (SWS) has received a lot of attention from researchers due to its ability of automatic Web Service discovery, execution and composition. Currently Web Service systems, which publish WSDL-described Web Services in UDDIs, cannot support SWS and UDDI has become the bottleneck of the whole system and would cause single node failure problems. Therefore, we propose a CAN-based P2P system to replace traditional UDDI, by distributing the functions of the UDDI among all the peers in the P2P network. At the same time, we design an ontology-based mechanism, guaranteeing every service would be registered on a specific peer in the CAN-based P2P network, according to the service's ontology. By replacing the UDDI, our system improves the scalability and stability of the SWS system, and realizes an efficient ontology-based discovery of Semantic Web Services.
a new WWW architecture that enhances content with formal semantics. That
means, content is made suitable for machine consumption, as opposed to
content that is only intended for human consumption. This will enable
automated agents to reason about Web content, and produce an intelligent
response to unforeseen situations. By describing Web Services in contents to
AI inspired markup languages, such as DARPA Agent Markup Language
(DAML) [
In recent years P2P computing [
In this paper, we propose three-layered novel system architecture to
support SWS and enhance the scalability and stability of Web Service
systems, which uses a Content Addressable Network-Based (CAN-Based)
Peer-to-Peer (P2P) network as its infrastructure, to replace traditional Web
Service systems. And the whole system is composed of P2P Infrastructure,
Web Service Distributor (WSD) and Web Service Translator (WST). To
publish Web Service Distributor Language for described Web Services, the
Web Services would be translated into OWL-Services (OWL-S) [
The rest of this paper is organized as follows: Section 2 presents the overview of our system and Section 3 describes the design and implementation of our system in detail. Section 4 surveys the related work. Section 5 draws the conclusions and describes our future work.
The framework of our proposed system is shown in Figure 1, which is
made up of three major components including Web Service Translator
(WST), Web Service Distributor (WSD) and CAN-Based P2P Network.
Web Service Translator interprets WSDL-described Web Services into
OWL-S. And Web Service Distributor is in charge of distributing OWL-S
among peers in the P2P network according to the ontology OWL-S contains.
The P2P network functions as the infrastructure of whole system, which
replaces the UDDI in traditional Web Service systems. When we publish a
Web Service, WST would translate the WSDL files of this Web Service into
OWL-S files, and the WSD extracts the ontology contained in OWL-S files
and allocates the Web Service to a specific peer in P2P infrastructure
according to this ontology. Due to the delicate design of our system, it is
easy to realize Web Service discovery efficiently. Because after obtaining
the ontology of requested Web Service, we can figure out the coordinates of
the Web Service and route to the specific peer quickly according to the CAN
[
For automatic registering and discovering services, we need semantic description but currently on the web, a large number of Web Services are available, which are described in syntactic description. Therefore in our system, we use translator, which translates WSDL files into OWL-S and provides semantically enriched description. It is important to note here that until now, this translation process is not functioning fully automatically.
After the translation from WSDL files to OWL-S, the OWL-S must be published for future operations. Traditionally, Web Services would be published on UDDI. On the other hand our proposed system uses P2P network to replace UDDI, in which every peer works as a small UDDI server and cooperates with other peers. The distributor is in-charge of mapping an OWL-described Web Service to a specific peer according to the ontology in the OWL files.
CAN-Based P2P Network
To replace UDDI with P2P network, we have to resolve the problems of choosing an appropriate protocol to organize the P2P infrastructure. It is also important that we must guarantee that a requested Web Service, which has been published, would be definitely discovered in a lookup process; on the other hand, this lookup process should be finished efficiently and quickly. Based on these requests, we choose CAN-Based P2P network as our infrastructure, because in CAN-Based P2P network, all the resources are well organized according to their coordinates and will be quickly located if their coordinates are available
The translator lies on the first layer of our system, which translates WSDL files into OWL-S files. OWL-S are ontology services which support simple as well as complex services. They enable us to automatically discover, invocate, compose, interoperate and monitor Web Services. OWLS descriptions are organized into three conceptual areas. These are Service Profiles, Process Models and Service Groundings. The Service Profiles tell what Web Service do? Service Profiles provide general description of a Web Service for advertising and discovering. They provide a way to describe Web Services offered by the providers and those needed by the requesters. Process Models present how the Web Services work? The Process Models have a number of inputs, outputs, preconditions and effects. Here inputs and outputs specify the data transformation produced by the process. Inputs represent the information, which is required for the execution of the process; outputs are the information that the process returns after its execution. Preconditions specify conditions that must be satisfied for the Web Services to be executed correctly. The effects describe the actual results as consequence of such execution. The Service Grounding specifies the details of how to access Web Services.
The Figure 2 shows the whole structure of translator, which provides an automatic or semi-automatic generation of OWL-S specifications starting from WSDL specifications. This translation generates OWL ontologies, which need to be mapped to existing ontologies in the Semantic Web to be useful for automatic process composition. The outputs of this translator provide the basic structure of an OWL-S description of Web Services and save a great deal of manpower.
WSDL Files
Translator Service Profile
Process Model Service Grounding
The translation is based on the following two principles. 1. A WSDL operation is equivalent to an atomic process of the OWL-S Process Model. This observation provides the basic mapping between WSDL and OWL-S. It is used for both the generation of the basic Process Model and for the generation of the Grounding. 2. OWL-S descriptions make use of OWL concepts to specify the content of inputs and outputs, while WSDL makes use of XML Schema data (XSD) types to specify inputs and outputs. Since the OWL-S Grounding that specifies the mapping between OWL-S Process Models and WSDL does not provide any mapping from concepts to types, therefore we are forced to assume a 1:1 correspondence between them. The second rule generates the basic data used by OWL-S.
Translator’s generating OWL-S description from WSDL description can be semi-automatic or manual due to information difference between OWL-S and WSDL-described Web Services. WSDL files provide only input and output information, while OWL-S files contain more than input and output information. Therefore the rest of the OWL-S profile, such as preconditions and effects, must be set manually 3.2
The Web Service Distributor lies in the second layer of our system, which distributes and publishes Web Services on the P2P infrastructure based on the ontology the Web Services contain.
O W L F i l e s W e b S e r v i c e D i s t r i b u t o r
F i l e P r o c e s s o r
O n t o l o g y L o c a l i z e r
L o c a t i o n
R e g i s t e r
Its input is in form of three OWL files, which are the outputs of the Web Service Translator. After extracting ontology from these OWL files, it figures out the specific location of the published Web Service in the P2P network. At last, according to this location information, Web Service Distributor would register the published Web Services on a specific peer.
As Figure 3 shows, Web Service Distributor is composed of three layers, including File Processor, Localizer and Register. File Processor takes charge of extracting ontology from OWL files and sends them to Localizer. Possibly, there may be a lot of ontology in OWL files. File Processor only takes out the ontology in the areas we concern. For example, in our proposed system, we use Input, Output, Precondition and Effects (hereafter IOPEs) to identify Web Services. So, the concerned areas are IOPE, which means File Processor only need to take out the ontology in IOPE. Based on the ontology input, Localizer works out the locations of Web Services according to some location algorithm. This paper, proposes a location algorithm, which establishes a coordinate space by numbering all the possible ontology and figure out the coordinates by mapping the input ontology with this coordinate space. We use an example to simplify our presentation. Figure 4 shows the service ontology and domain ontology. We provide reserve, check in and check out services, and the Room domain is composed of Single Room, Standard Room and Suite. Our location algorithm numbers all of these ontology and form a coordinate space, whose coordinates are 6-bits long. So, a “reserve Single Room” operation would be mapped to the coordinate of “100100” and a “check out suite” operation would be mapped to the coordinate of “001001”. For Web Services, different location algorithms would generate different locations. Because of our module design of Distributor, when applying a different location algorithm, we only need to modify the Localizer, not the whole Web Service Distributor.
Service reserve check in
check out 1 2 3
Single Room 4
Room Standard
Room 5
Suite 6
The bottom of Web Service Distributor is Register, which registers Web Services on specific peers with the help of the locations provided by Localizer. The Register is closely connected with the CAN-Based P2P of our system. Here, we resort to an example to present the whole function of Distributor. Suppose we use IOPE to identify Web Services, which mean we only care about the ontology in input, output, precondition and effect areas, and use the service ontology and domain ontology in Figure 4 when realizing mapping from ontology to coordinates. We also suppose that service’s input area contains the operation of “reserve Single Room”, service’s precondition area contains the operation of “check out Standard Room” and service’s effect area contains the operation of “check in Single Room”. Based on the areas we concern (IOPE), we build a three-dimension space, which is shown in Figure 5. According to the location algorithm mentioned above, we can get the coordinates of the service, (100100, 010010, 001100). After obtaining these coordinates, we can easily find out which peer this service should be registered on in the CAN-Based P2P Infrastructure according to CAN algorithm.
In fact, our system does not set up any constraint on the number and order of dimensions. Usually, the areas that users care about are far more than IOPE. Users can establish their own multi-dimension spaces at their wills.
010010
Y (P) 001100
Z (E)
After arranging all the Web Services according to our proposed architecture, Web Service discovery and composition can be realized easily. Referring to the example mentioned above, we use IOPE areas to identify Web Services, which means when requesting a Web Service we must provide the information about IOPE areas. With the help of Web Service Distributor, we can figure out the coordinates of the requested Web Service easily. Based on these coordinates, we can find out the right peer, which contains the requested Web Service. In addition, our system supports “vague” Web Service lookup. For example, the requester can only provide information about Input, Output and Effect areas. After the processing of Distributor, we achieve the X dimension and Z dimension coordinates of requested Web Service, which forms a vertical “line” in Figure 5. Although we still cannot figure out the peer containing requested Web Service. It is obvious that the requested Web Service must be located on one of the peers, whose spaces cover this vertical “line”. As a result, we do not broadcast the Web Service request, but only send the request to these peers, which reduce lookup area greatly. 3.3
We use CAN protocol to arrange our P2P infrastructure. Every peer in the infrastructure takes charge of a range of space of the whole multidimension space. Every Web Service would be registered on the peer, which covers the location of this Web Service.
10000 01100 01000 00000
Y
Current Web Service systems are based on “central” UDDI servers and
syntactic description of Web Services, which are fragile and unscalable, and
do not support Semantic Web Services. It is necessary to replace this UDDI
structure with a new one. P2P is such an infrastructure, which allows the
sharing of resources and services by direct interaction between equal nodes.
Until now, there are many P2P systems, such as Napster [
In fact, there have appeared some projects, which are using P2P network
to replace UDDI and support Semantic Web Service, such as METEOR-S
WSDI [
METEOR-S WSDI “uses an ontology-based approach to organize registries, enabling semantic classification of all Web Services based on domains”. The P2P infrastructure in METEOR-S WSDI project is not a pure P2P network, in which there is a Gateway Peer controlling access to the P2P network and some Auxiliary Peers providing Registries Ontology. These special peers are the performance bottleneck of the P2P infrastructure and make the whole system fragile facing malicious attacks.
As for service ontologies, there also exist some projects, which use
service ontologies to describe the semantics of Web Services. Ruoyan Zhang
et al. [
In this paper, we proposed a novel Semantic Web Service system, in which we resorted to CAN-Based infrastructure to replace UDDI and distribute Semantic Web Services among all the peers in P2P infrastructure based on the ontology contained in Semantic Web Services. Because there is no “central server”, our system avoids “single node failure” problem, which improves the stability of the whole system. And the P2P infrastructure also makes our system more scalable than traditional Web Service systems by distributing the system function among all the peers, not focusing on only one or a few servers. By abstracting ontology contained in SWS and allocating SWS according to the ontology, our system also provides a promising support for Semantic Web Service.
Now, we have established our SWS system and realized the publishing and discovery of SWS, while the whole life cycle of SWS includes not only Web Service publishing and discovery, but also automatic Web Service composition and execution. In the future, we would work on realizing autocomposition and auto-execution in our system.