1 / 27

Speed-R : Semantic Peer to Peer Environment for Diverse Web Services Registries

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

raja
Download Presentation

Speed-R : Semantic Peer to Peer Environment for Diverse Web Services Registries

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. Goal • Create a more scalable, high performance environment for Web Service Discovery • Scalability using P2P • High Performance using Semantic Annotation

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

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

  6. 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 SWAP: Semantic Web and Peer-to-Peer SWWS: Semantic Web and Web Services

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

  8. Objectives • Using upperontology 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

  9. 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

  10. Vision Interoperating Web Services registries. Client 1 2 Ontologies • 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 This project is the first step towards this vision and focuses on building a scalable infrastructure

  11. 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

  12. Layers in Speed-R

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

  14. 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.

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. Adding a Registry: I-Type 1 New Registry Operator 1 Gateway Peer 2 3 • REQUEST: for Registries Ontology • SEND: Registries Ontology • SUBMIT: Change in Registries Ontology • Registries Ontology updated at GWP, change is broadcasted • New Registry Operator joins P2P cloud and makes its registry available for access

  22. Publishing a Web Service: I-Type 2 Domain Ontology, services Web Service Provider 3b P2P network of Operator Peers 1 2 3b 3a • REQUEST: for Registries Ontology • SEND: Registries Ontology • Registry selection using Registries ontology and service publication • Without annotation (not I-Type 2) • Using annotationservice, Service ontology provided by OP …….

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

  24. Semantic Publication |Querying Create template, map it with Concepts in Ontology and Search Map Inputs/Outputs to Concepts in Ontology and Publish in registry

  25. 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

  26. 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

  27. Questions/Comments ? Thank you !

More Related