1 / 8

Integration of Semantic Web Services into Existing Web Services Infrastructures

This paper discusses the integration of Semantic Web Services (SWS) into existing web services infrastructures, exploring state-of-the-art technologies, usage scenarios, and the potential for integration. It examines the need for defining SWS architecture that can cope with evolving requirements and outlines the benefits and challenges of incorporating SWS into business applications. The paper also proposes a proxy-based approach for integrating SWS into existing environments, highlighting its advantages and disadvantages.

keith-schultz
Télécharger la présentation

Integration of Semantic Web Services into Existing Web Services Infrastructures

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. Towards an Integration of SWS into existing WS Infrastructures Christian DrummSAP AG

  2. Outline • State-of-the-art • SWS in business applications • Abstract SWS environment • Usage scenarios • Integration into existing infrastructures • Evaluation/Outlook

  3. State-of-the-art • Enterprise application platforms • Support the development/deployment of WS  SOAP, UDDI, WSDL • Workflow engines to support complex scenarios  BPEL4WS • Semantic Web Services • Next evolutionary step for WS • Several different architecture proposals • WSM* • OWL-S • No integration in business applications yet

  4. SWS in business applications • Two scenarios possible • Replacement of existing environments • Augmentation of existing environments • Second scenario much more likely as • Significant investments in current environments • Transition will take place gradually Define SWS architecture capable of coping with this requirements

  5. Abstract SWS environment • Important features • Separation of design-time and run-time • Semantic discovery • Data and process mediation Semantics Discover SWS Composition (design-time) Query ontologies Reasoning Discovery Mediation Execution (run-time) Deployment Perform mediation

  6. SWS usage scenarios • NO dynamic goal decomposition • Static usage scenario • Discovery only during design-time • Execution of static process script during run-time • Dynamic usage scenario • Goal-based discover during run-time • Mixed usage scenario • Somewhere between the two extremes

  7. Mixed usage scenarios with existing environments • Execution Environment • Simple WF engine • No “knowledge” of semantics • Proxy • Specific for one goal • Template based manual creation • Offers standard WS interface to execution environment Semantics Composition (design-time) Discovery Mediation Execution (BPEL4WS) Proxy WS

  8. Evaluation/Outlook • Advantages • Proxy enables SWS integration in existing environments • Only extensions of existing infrastructures necessary • Disadvantages • Proxy needs manual coding • SWS developed using proxy approach can’t be easily moved to a full SWS environment • Next Steps • Implementation of ideas in a real system

More Related