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

Registry is universal and provides non-semantic search Search retrieves lot of services (irrelevant results included) Which service to select ? How to select? The Problem.. Keyword match, taxonomy

Registries are categorized Select relevant registries (semantic filtering) Registry is domain specific and supports semantic search Select service(s) of interest Ontology The Solution..

SWAP: Semantic Web and Peer-to-Peer SWWS: Semantic Web and Web Services 3-Dimensions of fully enabled Service driven architectures [Staab and Maedche] I-D: Info Vs. Activity II-D: Centraized Vs Adhoc III-D: Implicit Vs Explicit semantics

1.No. of Peers = No. of Service providers 2. No central registry 3. Search may not be efficient 4. Peer community is huge 1.No. of Peers ≠ No. of Service providers 2.Registry at each peer 3.Search is better 4.Peer community is smaller Granularity of de-centralization Sparse: Each service provider is a peer Coarse: Each registry provider is a peer

Objectives  Using upper ontology to organize registries enabling logical (semantic) partitioning of all Web services based on domains  avoids replication, improves scalability  Supporting domain specific ontology in each registry  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]. how to link all registries ?  Success of business depends on speed, reacheability and locating right partners. Keyword-based search results too many irrelevant results. where to search ? how to search ?  Central problem in e-commerce interoperability is that no common basis for interaction between different business domains/environments how to handle interoperability issues ? Without making assumptions

Vision Interoperating Web Services registries High level query from user (optional Input/Output/Pre-post conditions/transactions/constraints) 2. List of relevant Web Services (discover) OR Composition plans of web processes Client This project is the first step towards this vision and focuses on building a scalable infrastructure Ontologies

Capabilities  Provides logical view of all types of registries Finding right service using full scale ontology support *  Networks all types of Web Service registries 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

……. Peer1 Peer2 Peer3 PeerK PeerN Reg1Reg2Reg3 ….. RegNRegK GWP Peer1..PeerN: Operator Peers Reg1..RegN: Registries GWP:Gateway Peer Each ‘Operator Peer’ manages a registry using Operator Peer Controller Model: Peer as a registry operator Operator Services, Domain Ontology Operator Services, Domain Ontologies Operator Services, Domain Ontology API Registries Ontology

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 a Web Service with annotation 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 New Registry Operator Gateway Peer 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 P2P network of Operator Peers Web Service Provider 1 2 3a 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 ……. 3b Domain Ontology, services

Querying for Web Service: I-Type 3 P2P network of Operator Peers REQUEST: for Registries Ontology 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 Client 3-2a 3-2b ……. Domain Ontology, services

Semantic Publication |Querying Map Inputs/Outputs to Concepts in Ontology and Publish in registry 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 !