Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Applying Semantics to Service Oriented Architectures Oasis Symposium 2006 The Meaning of Interoperability 9-12 May, San Francisco Presenters: Adrian.

Similar presentations


Presentation on theme: "1 Applying Semantics to Service Oriented Architectures Oasis Symposium 2006 The Meaning of Interoperability 9-12 May, San Francisco Presenters: Adrian."— Presentation transcript:

1 1 Applying Semantics to Service Oriented Architectures Oasis Symposium 2006 The Meaning of Interoperability 9-12 May, San Francisco Presenters: Adrian Mocan Mick Kerrigan Michal Zaremba Special Thanks to: Emilia Cimpian Thomas Haselwanter Brahmananda Sapkota

2 OASIS Symposium 20062 The Aims of this Tutorial Introduce the aims & challenges of Semantic Web Services (SWS) - the WSMO approach Describe how SOA can be used with Semantic Web Services – WSMX Approach Semantic SOA enables interoperability

3 OASIS Symposium 20063 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability Web Service Modeling Toolkit (WSMT) Conclusions

4 OASIS Symposium 20064 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

5 OASIS Symposium 20065 Introduction to Semantic Web Services Introduction to Semantic Web Introduction to Web services Semantic Web Services

6 OASIS Symposium 20066 500 million user more than 3 billion pages Static WWW URI, HTML, HTTP Semantic Web and Web Services – The Vision

7 OASIS Symposium 20067 Static WWW URI, HTML, HTTP Serious Problems in information finding, information extracting, Information representing, information interpreting and information maintaining. Semantic Web RDF, RDF(S), OWL Semantic Web and Web Services

8 OASIS Symposium 20068 Static WWW URI, HTML, HTTP Bringing the computer back as a device for computation Semantic Web RDF, RDF(S), OWL Dynamic Web Services UDDI, WSDL, SOAP Semantic Web and Web Services – The Vision

9 OASIS Symposium 20069 Static WWW URI, HTML, HTTP Bringing the Web to its full potential Semantic Web RDF, RDF(S), OWL Dynamic Web Services UDDI, WSDL, SOAP Intelligent Web Services Semantic Web and Web Services – The Vision

10 OASIS Symposium 200610 Formal, explicit specification of a shared conceptualization commonly accepted understanding conceptual model of a domain (ontological theory) unambiguous terminology definitions machine-readability with computational semantics Ontology Definition

11 OASIS Symposium 200611 Ontology Example Concept conceptual entity of the domain Attribute property of a concept Relation relationship between concepts or properties Axiom coherent description between Concepts / Properties / Relations via logical expressions Person Student Professor Lecture isA – hierarchy (taxonomy) nameemail student nr. research field topic lecture nr. attends holds holds(Professor, Lecture) Lecture.topic Professor.researchField

12 OASIS Symposium 200612 Ontology Languages Requirements: –expressivity knowledge representation ontology theory support –reasoning support sound (unambiguous, decidable) support of reasoners / inference engines Semantic Web languages: –web compatibility –Existing W3C Recommendations: XML, RDF, OWL

13 OASIS Symposium 200613 Semantic Web Language Layer Cake

14 OASIS Symposium 200614 Web Services Web Services [Stencil Group] loosely coupled, reusable components encapsulate discrete functionality distributed programmatically accessible over standard internet protocols add new level of functionality on top of the current web

15 OASIS Symposium 200615 Using Web Services

16 OASIS Symposium 200616 Using Web Services

17 OASIS Symposium 200617 Lack of SWS standards Current technology does not allow realization of any of the parts of the Web Service usage process: –Only syntactical standards available –Lack of fully developed semantic markup languages –Lack of semantically marked up content and services –Lack of semantically enhanced repositories –Lack of frameworks that facilitate discovery, composition and execution –Lack of tools and platforms that allow to semantically enrich current Web content

18 OASIS Symposium 200618 Semantic Web Services Define exhaustive description frameworks for describing Web Services and related aspects (Web Service Description Ontologies) Support ontologies as underlying data model to allow machine supported data interpretation (Semantic Web aspect) Define semantically driven technologies for automation of the Web Service usage process (Web Service aspect)

19 OASIS Symposium 200619 Semantic Web Services (2) Usage Process: Publication: Make available the description of the capabilities of a service Discovery: Locate different services suitable for a given task Selection: Choose the most appropriate services among the available ones Composition: Combine services to achieve a goal Mediation: Solve mismatches (in data or process) among the combined services Execution: Invoke services following programmatic conventions

20 OASIS Symposium 200620 Semantic Web Services (3) Usage Process – execution support Monitoring: Control the execution process Compensation: Provide transactional support and undo or mitigate unwanted effects Replacement: Facilitate the substitution of services by equivalent ones Auditing: Verify that service execution occurred in the expected way

21 OASIS Symposium 200621 Semantic Web Services = Semantic Web Technology + Web Service Technology Summary

22 OASIS Symposium 200622 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

23 OASIS Symposium 200623 Web Service Modeling Ontology (WSMO) A conceptual model for Semantic Web Services: –Ontology of core elements for Semantic Web Services –a formal description language (WSML) –execution environment (WSMX) … derived from and based on the Web Service Modeling Framework WSMF an European Semantic System Initiative –ESSI Cluster Working Group –joint European research and development initiative

24 OASIS Symposium 200624 A Conceptual Model for SWS A Formal Language for WSMO A Rule-based Language for SWS Execution Environment for WSMO WSMO Working Groups

25 OASIS Symposium 200625 WSMO Design Principles Web ComplianceOntology-Based Strict Decoupling Of Modeling Elements Centrality of Mediation Ontological Role Separation Description versus Implementation Execution Semantics WSMO

26 OASIS Symposium 200626 Objectives that a client wants to achieve by using Web Services Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: - Capability (functional) - Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities WSMO Top Level Notions

27 OASIS Symposium 200627 Non-Functional Properties Every WSMO elements is described by properties that contain relevant, non-functional aspects Dublin Core Metadata Set: –complete item description –used for resource management Versioning Information –evolution support Quality of Service Information –availability, stability Other –Owner, financial

28 OASIS Symposium 200628 Dublin Core Metadata Contributor Coverage Creator Description Format Identifier Language Publisher Relation Rights Source Subject Title Type Quality of Service Accuracy NetworkRelatedQoS Performance Reliability Robustness Scalability Security Transactional Trust Other Financial Owner TypeOfMatch Version Non-Functional Properties List

29 OASIS Symposium 200629 WSMO Ontologies Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: - Capability (functional) - Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services

30 OASIS Symposium 200630 Ontology Usage & Principles Ontologies are used as the data model throughout WSMO –all WSMO element descriptions rely on ontologies –all data interchanged in Web Service usage are ontologies –Semantic information processing & ontology reasoning WSMO Ontology Language WSML –conceptual syntax for describing WSMO elements –logical language for axiomatic expressions (WSML Layering) WSMO Ontology Design –Modularization: import / re-using ontologies, modular approach for ontology design –De-Coupling: heterogeneity handled by OO Mediators

31 OASIS Symposium 200631 Ontology Specification Non functional properties (see before) Imported Ontologies importing existing ontologies where no heterogeneities arise Used mediators OO Mediators (ontology import with terminology mismatch handling) Ontology Elements: Concepts set of concepts that belong to the ontology, incl. Attributes set of attributes that belong to a concept Relations define interrelations between several concepts Functions special type of relation (unary range = return value) Instances set of instances that belong to the represented ontology Axioms axiomatic expressions in ontology (logical statement)

32 OASIS Symposium 200632 WSMO Web services Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: - Capability (functional) - Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services

33 OASIS Symposium 200633 Web service Implementation (not of interest in Web Service Description) Choreography --- Service Interfaces --- Capability functional description WS - Advertising of Web Service - Support for WS Discovery client-service interaction interface for consuming WS - External Visible Behavior - Communication Structure - Grounding realization of functionality by aggregating other Web Services - functional decomposition - WS composition Non-functional Properties DC + QoS + Version + financial - complete item description - quality aspects - Web Service Management WS Orchestration WSMO Web service description

34 OASIS Symposium 200634 Capability Specification Non functional properties Imported Ontologies Used mediators –OO Mediator: importing ontologies with mismatch resolution –WG Mediator: link to a Goal wherefore service is not usable a priori Pre-conditions –What a web service expects in order to be able to provide its service –Define conditions over the input. Assumptions –Conditions on the state of the world that has to hold before the Web Service can be executed Post-conditions –Describes the result of the WS in relation to the input, and conditions on it Effects –Conditions on the state of the world that hold after execution of the –Web Service (i.e. changes in the state of the world)

35 OASIS Symposium 200635 VTA Service Date Time Flight, Hotel Error Confirmation Hotel Service Flight Service Date, Time Hotel Error Date, Time Flight Error When the service is requested When the service requests Choreography & Orchestration VTA example: Choreography = how to interact with the service to consume its functionality Orchestration = how service functionality is achieved by aggregating other Web services Confirmation

36 OASIS Symposium 200636 Choreography Aspects Interface for consuming Web Service –External Visible Behavior those aspects of the workflow of a Web Service where Interaction is required described by workflow constructs: sequence, split, loop, parallel –Communication Structure messages sent and received their order (communicative behavior for service consumption) choreography related errors (e.g. input wrong, message timeout, etc.) –Grounding concrete communication technology for interaction –Formal Model reasoning on Web Service interfaces (service interoperability) allow mediation support on Web Service interfaces

37 OASIS Symposium 200637 -decomposition of service functionality -all service interaction via choreographies Control Structure for aggregation of other Web Services WS Web Service Business Logic 1 2 3 4 WS State in Orchestration Control Flow Data Flow Service Interaction Orchestration Aspects

38 OASIS Symposium 200638 Orchestration Aspects Service interfaces are concerned with service consumption and interaction Choreography and Orchestration as sub-concepts of Service Interface Common requirements for service interface description: –represent the dynamics of information interchange during service consumption and interaction –support ontologies as the underlying data model –appropriate communication technology for information interchange –sound formal model / semantics of service interface specifications in order to allow operations on them.

39 OASIS Symposium 200639 Ontologies as data model: - every resource description based on ontologies - every data element interchanged is ontology instance Formal description of service interfaces: - ASM-based approach - allows reasoning & mediation workflow constructs as basis for describing service interfaces: - workflow based process models for describing behavior - on basis of generic workflow constructs (e.g. van der Aalst) Choreography: - interaction of services / service and client - a choreography interface describes the behavior of a Web Service for client-service interaction for consuming the service Orchestration: - how the functionality of a Web Service is achieved by aggregating other Web Services - extends Choreography descriptions by control & data flow constructs between orchestrating WS and orchestrated WSs. Grounding: - making service interfaces executable - currently grounding to WSDL Conceptual models User language - based on UML2 activity diagrams - graphical Tool for Editing & Browsing Service Interface Description Choreography and Orchestration - Overview

40 OASIS Symposium 200640 WSMO Goals Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: - Capability (functional) - Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services

41 OASIS Symposium 200641 Goals Ontological De-coupling of Requester and Provider Goal-driven Approach –derived from AI rational agent approach –Requester formulates objective independently –Intelligent mechanisms detect suitable services for solving the Goal –allows re-use of Services for different purposes Usage of Goals within Semantic Web Services –A Requester, that is an agent (human or machine), defines a Goal to be resolved –Web Service Discovery detects suitable Web Services for solving the Goal automatically –Goal Resolution Management is realized in implementations

42 OASIS Symposium 200642 Goal Specification Non functional properties Imported Ontologies Used mediators –OO Mediators: importing ontologies with heterogeneity resolution –GG Mediator: Goal definition by reusing an already existing goal allows definition of Goal Ontologies Requested Capability –describes service functionality expected to resolve the objective –defined as capability description from the requester perspective Requested Interface –describes communication behaviour supported by the requester for consuming a Web Service (Choreography) –Restrictions / preferences on orchestrations of acceptable Web Services

43 OASIS Symposium 200643 WSMO Mediators Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: - Capability (functional) - Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services

44 OASIS Symposium 200644 Mediation Heterogeneity … –Mismatches on structural / semantic / conceptual / functional / level –Occur between different components that shall interoperate –Especially in distributed & open environments like the Internet Concept of Mediation (Wiederhold, 94): –Mediators as components that resolve mismatches –Declarative Approach: Semantic description of resources Intelligent mechanisms that resolve mismatches independent of content –Mediation cannot be fully automated (integration decision) Levels of Mediation within Semantic Web Services (WSMF): (1)Data Level: mediate heterogeneous Data Sources (2)Functional Level: mediate mismatches between Web Service/Goal and Web Service/Goals functionalities (3)Process/Protocol Level: mediate heterogeneous Business Processes/Communication Patterns Layers of Mediators –Specification Layer – WSMO Mediators –Implementation Layer – Levels of Mediation

45 OASIS Symposium 200645 WSMO Mediators Overview

46 OASIS Symposium 200646 WSMO Mediator uses a Mediation Service via Source Component Source Component Target Component 1.. n 1 Mediation Services - as a Goal - directly - optionally incl. Mediation Mediator Structure Specification layer Implementation layer

47 OASIS Symposium 200647 OO Mediator Mediation Service Train Connection Ontology (s1) Purchase Ontology (s2) Train Ticket Purchase Ontology Mediation Services Discovery Merging 2 ontologies OO Mediator - Example Goal: merge s1, s2 and s1.ticket subclassof s2.product

48 OASIS Symposium 200648 GG Mediator Mediation Service Source Goal Buy a ticket Target Goal Buy a Train Ticket postcondition: aTicket memberof trainticket GG Mediators Aim: –Support specification of Goals by re-using existing Goals –Allow definition of Goal Ontologies (collection of pre-defined Goals) –Terminology mismatches handled by OO Mediators Example: Goal Refinement

49 OASIS Symposium 200649 WG Mediators: –link a Web Service to a Goal and resolve occurring mismatches –match Web Service and Goals that do not match a priori –handle terminology mismatches between Web Services and Goals broader range of Goals solvable by a Web Service WW Mediators: –enable interoperability of heterogeneous Web Services support automated collaboration between Web Services –OO Mediators for terminology import with data level mediation –Protocol Mediation for establishing valid multi-party collaborations –Process Mediation for making Business Processes interoperable WG & WW Mediators

50 OASIS Symposium 200650 Data Level Mediation Scope –Solving terminological mismatches Related Aspects / Techniques: –Ontology Integration (Mapping, Merging, Alignment) –Data Lifting & Lowering –Transformation between Languages / Formalisms Terminology Mismatches Classification –Conceptualization Mismatches same domain concepts, but different conceptualization different levels of abstraction different ontological structure => resolution only includs human intervention –Explication Mismatches mismatches between: –T (Term used), D (definition of concepts), C (real world concept) => automated resolution partially possible

51 OASIS Symposium 200651 Functional Level Mediation Scope –Solving functional mismatches between goals and/or ws Related Aspects/Techniques –Discovery –Semantic Matchmaking Matchmaking Mismatches = G/WS X Exact MatchSubsumption MatchIntersection MatchNo MatchPlugIn Match

52 OASIS Symposium 200652 Process Level Mediation Scope –Resolves communication mismatches and establish behavior compatibility Related Aspects/Techniques –Data and control flow composition Process Mismatches –Signature terminology mismatches (need for data level mediation) –Communication/behavior mismatches

53 OASIS Symposium 200653 WSMO Mediators and Mediation Levels ooMediator –Data Level Mediation ggMediator –Data Level Mediation –Functional Level Mediation Ex: wgMediator –Data Level Mediation –Functional Level Mediation –Process Level Mediation wwMediator –Data Level Mediation –Functional Level Mediation –Process Level Mediation internal business logic of Web Service (not of interest in Service Interface Description) internal business logic of Web Service (not of interest in Service Interface Description) WW Mediator

54 OASIS Symposium 200654 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

55 OASIS Symposium 2006 Key Enablers Information Technology versus Mission of Organizations People (e.g., organization structure, human capital) Business Processes IT (e.g., systems) Physical Infrastructure (e.g., facilities, workplace environment) Goals Objectives Strategy selection Value Proposition development Long term vision alignment Critical success factors for customers and service offerings Specific definition functional performance Mission Strategies Capabilities

56 OASIS Symposium 200656 Existing Architectures do not scale Existing IT architectures cannot support changing needs Agility IT assets cannot be easily repositioned in response to changing requirements No solution for efficient intra- and inter- organization information sharing Decision cycles are unnecessarily lengthened by data stovepipes IT assets cannot be easily repositioned in response to changing requirements No solution for efficient intra- and inter- organization information sharing Decision cycles are unnecessarily lengthened by data stovepipes Process Heterogeneity Systems, organizations units and network of partners duplicate the same work Information stovepipes require point-to-point integrations that limit flexibility and create maintenance overhead More efforts spent connecting systems together than adding mission critical capabilities Systems, organizations units and network of partners duplicate the same work Information stovepipes require point-to-point integrations that limit flexibility and create maintenance overhead More efforts spent connecting systems together than adding mission critical capabilities Data Heterogeneity Difficult to determine what data means fosters duplicate applications and data Inability of applications to interoperate due to platform incompatibility Data used across an organization is often inconsistent and potentially inaccurate Difficult to determine what data means fosters duplicate applications and data Inability of applications to interoperate due to platform incompatibility Data used across an organization is often inconsistent and potentially inaccurate Costs Duplicate data entry and manual data reunion require extra man power Point-to-point integration shifts IT professionals towards repetitive employees to time consuming tasks Integrating data stovepipes is expensive and wasteful Operations and maintenance costs are a rising percentage of the budget Duplicate data entry and manual data reunion require extra man power Point-to-point integration shifts IT professionals towards repetitive employees to time consuming tasks Integrating data stovepipes is expensive and wasteful Operations and maintenance costs are a rising percentage of the budget No agility, processes redundant, lack of system interactions, and everything is very costly

57 OASIS Symposium 200657 SOA is an approach to organizing and using IT to match and combine needs with capabilities in support of the overall mission of an enterprise Capabilities performed by one for another to achieve a desired outcome Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem The fundamental organization of a system embodied in its capabilities, their interactions, and the environment Architecture Oriented Service A Solution – Service Oriented Architectures SOA - A paradigm that encourages organizations to re-think how their IT capabilities are organized

58 OASIS Symposium 200658 Traditional approach to software architecture Traditional approach to software architecture Analogy - traditional software architecture versus SOA No Agility to repair your car even for trivial tasks A Process that is duplicative and inefficient Costly to operate and maintain – keep many people Agility to repair cars quickly (next available mechanic takes care) A Process that is efficient Cost effective to operate and maintain Service-Oriented Architecture In garage every mechanic specialize only in one type of car so it does not matter what you want to repair you always have to wait for a mechanic who knows your type of car; if he/she is sick or on holiday you cannot repair your car at all You ask any mechanic in a garage to repair your car – model of your car does not matter Separate Specialist modelService-Oriented model Mechanic does job himself or asks other mechanics to take care of tasks he is not capable to do

59 OASIS Symposium 200659 SOA Benefits Agility Focus more on core competencies Creates a network of service requesters (consumers) and service providers (producers) Enable enterprises to be more agile and respond quickly to changing requirements Increase business flexibility through plug- and-play architecture and re-use of existing services Focus more on core competencies Creates a network of service requesters (consumers) and service providers (producers) Enable enterprises to be more agile and respond quickly to changing requirements Increase business flexibility through plug- and-play architecture and re-use of existing services Process Heterogeneity Allow interoperation with other systems without time consuming customization and point- to-point integration Ensure system change is not a constraint on business or mission change Facilitate integration with multiple solutions via open IT standards Allow interoperation with other systems without time consuming customization and point- to-point integration Ensure system change is not a constraint on business or mission change Facilitate integration with multiple solutions via open IT standards Data Heterogeneity Improve semantics of data exchanged during business process execution Maintain consistency of data across different systems Remain platform, language, and vendor independent to remove IT barriers for using best-of- breed software packages Improve semantics of data exchanged during business process execution Maintain consistency of data across different systems Remain platform, language, and vendor independent to remove IT barriers for using best-of- breed software packages Costs Leverage existing IT infrastructure Reduce costs of development of new functionalities by acquiring pre-built components/services Lower maintenance costs Leverage existing IT infrastructure Reduce costs of development of new functionalities by acquiring pre-built components/services Lower maintenance costs SOA allows to align IT with mission of the organization Better agility, no redundancy, system interactions, and reduces overall costs of system maintenance

60 OASIS Symposium 200660 SOA Design Principles Strong Decoupling & Strong Mediation –autonomous components with mediators for interoperability Interface vs. Implementation –distinguish interface (= description) from implementation (=program) Peer to Peer –interaction between equal partners (in terms of control)

61 OASIS Symposium 200661 Benefits of SOA Better reuse –Build new functionality (new execution semantics) on top of existing Business Services Well defined interfaces –Manage changes without affecting the Core System Easier Maintainability –Changes/Versions are not all-or-nothing Better Flexibility

62 OASIS Symposium 200662 Semantically Empowered Service-oriented Architectures (SESA) Currently, computer science is in a new period of abstraction. A generation ago we learnt to abstract from hardware and currently we learn to abstract from software in terms of SERVICE oriented architectures (SOA). It is the service that counts for a customer and not the specific software or hardware that is used to implement the service. In a later stage, we may even talk in terms of problem-oriented architectures (or more positively expressed in terms of problem-solving oriented architectures) because SOAs are biased towards the service provider and not towards the customer that has a problem that needs to be solved.

63 OASIS Symposium 200663 Semantically Empowered Service-oriented Architecture (SESA) Service-oriented architectures will become quickly the leading software paradigm However, SOAs will not scale without significant mechanization of –Service discovery, service adaptation, negotiation, service composition, service invocation, and service monitoring; and –Data and process mediation Therefore, machine processable semantics needs to be added to bring SOAs to their full potential Development of open standards (languages) and open source architectures and tools that add semantics to service descriptions

64 OASIS Symposium 200664 Semantic Web Services Infrastructure A service oriented architecture. Reference implementation of WSMO

65 OASIS Symposium 200665 User Service versus Platform Service in SWS Systems

66 OASIS Symposium 200666 Vertical and Horizontal Services Vertical services remain invisible to horizontal services, and during its execution, the horizontal services remain unaware that vertical services are executed together with them Vertical services invoke horizontal services, coordinating overall workflow, rather than horizontal service invoking the vertical

67 OASIS Symposium 200667 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

68 OASIS Symposium 200668 WSMX Introduction Software framework for runtime binding of service requesters and service providers WSMX interprets service requesters goal to – discover matching services – select (if desired) the service that best fits – provide mediation (if required) – make the service invocation Is based on the conceptual model provided by WSMO Has a formal execution semantics Service Oriented and event-based architecture –based on microkernel design using technologies as J2EE, Hibernate, Spring, JMX, etc.

69 OASIS Symposium 200669 WSMX Motivation Provide middleware glue for Semantic Web Services –Allow service providers focus on their business Provide a reference implementation for WSMO –Eat our own cake Provide an environment for goal based service discovery and invocation –Run-time binding of service requester and provider Provide a flexible Service Oriented Architecture –Add, update, remove components at run-time as needed Keep open-source to encourage participation –Developers are free to use in their own code Define formal execution semantics –Unambiguous model of system behaviour

70 OASIS Symposium 200670 WSMX Usage Scenario

71 OASIS Symposium 200671 WSMX Usage Scenario - P2P A P2P network of WSMX nodes Each WSMX node described as a SWS Communication via WSML over SOAP Distributed discovery – first aim Longer term aim - distributed execution environment

72 OASIS Symposium 200672 WSMX Usage Scenario - P2P

73 OASIS Symposium 200673 WSMX Usage Scenario - P2P

74 OASIS Symposium 200674 Design Principles Strong Decoupling & Strong Mediation –autonomous components with mediators for interoperability Interface vs. Implementation –distinguish interface (= description) from implementation (=program) Peer to Peer –interaction between equal partners (in terms of control) WSMO Design Principles == WSMX Design Principles == SOA Design Principles

75 OASIS Symposium 200675 Benefits of SOA Better reuse –Build new functionality (new execution semantics) on top of existing Business Services Well defined interfaces –Manage changes without affecting the Core System Easier Maintainability –Changes/Versions are not all-or-nothing Better Flexibility

76 OASIS Symposium 200676 WSMX Architecture Messaging Application Managemen t Service Oriented Architecture s Service Oriented Architecture s

77 OASIS Symposium 200677 Selected Components Adapters Parser Invoker Choreography Process Mediator Discovery Data Mediator Resource Manager Reasoning

78 OASIS Symposium 200678 Adapters To overcome data representation mismatches on the communication layer Transforms the format of a received message into WSML compliant format Based on mapping rules

79 OASIS Symposium 200679 Parser WSML compliant parser –Code handed over to wsmo4j initiative http://wsmo4j.sourceforge.net/ http://wsmo4j.sourceforge.net/ Validates WSML description files Compiles WSML description into internal memory model Stores WSML description persistently (using Resource Manager)

80 OASIS Symposium 200680 Communication Manager – Invoker WSMX uses –The SOAP implementation from Apache AXIS –The Apache Web Service Invocation Framework (WSIF) WSMO service descriptions are grounded to WSDL Both RPC and Document style invocations possible Input parameters for the Web Services are translated from WSML to XML using an additional XML Converter component. Network Invoker Apache AXIS XML Converter Mediated WSML Data XML Web Service SOAP

81 OASIS Symposium 200681 Choreography Requester and provider have their own observable communication patterns –Choreography part of WSMO Choreography instances are loaded for the requester and provider –Both requester and provider have their own WSMO descriptions Choreography Engine –Evaluation of transition rules Prepares the available data –Sends data to the Process Mediator The Process Mediator filters, changed or even replaced data –Receive data from PM and forwards it to the Communication manager Data to be finally sent to the communication partner

82 OASIS Symposium 200682 Process Mediator Requester and provider have their own communication patterns Only if the two match precisely, a direct communication may take place The Process Mediator provides the means for runtime analyses of two choreography instances and uses mediators to compensate possible mismatches

83 OASIS Symposium 200683 Discovery Responsible for finding appropriate Web Services to achieve a goal (discovery) Current discovery component is based on simple matching –Keywords identified in the NFP of the goal –Matched against NFPs of the published WSs –Variable set of NFPs to be considered for this process –To be extended Values in NFPs might be concepts from ontologies More elaborate string matching algorithms Advanced semantic discovery in prototypical stage

84 OASIS Symposium 200684 Data Mediator Ontology-to-ontology mediation A set of mapping rules are defined and then executed Initially rules are defined semi-automatic Create for each source instance the target instance(s)

85 OASIS Symposium 200685 Resource Manager Stores internal memory model to a data store Decouples storage mechanism from the rest of WSMX Data model is compliant to WSMO API Independent of any specific data store implementation i.e. database and storage mechanism

86 OASIS Symposium 200686 Reasoner Mins –Datalog + Negation + Function Symbols Reasoner Engine –Features Built-in predicates Function symbols Stratified negation WSMO4J –validation, serialization and parsing WSML2Reasoner –Reasoning API mapping fromWSML to a vendor-neutral rule representation –Contains: Common API for WSML Reasoners Transformations of WSML to tool-specific input data (query answering or instance retrieval) WSML-DL-Reasoner –Features: T-Box reasoning (provided by FaCT++) Querying for all concepts Querying for the equivalents, for the children, for the descendants, for the parents and for all ancestors of a given concept Testing the satisfiability of a given concept with respect to the knowledge base Subsumption test of two concepts with respect to the knowledge base Wrapper of WSML-DL to the XML syntax of DL used in the DIG interface

87 OASIS Symposium 200687 System Entry Points achieveGoal (WSMLDocument): Context getWebServices (WSMLDocument): Context invokeWebService(WSMLDocument, Context): Context

88 OASIS Symposium 200688 Define Business Process

89 OASIS Symposium 200689 Generate Wrappers for Components Discovery Wrapper Choreography Wrapper Communication Manager Wrapper Registry of known components

90 OASIS Symposium 200690 Context Data PROCESS CONTEXT Discovery Wrapper Data Mediator Choreography Wrapper Communication Manager Wrapper Registry of known components Choreography object Mediated objects, Web Services entities Errors Exceptions

91 OASIS Symposium 200691 Event-based Implementation

92 OASIS Symposium 200692 WSMX Conclusions Conceptual model is WSMO End to end functionality for executing SWS Has a formal execution semantics Real implementation Open source code base at SourceForge Event-driven component architecture

93 OASIS Symposium 200693 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

94 OASIS Symposium 200694 Means of Interoperability Format and Language heterogeneity –Adaptors to/from WSML Interface/communications formalism –Choreography and Orchestraton Ontology heterogeneity –Data Mediation Interface/communication patterns heterogeneity –Process Mediation

95 OASIS Symposium 200695 Adapter Framework Overview –Overcomes mismatches at the communication layer –Is based on Java Connector Architecture (JCA) –Is based on SOA design principles –Adapters function independently –Adapters are built based on mapping rules –Is developed in Java Motivation –WSMX does not recognize message formats other than WSML –Backend applications that do not use WSML cannot communicate with WSMX without the help of adapters that transforms the format of a received message to WSML format –Provide a unified framework for developing and using adapters

96 OASIS Symposium 200696 Features Adapters can be added and removed at run time Secure pluggability Supports both synchronous and asynchronous communication Handles communication protocol heterogeneity, i.e., allow to communicate using HTTP(S), TCP/IP, UDP Provides simple operations: –Deploy: adds adapter to the adapter pool –Undeploy: removes adapter from the adapter pool, subject to security constraints –Send: send legacy message to WSMX –Receive: receive legacy message from WSMX

97 OASIS Symposium 200697 Adapter Framework - Architecture

98 OASIS Symposium 200698 Adapter Framework – Deploy adapter deploy ( adapterName, someAdaper. adapter ) Request sent to deploy an adapter

99 OASIS Symposium 200699 Adapter Framework – Deploy adapter deploy ( adapterName, someAdaper. adapter ) Communication type scanned

100 OASIS Symposium 2006100 Adapter Framework – Deploy adapter deploy ( adapterName, someAdaper. adapter ) Fingerprint for this adapter created

101 OASIS Symposium 2006101 Adapter Framework – Deploy adapter Metadata updated

102 OASIS Symposium 2006102 Adapter Framework – Deploy adapter Adapter stored

103 OASIS Symposium 2006103 Adapter Framework – Deploy adapter Fingerprint returned in a requested communication mode

104 OASIS Symposium 2006104 Adapter Framework – Deploy adapter Fingerprint returned in to backend application D749 9163 9E5E BDFC 8018 E6B8 49DD 3252 ACF6 7294

105 OASIS Symposium 2006105 Adapter Framework – Send Message send to WSMX via Adapter Framework send ( adapterName, message, fingerprint )

106 OASIS Symposium 2006106 Adapter Framework – Send Communication type scanned send ( adapterName, message, fingerprint )

107 OASIS Symposium 2006107 Adapter Framework – Send Fingerprint checked, valid fingerprint send ( adapterName, message, fingerprint )

108 OASIS Symposium 2006108 Adapter Framework – Send Message format checked, valid fingerprint send ( adapterName, message, fingerprint )

109 OASIS Symposium 2006109 Adapter Framework – Send Internal request sent to select adapterName2WSML send ( adapterName, message, fingerprint )

110 OASIS Symposium 2006110 Adapter Framework – Send adapterName2WSML selected looking into metadata repository send ( adapterName, message, fingerprint )

111 OASIS Symposium 2006111 Adapter Framework – Send Message translated and sent to WSMX achieveGoal ( WSMLDocument )

112 OASIS Symposium 2006112 Adapter Framework – Undeploy adapter Request sent to undeploy an adapter together with its fingerprint undeploy ( adapterName, D749 9163 9E5E BDFC 8018 E6B8 49DD 3252 ACF6 7294 )

113 OASIS Symposium 2006113 Adapter Framework – Undeploy adapter Fingerprint checked, valid fingerprint undeploy ( adapterName, D749 9163 9E5E BDFC 8018 E6B8 49DD 3252 ACF6 7294 )

114 OASIS Symposium 2006114 Adapter Framework – Undeploy adapter Metadata updated

115 OASIS Symposium 2006115 Adapter Framework – Undeploy adapter Adapter removed

116 OASIS Symposium 2006 VTA Service Date Time Flight, Hotel Error Confirmation Hotel Service Flight Service Date, Time Hotel Error Date, Time Flight Error When the service is requested When the service requests Choreography & Orchestration VTA example: Choreography = how to interact with the service to consume its functionality Orchestration = how service functionality is achieved by aggregating other Web services Confirmation

117 OASIS Symposium 2006 Abstract State Machine Formality –a rigid framework to express dynamics. Maximality –expressive enough to model any aspect around computation Minimality –minimal set of modeling primitives – minimal ontological commitment

118 OASIS Symposium 2006 Choreography outline NFPs –The same as in WSML State Signature –Defines the state ontology used by the service together with the definition of the types of modes the concepts and relations may have Transition Rules –Express changes of states Class choreography hasNonFunctionalProperties type nonFunctionalProperties hasStateSignature type stateSignature hasTransitionRules type transitionRules

119 OASIS Symposium 2006 States Signatures Class stateSignature hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator hasStatic type mode hasIn type mode hasOut type mode hasShared type mode hasControlled type mode Class mode subClass {concept, relation} hasGrounding type grounding

120 OASIS Symposium 2006 Transition Rules if φ then T endIf forall V with ψ do T endForall choose V with ψ do T endChoose φ is a first order formula with no free variables V is a set of variables ψ is a first order formula where the free variables are interpreted as parameters and all free variables in ψ occur in V T is a set of transition rules T is a set of transition rules and/or non-ground update rules, where each variable which occurs in any non-ground update rule in T, occurs also in V

121 OASIS Symposium 2006 Update rules add(a) delete(a) where a is a WSML atomic formula, which possibly includes –parameter variables, or –non-primitive update rules of the form: update(a new ) update(a old => a new ) S U = S \ {a|delete(a) Є U} U {a|add(a) Є U} where O is an ontology O, S a state and U an update set

122 OASIS Symposium 2006 Machine behaviour Given C = (O, T, S) S 0 = S for 0 i n-1, –S i S i+1 –U = {add(a) | a Є S i+1 \ S i } U {delete(a) | a Є S i \ S i+1 } is an update set associated with S i, O and T –S i+1 is consistent with O, and S i run terminated

123 OASIS Symposium 2006123 Data Mediator Ontology-to-ontology mediation A set of mapping rules are defined and then executed Initially rules are defined semi-automatic Create for each source instance the target instance(s)

124 OASIS Symposium 2006124 Design-time Inputs –Source Ontology and Target Ontology Features –Graphical interface –Set of mechanism towards semi-automatic creation of mappings –Capturing the semantic relationships identified in the process –Storing these mappings in a persistent storage Output –Abstract representation of the mappings

125 OASIS Symposium 2006125 Design-time Phase

126 OASIS Symposium 2006126 Design-time Phase - Approach, Decomposition and Mapping Context Bottom-up -> training set Top-down -> decomposition, context

127 OASIS Symposium 2006127 Design-time Phase - Suggestion Algorithms Eligibility Factor = f(Lexical Factor, Structural Factor) Lexical Factor: –WordNet Synonyms, hyponyms, hipernyms –string analyzing algorithms Tokenizer and string distance Structural Factor –Decomposition, EF for the composing concepts Based on the already done mappings

128 OASIS Symposium 2006128 Run-Time Data Mediator Main Mediation Scenario: Instance Transformation Inputs –Incoming data Source ontology instances Features –Completely automatic process –Grounding of the abstract mappings to a concrete language F-Logic, WSML –Uses a reasoner to evaluate the mapping rules MINS Outputs –Mediated data Target ontology instances

129 OASIS Symposium 2006129 Run Time Component - Architecture Abstract Mappings Repr. Rules Generator Instance Source Reasoning Environment Mapping Rules Mappings Instance Target Ontologies

130 OASIS Symposium 2006130 Run Time Component – Features Grounding the abstract mappings Associate a formal semantics to the mappings –Obtain rules in a concrete language Why not during design time? –Offers a grater flexibility –Different groundings for the same mappings set –Different execution environments for the grounded mappings –Easier to maintain the abstract mappings –Important point of alignment Caching mechanism can be used

131 OASIS Symposium 2006131 Ontology Mapping Language Language Neutral Mapping Language –mapping definitions on meta-layer (i.e. on generic ontological constructs) –independent of ontology specification language –Grounding to specific languages for execution (WSML, OWL, F-Logic) Main Features: –Mapping Document (sources, mappings, mediation service) –direction of mapping (uni- / bidirectional) –conditions / logical expressions for data type mismatch handling, restriction of mapping validity, and complex mapping definitions –mapping constructs: classMapping, attributeMapping, relationMapping (between similar constructs) classAtrributeMapping, classRelationMapping, classInstanceMapping instanceMapping (explicit ontology instance transformation) –mapping operators: =,, >=, and, or, not inverse, symmetric, transitive, reflexive join, split

132 OASIS Symposium 2006132 Ontology O2 Mapping Language Example Human - name Adult Child Person - name - age mick memberOf Person - name = Mick Kerrigan - age = 27 classMapping(unidirectional o2:Person o1.Adult attributeValueCondition(o2.Person.age >= 18)) This allows to transform the instance mick of concept person in ontology O2 into a valid instance of concept adult in ontology O1 Ontology O1

133 OASIS Symposium 2006133 Process Mediator Requester and provider have their own communication patterns Only if the two match precisely, a direct communication may take place The Process Mediator provides the means for runtime analyses of two choreography instances and uses mediators to compensate possible mismatches

134 OASIS Symposium 2006134 Compatibility Two business partners are compatible if their public processes are matching Business Partner1 Business Partner2 A B C D E A B C D E

135 OASIS Symposium 2006135 Compatibility Two business partners are compatible if their public processes are matching Business Partner1 Business Partner2 A B C D E E B C, D A

136 OASIS Symposium 2006136 Process Mediator – Addressed Mismatches

137 OASIS Symposium 2006137 Process Mediator – Unsolvable Mismatches Business Partner1 Business Partner1 Business Partner2 Business A Partner1 Business Partner1 Business Partner2 Business Partner2 AB BA Business Partner1 Business Partner1 Business Partner2 Business Partner2 PM A Ack ? ? ?

138 OASIS Symposium 2006138 itinerary[origin, destination, date] time price origin destination itinerary[origin, destination] date ticket[route, date, time, price] REQUESTREQUEST SERVICESERVICE Processes Mediator Process Mediation Example

139 OASIS Symposium 2006139 time price date REQUESTREQUEST SERVICESERVICE Processes Mediator Process Mediation Example itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket [route, date, time, price]

140 OASIS Symposium 2006140 time price date REQUESTREQUEST SERVICESERVICE Processes Mediator Process Mediation Example itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket [route, date, time, price]

141 OASIS Symposium 2006141 time price date REQUESTREQUEST SERVICESERVICE Processes Mediator itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket [route, date, time, price] Process Mediation Example

142 OASIS Symposium 2006142 time price date REQUESTREQUEST SERVICESERVICE Processes Mediator itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket [route, date, time, price] Process Mediation Example

143 OASIS Symposium 2006143 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

144 OASIS Symposium 2006144 Web Services Modeling Toolkit The aim of the Web Services Modeling Toolkit (WSMT) is to provide high-quality tools for designing, mediating and using Semantic Web Services, through the WSMO paradigm. The focus is currently on the following areas: –Creation of ontologies, web services, goals and mediators in WSMO –Creation of mappings between pairs of ontologies to allow runtime instance transformation –Management of Execution Environments for Semantic Web Services like WSMX and IRSIII

145 OASIS Symposium 2006145 WSML Perspective Perspectives in the Eclipse framework allow for a number of Editors and views to be grouped and positions. The WSML perspective offers editors and views related to engineering of semantic descriptions in WSMO through the WSML language. Other General features include: –WSML file validation –Problems view (errors and warnings on files in the workspace) –Label highlighting (marking of errors and warnings in navigator view)

146 OASIS Symposium 2006146 WSML Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

147 OASIS Symposium 2006147 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

148 OASIS Symposium 2006148 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

149 OASIS Symposium 2006149 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

150 OASIS Symposium 2006150 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

151 OASIS Symposium 2006151 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

152 OASIS Symposium 2006152 Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner

153 OASIS Symposium 2006153 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

154 OASIS Symposium 2006154 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

155 OASIS Symposium 2006155 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

156 OASIS Symposium 2006156 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

157 OASIS Symposium 2006157 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

158 OASIS Symposium 2006158 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

159 OASIS Symposium 2006159 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

160 OASIS Symposium 2006160 Editors, Views for the Abstract Mapping Language Editors AML Text Editor AML Conceptual Editor AML View Based Editor Views Concept 2 Concept View Attribute 2 Attribute View Concept 2 Attribute View Attribute 2 Concept View Status View

161 OASIS Symposium 2006161 Overview Introduction to SWS –WSMO Introduction to SOA –WSMX Means of Interoperability WSMT Conclusions

162 OASIS Symposium 2006162 Conclusions Semantic Enabled SOA combines the benefits of semantics with best practices from industry WSMO - conceptual model for Semantic Web Services –Ontology of core elements for Semantic Web Services Clear separation between layers –Specification and realization –Interface and implementation WSMX/SEE – a Semantic Enabled SOA –Service Oriented Architecture –Reference implementation of WSMO Semantic Enabled SOA offers multiple means for interoperability –Mediation framework –Interface/communication disambiguation WSMT – emerging tool to handle semantics –High-quality tools for designing, mediating and using Semantic Web Services

163 OASIS Symposium 2006163 References The central location where WSMO work and papers can be found is WSMO Working Group: http://www.wsmo.orghttp://www.wsmo.org WSMO languages – WSML Working Group: http://www.wsml.orghttp://www.wsml.org WSMO implementation –WSMX working group : http://www.wsmx.orghttp://www.wsmx.org –WSMX open source can be found at: https://sourceforge.net/projects/wsmx/https://sourceforge.net/projects/wsmx/

164 OASIS Symposium 2006164 References [WSMO Specification]: Roman, D.; Lausen, H.; Keller, U. (eds.): Web Service Modeling Ontology, WSMO Working Draft D2, final version 1.2, 13 April 2005. [WSMO Primer]: Feier, C. (ed.): WSMO Primer, WSMO Working Draft D3.1, 18 February 2005. [WSMO Choreography and Orchestration] Roman, D.; Scicluna, J., Feier, C. (eds.): Ontology-based Choreography and Orchestration of WSMO Services, WSMO Working Draft D14, 01 March 2005. [WSMO Use Case] Stollberg, M.; Lausen, H.; Polleres, A.; Lara, R. (ed.): WSMO Use Case Modeling and Testing, WSMO Working Drafts D3.2; D3.3.; D3.4; D3.5, 05 November 2004. [WSML] de Bruijn, J. (Ed.): The WSML Specification, WSML Working Draft D16, 03 February 2005. [Arroyo et al. 2004] Arroyo, S., Lara, R., Gomez, J. M., Berka, D., Ding, Y. and Fensel, D: "Semantic Aspects of Web Services" in Practical Handbook of Internet Computing. Munindar P. Singh, editor. Chapman Hall and CRC Press, Baton Rouge. 2004. [Berners-Lee et al. 2001] Tim Berners-Lee, James Hendler, and Ora Lassila, The Semantic Web. Scientific American, 284(5):34-43, 2001.

165 OASIS Symposium 2006165 References [Bussler, 2003] Bussler, C. (2003): B2B Integration. Berlin, Heidelberg: Springer. [Cimpian and Mocan, 2005] Emilia Cimpian, Adrian Mocan: WSMX Process Mediation Based on Choreographies, 1st International Workshop on Web Service Choreography and Orchestration for Business Process Management (BPM 2005), September 2005, Nancy, France [Chen et al., 1993] Chen, W., Kifer, M., and Warren, D. S. (1993). HILOG: A foundation for higher-order logic programming. Journal of Logic Programming, 15(3):187-230. [Haller et al., 2005] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. WSMX - A Semantic Service-Oriented Architecture. International Conference on Web Services (ICWS 2005), July 2005. [Kerrigan, 2006] Mick Kerrigan: Web Service Selection Mechanisms in the Web Service Execution Environment (WSMX), Proceedings of the 21st Annual ACM Symposium on Applied Computing (SAC), April, 2006, Dijon, France [Mandell and McIIraith, 2003] Daniel J. Mandell and Sheila A. McIlraith. Adapting BPEL4WS for the Semantic Web: The Bottom-Up Approach to Web Service Interoperation. In Proceedings of the Second International Semantic Web Conference (ISWC2003) [Mocan and Cimpian, 2005] Adrian Mocan, Emilia Cimpian: Mapping Creation Using a View Based Approach, 1st International Workshop on Mediation in Semantic Web Services (Mediate 2005), December 2005, Amsterdam, Netherlands

166 OASIS Symposium 2006166 References [Domingue et al., 2004] Domingue, J. Cabral, L., Hakimpour, F., Sell D., and Motta, E., (2004) IRS-III: A Platform and Infrastructure for Creating WSMO- based Semantic Web Services WSMO Implementation Workshop (WIW), Frankfurt, Germany, September,2004 [Feier et al., 2005] C. Feier, A. Polleres, R. Dumitru, J. Domingue, M. Stollberg, and D. Fensel. Towards intelligent web services: The web service modeling ontology (WSMO). International Conference on Intelligent Computing (ICIC), April 2005. [Fensel, 2001] Dieter Fensel, Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce, Springer-Verlag, Berlin, 2001. [Fensel and Bussler, 2002] Fensel D. and Bussler C., "The Web Service Modeling Framework, WSMF," Electronic Commerce Research and Application, vol. 1, 2002 [Fensel, 2004] D. Fensel: Triple Space computing - Semantic Web Services based on persistent publication of information. In Proceedings of IFIP International Conference on Intelligence in Communication Systems, Pages 43-53, Bangkok, Thailand, November 2004. [Gruber, 1993] Thomas R. Gruber, A Translation Approach to Portable Ontology Specifications, Knowledge Acquisition, 5:199-220, 1993. [Grosof et al., 2003] Grosof, B. N., Horrocks, I., Volz, R., and Decker, S. (2003). Description logic programs: Combining logic programs with description logic. In Proc. Intl. Conf. on the World Wide Web (WWW-2003), Budapest, Hungary.

167 OASIS Symposium 2006167 References [Haselwanter et al., 2005] Haselwanter, T.; Zaremba, Ma.., Zaremba Mi.: Enabling Components Management and Executions Semantics in WSMX. In Proceedings of the 2nd International WSMO Implementation Workshop (WIW 2005), Innsbruck, Austria, June 2005. [Keller et al., 2004] Keller, U.; Lara, R.; Polleres, A. (Eds): WSMO Web Service Discovery. WSML Working Draft D5.1, 12 Nov 2004. [Keller et al., 2005] Keller, U.; Lara, R.; Lausen, H.; Polleres, A.; Fensel, D.: Automatic Location of Services. In Proc. of the 2nd European Semantic Web Symposium (ESWS2005), Heraklion, Crete, 2005. [Kifer et al., 1995] Kifer, M., Lausen, G., and Wu, J. (1995). Logical foundations of object-oriented and frame-based languages. JACM, 42(4):741-843. [Kiffer et al., 2004] M. Kifer, R. Lara, A. Polleres, C. Zhao, U. Keller, H. Lausen and D. Fensel: A Logical Framework for Web Service Discovery. Proc. 1st. Intl. Workshop SWS'2004 at ISWC 2004,Hiroshima, Japan, November 8, 2004, CEUR Workshop Proceedings, ISSN 1613-0073 [Li and Horrocks, 2003] Lei Li and Ian Horrocks. A software framework for matchmaking based on semantic web technology. In Proc. of the Twelfth International World Wide Web Conference (WWW 2003), 2003 [Paolucci et al., 2002a] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara; Importing the Semantic Web in UDDI. In Proceedings of Web Services, E-business and Semantic Web Workshop, 2002 [Paolucci et al., 2002b] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara; "Semantic Matching of Web Services Capabilities." In Proceedings of the 1st International Semantic Web Conference (ISWC2002), 2002

168 OASIS Symposium 2006168 References [Pan and Horrocks, 2004] Pan, J. Z. and Horrocks, I. (2004). OWL-E: Extending OWL with expressive datatype expressions. IMG Technical Report IMG/2004/KR-SW-01/v1.0, Victoria University of Manchester. Available from http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf.http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf [Preist, 2004] Preist, C.: A Conceptual Architecture for Semantic Web Services. In Proceedings of the 3rd International Semantic Web Conference (ISWC 2004), 2004, pp. 395 - 409. [Pollers et al., 2005] Axel Polleres, Holger Lausen, Jos de Bruijn and Dieter Fensel. WSML - A Language Framework for Semantic Web Services. W3C Workshop on Rule Languages for Interoperability, April 2005. [Stencil Group] - www.stencilgroup.com/ideas_scope_200106wsdefined.htmlwww.stencilgroup.com/ideas_scope_200106wsdefined.html [Stolberg et al., 2004] Stollberg, M.; Keller, U.; Fensel. D.: Partner and Service Discovery for Collaboration on the Semantic Web. Proc. 3rd Intl. Conference on Web Services (ICWS 2005), Orlando, Florida, July 2005. [Stolberg et al., 2005] M. Stollberg, E. Cimpian, and D. Fensel. Mediating Capabilities with Delta-Relations. In Proceedings of the First International Workshop on Mediation in Semantic Web Services, co-located with the Third International Conference on Service Oriented Computing (ICSOC 2005), Amsterdam, the Netherlands, 2005. [Stollberg et al., 2006] Michael Stollberg, Emilia Cimpian, Adrian Mocan, Dieter Fensel: A Semantic Web Mediation Architecture, Canadian Semantic Web Working Symposium (CSWWS 2006), June 2006, Québec city, Canada [Zaremba and Bussler, 2005] Zaremba, M. and Bussler, C.: Towards Dynamic Execution Semantics in Semantic Web Services. In Proceedings of the WWW 2005 Workshop on Web Service Semantics: Towards Dynamic Business Integration, 2005.

169 OASIS Symposium 2006169 Acknowledgements We would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this tutorial. The WSMO working groups are funded by the European Commission under the projects ASG, DIP, Knowledge Web, SEKT, SemanticGov, SWWS, AKT and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the FIT-IT program


Download ppt "1 Applying Semantics to Service Oriented Architectures Oasis Symposium 2006 The Meaning of Interoperability 9-12 May, San Francisco Presenters: Adrian."

Similar presentations


Ads by Google