Applying Semantics to Service Oriented Architectures: 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


The Aims of this Tutorial: The Aims of this Tutorial Introduce the aims andamp; 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


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability Web Service Modeling Toolkit (WSMT) Conclusions


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Introduction to Semantic Web Services: Introduction to Semantic Web Services Introduction to Semantic Web Introduction to Web services Semantic Web Services


Semantic Web and Web Services – The Vision: Static WWW URI, HTML, HTTP Semantic Web and Web Services – The Vision


Semantic Web and Web Services: 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


Semantic Web and Web Services – The Vision: 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


Semantic Web and Web Services – The Vision: 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


Ontology Definition: Formal, explicit specification of a shared conceptualization Ontology Definition


Ontology Example: 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) name email student nr. research field topic lecture nr. attends holds holds(Professor, Lecture)  Lecture.topic  Professor.researchField


Ontology Languages : 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


Semantic Web Language Layer Cake: Semantic Web Language Layer Cake


Web Services: 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


Using Web Services: Using Web Services


Using Web Services: Using Web Services


Lack of SWS standards: 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


Semantic Web Services: 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)


Semantic Web Services (2): 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


Semantic Web Services (3): 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


Summary: Semantic Web Services = Semantic Web Technology + Web Service Technology Summary


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Web Service Modeling Ontology (WSMO): 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


WSMO Working Groups: A Conceptual Model for SWS A Formal Language for WSMO A Rule-based Language for SWS Execution Environment for WSMO WSMO Working Groups


WSMO Design Principles: WSMO Design Principles Web Compliance Ontology-Based Strict Decoupling Of Modeling Elements Centrality of Mediation Ontological Role Separation Description versus Implementation Execution Semantics WSMO


WSMO Top Level Notions: 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


Non-Functional Properties: 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


Non-Functional Properties List: 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


WSMO Ontologies: 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


Ontology Usage & Principles: Ontology Usage andamp; 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 andamp; 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


Ontology Specification: 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)


WSMO Web services: 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


WSMO Web service description: Web service Implementation (not of interest in Web Service Description) Choreography --- Service Interfaces --- Capability functional description 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 Orchestration WSMO Web service description


Capability Specification: 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)


Choreography & Orchestration: 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 andamp; 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 Confirmation


Choreography Aspects: 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


Orchestration Aspects: decomposition of service functionality all service interaction via choreographies Control Structure for aggregation of other Web Services Web Service Business Logic 1 2 3 4 Orchestration Aspects


Orchestration Aspects: 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.


Choreography and Orchestration - Overview: 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 andamp; 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 andamp; 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 andamp; Browsing Service Interface Description Choreography and Orchestration - Overview


WSMO Goals: 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


Goals: 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


Goal Specification: 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


WSMO Mediators: 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


Mediation: Mediation Heterogeneity … Mismatches on structural / semantic / conceptual / functional / level Occur between different components that shall interoperate Especially in distributed andamp; 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): Data Level: mediate heterogeneous Data Sources Functional Level: mediate mismatches between Web Service/Goal and Web Service/Goals functionalities Process/Protocol Level: mediate heterogeneous Business Processes/Communication Patterns Layers of Mediators Specification Layer – WSMO Mediators Implementation Layer – Levels of Mediation


WSMO Mediators Overview: WSMO Mediators Overview


Mediator Structure: 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


OO Mediator - Example: OO Mediator Mediation Service Train Connection Ontology (s1) Purchase Ontology (s2) Train Ticket Purchase Ontology Mediation Services Discovery Merging 2 ontologies OO Mediator - Example


GG Mediators: 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


WG & WW Mediators: 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 andamp; WW Mediators


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


Functional Level Mediation: Functional Level Mediation Scope Solving functional mismatches between goals and/or ws Related Aspects/Techniques Discovery Semantic Matchmaking Matchmaking Mismatches = G/WS = G/WS Exact Match Subsumption Match Intersection Match No Match PlugIn Match


Process Level Mediation: 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


WSMO Mediators and Mediation Levels: 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


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Information Technology versus Mission of Organizations: 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


Existing IT architectures cannot support changing needs: Existing IT architectures cannot support changing needs


A Solution – Service Oriented Architectures: 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


Analogy - traditional software architecture versus SOA: 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' model 'Service-Oriented' model Mechanic does job himself or asks other mechanics to take care of tasks he is not capable to do


SOA Benefits: SOA Benefits


SOA Design Principles: SOA Design Principles Strong Decoupling andamp; 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)


Benefits of SOA: 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


Semantically Empowered Service-oriented Architectures (SESA): 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.


Semantically Empowered Service-oriented Architecture (SESA) : 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


Semantic Web Services Infrastructure: Semantic Web Services Infrastructure A service oriented architecture. Reference implementation of WSMO


User Service versus Platform Service in SWS Systems: User Service versus Platform Service in SWS Systems


Vertical and Horizontal Services : 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


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


WSMX Introduction: WSMX Introduction Software framework for runtime binding of service requesters and service providers WSMX interprets service requester’s 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.


WSMX Motivation: 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


WSMX Usage Scenario: WSMX Usage Scenario


WSMX Usage Scenario - P2P: 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


WSMX Usage Scenario - P2P: WSMX Usage Scenario - P2P


WSMX Usage Scenario - P2P: WSMX Usage Scenario - P2P


Design Principles: Design Principles Strong Decoupling andamp; 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


Benefits of SOA: 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


WSMX Architecture: WSMX Architecture Messaging Application Management Service Oriented Architectures


Selected Components: Selected Components Adapters Parser Invoker Choreography Process Mediator Discovery Data Mediator Resource Manager Reasoning


Adapters: 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


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


Communication Manager – Invoker: 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


Choreography: 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


Process Mediator: 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


Discovery: 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


Data Mediator: 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)


Resource Manager: 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


Reasoner: 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


System Entry Points: System Entry Points achieveGoal (WSMLDocument): Context getWebServices (WSMLDocument): Context invokeWebService(WSMLDocument, Context): Context


Define “Business” Process: Define 'Business' Process


Generate Wrappers for Components: Generate Wrappers for Components


Context Data: Context Data


Event-based Implementation: Event-based Implementation


WSMX Conclusions: 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


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Means of Interoperability: 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


Adapter Framework: 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


Features: 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


Adapter Framework - Architecture: Adapter Framework - Architecture


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter deploy (adapterName, someAdaper.adapter) Request sent to deploy an adapter


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter deploy (adapterName, someAdaper.adapter) Communication type scanned


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter deploy (adapterName, someAdaper.adapter) Fingerprint for this adapter created


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter Metadata updated


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter Adapter stored


Adapter Framework – Deploy adapter: Adapter Framework – Deploy adapter Fingerprint returned in a requested communication mode


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


Adapter Framework – Send: Adapter Framework – Send Message send to WSMX via Adapter Framework send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send Communication type scanned send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send Fingerprint checked, valid fingerprint send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send Message format checked, valid fingerprint send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send Internal request sent to select adapterName2WSML send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send adapterName2WSML selected looking into metadata repository send (adapterName, message, fingerprint)


Adapter Framework – Send: Adapter Framework – Send Message translated and sent to WSMX achieveGoal (WSMLDocument)


Adapter Framework – Undeploy adapter: 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)


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


Adapter Framework – Undeploy adapter: Adapter Framework – Undeploy adapter Metadata updated


Adapter Framework – Undeploy adapter: Adapter Framework – Undeploy adapter Adapter removed


Choreography & Orchestration: 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 andamp; 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 Confirmation


Abstract State Machine: 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


Choreography outline: 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


States Signatures: 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


Transition Rules: 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


Update rules: 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(anew) update(aold =andgt; anew) SU = S \ {a|delete(a) Є U} U {a|add(a) Є U} where O is an ontology O, S a state and U an update set


Machine behaviour: Machine behaviour Given C = (O, T, S) S0 = S for 0 ≤ i ≤ n-1, Si ≠ Si+1 U = {add(a) | a Є Si+1 \ Si} U {delete(a) | a Є Si \ Si+1} is an update set associated with Si, O and T Si+1 is consistent with O, and Si run terminated


Data Mediator: 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)


Design-time: 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


Design-time Phase: Design-time Phase


Design-time Phase - Approach, Decomposition and Mapping Context: Design-time Phase - Approach, Decomposition and Mapping Context Bottom-up -andgt; training set Top-down -andgt; decomposition, context


Design-time Phase - Suggestion Algorithms: 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


Run-Time Data Mediator: 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


Run Time Component - Architecture: Run Time Component - Architecture Mapping Rules Mappings


Run Time Component – Features: 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


Ontology Mapping Language: 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: =, andlt;, andlt;=, andgt;, andgt;=, and, or, not inverse, symmetric, transitive, reflexive join, split


Mapping Language Example: 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 andgt;= 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


Process Mediator: 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


Compatibility: Compatibility Two business partners are compatible if their public processes are matching A B C D E A B C D E


Compatibility: Compatibility Two business partners are compatible if their public processes are matching A B C D E E B C, D A


Process Mediator – Addressed Mismatches: Process Mediator – Addressed Mismatches


Process Mediator – Unsolvable Mismatches: Process Mediator – Unsolvable Mismatches


Process Mediation Example : itinerary[origin, destination, date] time price origin destination itinerary[origin, destination] date ticket[route, date, time, price] R E Q U E S T S E R V I C E Processes Mediator Process Mediation Example


Process Mediation Example : time price date R E Q U E S T S E R V I C E Processes Mediator Process Mediation Example itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket[route, date, time, price]


Process Mediation Example : time price date R E Q U E S T S E R V I C E Processes Mediator Process Mediation Example itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket[route, date, time, price]


Process Mediation Example : time price date R E Q U E S T S E R V I C E Processes Mediator itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket[route, date, time, price] Process Mediation Example


Process Mediation Example : time price date R E Q U E S T S E R V I C E Processes Mediator itinerary[origin, destination, date] origin destination itinerary[origin, destination] ticket[route, date, time, price] Process Mediation Example


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Web Services Modeling Toolkit: 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


WSML Perspective: 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)


WSML Editors and Views in the WSML perspective: WSML Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors and Views in the WSML perspective: Editors and Views in the WSML perspective Editors WSML Text Editor WSML Conceptual Editor WSML Visualizer Views Navigator view Problems view WSML Reasoner


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Editors, Views for the Abstract Mapping Language: 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


Overview: Overview Introduction to SWS WSMO Introduction to SOA WSMX Means of Interoperability WSMT Conclusions


Conclusions: 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


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


References: 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.


References: 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


References : 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.


References : 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


References: 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. [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.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.


Acknowledgements: 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