Speed-R: Semantic Peer to Peer
Environment for Diverse Web
Services Registries
Kaarthik Sivashanmugam
Kunal Verma
Ranjit Mulye
Zhenyu Zhong
Final Project
CSCI 8350: Enterprise Integration
Outline
Vision
 Why Speed-R ? Goals and Objectives
 Layers in Speed-R, Architecture model
 Environment and Technology Choices


P2P, Peer Roles, Registries Ontology, Domain Ontologies
Peer Interaction Protocols
 Present Status
 Future Work

Goal

Create a more scalable, high performance
environment for Web Service Discovery


Scalability using P2P
High Performance using Semantic Annotation
The Problem..
Registry is universal and
provides non-semantic search
Keyword match,
taxonomy
• Which service to select ?
• How to select?
Search retrieves lot of
services (irrelevant
results included)
The Solution..
Registries are categorized
Select relevant registries
(semantic filtering)
Ontology
Select service(s) of
interest
Registry is domain
specific and supports
semantic search
3-Dimensions of fully enabled Service
driven architectures [Staab and Maedche]
I-D: Info Vs. Activity
SWAP: Semantic Web and Peer-to-Peer
II-D: Centraized Vs Adhoc
SWWS: Semantic Web and Web Services
III-D: Implicit Vs Explicit
semantics
Granularity of de-centralization
Sparse: Each service provider is
a peer
1. No. of Peers = No. of Service
providers
Coarse: Each registry provider is
a peer
1. No. of Peers ≠ No. of Service
providers
2. No central registry
2. Registry at each peer
3. Search may not be efficient
3. Search is better
4. Peer community is huge
4. Peer community is smaller
Objectives

Using upper ontology to organize registries enabling logical
(semantic) partitioning of all Web services based on domains


Supporting domain specific ontology in each registry


avoids replication, improves scalability
enables use of semantically annotated Web services (utilizes semantic
annotation of Web services supported by related project SAWS)
Using P2P based decentralized infrastructure for better
interoperability and management of registries

Provides high degree of autonomy and decentralization of registry
architecture
Motivation (Why Speed-R ?)

Large number of registry/repository
implementations are anticipated [NIST report].


Success of business depends on speed, reacheability
and locating right partners. Keyword-based search
results too many irrelevant results.



how to link all registries ?
where to search ?
how to search ?
Without making assumptions
Central problem in e-commerce interoperability is
that no common basis for interaction between
different business domains/environments
 how to handle interoperability issues ?
Vision
Client
1
Interoperating Web
Services registries.
2
1. High level query from user
Ontologies
(optional Input/Output/Pre-post conditions/transactions/constraints)
2. List of relevant Web Services (discover) OR Composition plans
of web processes
This project is the first step towards this vision and focuses on
building a scalable infrastructure
Capabilities

Provides logical view of all types of registries


Networks all types of Web Service registries


Finding right service using full scale ontology support *
Achieving better interoperation without affecting their
specifications and autonomy
Semantic Service Publication and Querying

Semantic matching of services during discovery
* Using Protégé API
Layers in Speed-R
Model: Peer as a registry operator
Operator Services, Domain Ontology
PeerK
Peer1
Peer2
PeerN
Registries
Ontology
GWP
Peer3
Operator Services, Domain Ontologies
Operator Services, Domain Ontology
API
API
API
API
…..
Reg1
Reg2
Reg3
Peer1..PeerN: Operator Peers
API
…….
RegK
Reg1..RegN: Registries
RegN
GWP:Gateway Peer
Each ‘Operator Peer’ manages a registry using Operator Peer Controller
Description of the Architecture

Each Peer runs ‘Operator Peer’ to control semantic access to its
registry (direct registry access without support for semantic
discovery is allowed)

Peers support Domain Ontology and Operator Services (if
ontology is not used, no semantic discovery can be provided,
search defaults to keyword search)

Each Registry can be accessed using API, which is dependent
on its implementation and standard that it conforms to.

Registries Ontology (i.e., the upper ontology, only one for the
whole P2P cloud) is present in the P2P n/w. Any given time
Peers are aware of the updated Registries Ontology.
Why P2P?

Best suited for information sharing with a
scalable approach

To logically relate all registries maintaining their
autonomy

Decentralization of control

To avoid replication of registry objects

Efficient Querying
 Forwarding query to relevant registry

Deploying Operator Services effectively
Why Gateway Peer?
Gateway Peer: Entry point for Operator Peer/registry to join
P2P group

Updating Registries Ontology

Maintaining catalogue of all registries

Validity check & Assertions for change in Registries
Ontology*

Security measures (if any) during registry addition*
Could be a single Peer or tightly bound group* of peers
* Future work
Why Operator Peer?
Operator Peer: Member of P2P network and
each OP controls a registry

Keeping registries physically outside P2P network
(but logically inside P2P)

Optionally force Web service registrations to go
thru conformance checking with domain specific
ontology used with that registry

Deploying Operator Services
Why Registries Ontology?

To capture relationship among registries to use for semantic
interoperability

To allow new Registry operators to categorize their registry

To manage different registry types effectively.

To send queries to relevant registry in automated manner*
Registry Types [JP2P Unleashed]:
 Corporate Registries (Public/Non-public)
 CRM/ERP vendor Registries (Package of services)
 E-market places (Private/Open)
 Consortia Registries (Industry specific/Standards specific)
 etc..
* Future work
Domain Ontology

A Domain Ontology defines the concepts
and relationships in the domain of interest
that will be used for semantic annotation
of services (by the registry adopting that
ontology)

Used by Operator Services.


Eg. Semantic Service Publication/Querying
Not a mandatory requirement to join
Speed-R
Peer Interaction Protocols
 Registry addition by an Operator
 Operator Joins P2P cloud and initiates I-Type 1
 Publishing
annotation

a Web Service with
Client joins P2P cloud and initiates I-Type 2
 Semantic Querying for a Web Service
 Client joins P2P cloud and initiates I-Type 3
I-Type: Interaction Type
Adding a Registry: I-Type 1
New Registry Operator
1
Gateway Peer
2
3
1. REQUEST: for Registries Ontology
2. SEND: Registries Ontology
3. SUBMIT: Change in Registries Ontology
4. Registries Ontology updated at GWP, change is broadcasted
5. New Registry Operator joins P2P cloud and makes its registry
available for access
Publishing a Web Service: I-Type 2
Domain Ontology, services
Web Service Provider
1
3b
2
3a
P2P network of
Operator Peers
3b
1. REQUEST: for Registries Ontology
2. SEND: Registries Ontology
3. Registry selection using Registries
ontology and service publication
a) Without annotation (not I-Type 2)
b) Using annotation service, Service
ontology provided by OP
…….
Querying for Web Service: I-Type 3
Client
Domain Ontology, services
4-2
3-2a
1
P2P network of
Operator Peers
2
3-1
1. REQUEST: for Registries Ontology
3-2b
4-1
2. SEND: Registries Ontology
3-1. Registry selection using registries ontology and querying/browsing the
registry (not I-Type 3)
OR
3-2a. Registry selection using registries ontology and querying the Operator
peer
3-2b. Value added querying by operator peer using querying operator
service, Service ontology
4-1, 4-2. Query results
…….
Semantic Publication
Map Inputs/Outputs to Concepts in
Ontology and Publish in registry
|Querying
Create template, map it
with Concepts in
Ontology and Search
Status Quo

Basic P2P infrastructure is complete




JXTA peer network setup
Peer Roles implementation
Peer interaction protocols
Completed the implementation of adding
registries to peer group, WS Publishing and
blended querying/browsing$ of Web Services.



Ontology (Registries Ontology) based Registry selection for querying
GUI to aid WSDL-UDDI mapping
GUI to aid Ontology (Domain Ontology) based Service discovery
$ With and without semantics
Future of Speed-R

Integrating Speed-R with SAWS(MWSDI)

Using SOAP based communication among
peers

Security features, performance and reliability
issues in P2P network

and finally…support for high level queries for
service discovery and process composition
Questions/Comments ?
Thank you !