INF 5120 Modellbasert Systemutvikling F 13: Model Driven Semantic interoperability – with Semantic web, Ontologies and Semantic SOA Forelesning 28. 04. 2008 Arne-Jørgen Berre Telecom and Informatics
Agenda Lecture plan and pensum INF 5120 Model Driven Interoperability (ref. F 11) Semantic Web Ontologies and RDF, OWL Semantic Web services and SOA Semantic Annotation and reconciliation Semantic SOA Telecom and Informatics
Lectures 1: 21/1: Introduction to MBSU, MDA, OO and Service/SOA modeling (AJB) 2: 28/1: Business Process Modeling (CIM) - with BPMN (AJB) 3: 4/2: Metamodeling and UML profiles, MDA technologies (EMF/GMF) – BPMN example (BRE) 4: 11/2: Language Engineering and DSL – SOA Example (BRE) 5: 18/2: Model transformations with ATL and QVT – and JEE (GO) 6: 25/2: SOA Architectures and UPMS (PIM) (AJB) 7: 3/3: Method Engineering and Service Modeling/SEMET (BRE) 8: 10/3: Code generation with MOFScript and other technologies (GO) EASTER 9 : 31/3: : Service Design and Patterns (AJB) 10: 7/4: PIM and Web Services technology (PSM) with WSDL/XML/BPEL (PSM) (BRE) 11: 14/4: Web services and Model Driven Interoperability (BRE) 12: 21/4: Architecture work at Telenor and Agent technologies (JOEA, Ismar) 13: 28/4: Model Driven Semantic interoperability–with Ontologies, Semantic web and SOA (AJB) 14: 5/5: Course summary, Course Handbooks/Material and updated Buyer/Seller Example (AJB) 15: 26/5 Preparation for exam, Course summary – QA and previous exams (AJB) Exam: June 2 nd, 2008… AJB – Arne J. Berre, BRE – Brian Elvesæter, GO – Gøran Olsen Telecom and Informatics
Model Driven Interoperability (ref. Lecture 11) Telecom and Informatics
ATHENA Interoperability Reference Architecture Telecom and Informatics
reconciliation Reference Ontology Sem Sw. App#1 Annot Set #1 Local Softwar e& Data Sem Rec Rules #1 Sem Annot Set #2 Design-time Run-time Internet Reconciliation Sem Rec Rules #2 Telecom and Informatics Sw. App#2 Local Softwar e& Data
Semantic Web Telecom and Informatics
Semantics – ancient Greek for meaning σημαίνω – I signal, sign, show Semantics has become a buzzword or even a fuzzword Example from a book about Eclipse: “We’ll use the same mechanisms to navigate semantic errors (…) that we use to navigate compile errors. ” (failing tests) – semantic error is less precise than “failing tests” a fuzzword in this case Oxford English Dictionary: 2. a. Relating to signification or meaning. (as adjective) Telecom and Informatics
Semantics and Definitions Standard way to communicate meaning is by definition: “Verbal description of a concept, permitting its differentiation from other concepts within a system of concepts. ” – International Standard ISO 1087, Terminology – Vocabulary, 1990 The Semantic Web is about formalizing your definitions “the Semantic Web, as envisioned by Tim Berners-Lee and many others since, is a logical extension of the current Web that enables explicit [machine-processable] representations of term meanings [concepts]” – Frankel, David; Hayes, Pat; Kendall, Elisa; Mc. Guinness, Deborah: MDA Journal July 2004 Telecom and Informatics
Ontology "An ontology is an explicit and formal specification (based on logic) of a shared conceptualization" Formality Spectrum: formal Ontology, e. g, OWL ontology SAPterm Informal Word. Net Formal Every tomato is red. for all x ( tomato (x) implies red (x) ) Telecom and Informatics
Concept, Object, Designation (term), and Definition Concept Definition A one-piece, handheld phone that includes battery power and may be used without any peripheral power or antenna. (Nokia) Object term is verbal designation Designations (terms) Handy (DE) cellular phone, cell phone (US) (two variants) mobile (UK) Telecom and Informatics
More on the meaning triangle morning star evening star An example from Gottlob Frege (1848 -1925): different terms different concepts and definitions same object, the planet Venus Telecom and Informatics
The general vision Serious Problems in information: • finding • extracting • representing • interpreting • and maintaining WWW URI, HTML, HTTP Bringing the web to its full potential: data and semantic interoperability Semantic Web RDF, RDF(S), OWL Telecom and Informatics
What is the Semantic Web? The Semantic Web is a major research initiative of the World Wide Web Consortium (W 3 C) to create a metadata-rich Web of resources that can describe themselves not only by how they should be displayed (HTML) or syntactically (XML), but also by the meaning of the metadata. From W 3 C Semantic Web Activity The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2001 Telecom and Informatics
Evolution of the semantic web Telecom and Informatics 16
The Tree of Knowledge Technologies (Extended from. Top Quadrant) WSMO OWL-S WSDL-S SAWSDL CC EXPRESS ISO 15926 Telecom and Informatics 17
Internet Evolution Telecom and Informatics 18
Ontologies and Ontology languages (RDF, OWL) Telecom and Informatics
RDF: Resource Description Framework RDF is the simplest of the semantic languages. At the simplest level, the Resource Description Framework is an XML-based language to describe resources. Basic Idea #1: RFD uses triples RDF is based on a subject-verb-object statement structure. RDF subjects are called resources (classes). Verbs (predicates) are called properties. Objects (values) may be simple literals or other resources. • Basic Idea #2: Everything is a resource that is named with a URI RDF nouns, verbs, and objects are all labeled with URIs A URI is just a name for a resource. It may be a URL, but not necessarily. A URI can name anything that can be described. Web pages, telephone numbers, concepts, creators of web pages, organizations that the creator works for…. Telecom and Informatics
Resource Description Framework (RDF) A language for making simple statements about things (resources) Statements: Subject Predicate Object (triples) Item 1 is. Order. For Product 1 Item 1 is-a Item Product 1 has. Name “Lawnmower” subject predicate object Line. Item database table: Telecom and Informatics
RDF and URIrefs Things are identified by Uniform Resource Identifiers (URI, URIref) Avoids naming clashes http: //www. co. uk/vocabulary#Item 1 (v: ) http: //www. w 3. org/1999/02/22 -rdf-syntax-ns#type (rdf: ) Same example using namespace prefixes v: Item 1 v: is. Order. For v: Product 1 v: Item 1 rdf: type v: Item v: Product 1 v: has. Name “Lawnmower” Subject and Predicate are always resources Objects can be either resources or literals (see 3 rd triple) Telecom and Informatics
RDF data model rdf: type v: Item 1 v: has. Order. Quantity 1 RDF statements can be expressed using XML syntax But, the RDF data model is a graph of nodes and directed arcs Subjects and objects are nodes Predicates (also called Properties) are directed arcs from the subject to the object. properties relate individuals to individuals (or values) Telecom and Informatics
RDF Schema compared to XML Has a formal model-theoretic semantics By contrast, there is no formal semantics for XML documents like po. xml po. xsd can be turned into an ontology and po. xml into an instance of it But, there is no standard algorithm to perform that transformation no single interpretation • <? xml version="1. 0"? > <purchase. Order order. Date="1999 -10 -20"> <ship. To country="US"> <name>Alice Smith</name> <street>123 Maple Street</street>… </ship. To> <bill. To country="US"> <name>Robert Smith</name> … </bill. To> <comment>Hurry, my lawn is going wild!</comment> <items> <item part. Num="872 -AA"> <product. Name>Lawnmower </product. Name> <quantity>1</quantity> <USPrice>148. 95</USPrice> <comment>Confirm this is electric </comment> </item> <item part. Num="926 -AA">… </items> </purchase. Order> Telecom and Informatics
RDF: Purchase. Order <rdf: RDF xmlns: rdf="http: //www. w 3. org/1999/02/22 -rdf-syntax-ns#" xmlns: po="http: //example. com/purchase-order-ns" xmlns: addr="http: //example. com/address-ns" xmlns: prod="http: //example. com/product-ns"> <po: Purchase. Order> <po: order. Number>123456</po: order. Number> <po: raised. By> <po: Customer> <po: name>Wild Widgets Inc. </po: name> <po: customer. Number>1447389</po: customer. Number> </po: Customer> </po: raised. By> <po: customer. Ref>XS 31444</po: customer. Ref> <po: ship. To> <addr: Street. Address> <addr: number>1421</addr: number> <addr: street>Plane Avenue</addr: street> <addr: town>1421</addr: town> </addr: Street. Address> </po: ship. To> <po: line. Item> <po: Item> <prod: code>TYW-65523 -GB</prod: code> <prod: color>TYW-65523 -GB</prod: color> <po: quantity>15</po: quantity> </po: Item> </po: line. Item> </po: Purchase. Order> </rdf: RDF> Telecom and Informatics
Ontology Web Language (OWL) A more expressive ontology language Concepts (classes) can be described or defined described – necessary conditions given defined – necessary and sufficient conditions given Builds on RDF and can be expressed in several ways: RDF XML-based syntax abstract syntax graphic UML-like Has three sub-languages: OWL Full OWL Description Logic (DL) – maps to a DL, a subset of predicate logic OWL lite – for simple taxonomies (class hierarchies) Telecom and Informatics
Logical languages for the Semantic Web OWL Web Ontology Language (sometimes called Ontology Web Languagea) language developed by the W 3 C's Web Ontology Working Group and intended to be the successor of DAML+OIL. OWL is the most expressive knowledge representation for the Semantic Web so far. OWL has three levels of language: OWL Lite, OWL DL (for description logic), and OWL Full. These three levels are in increasing order of expressivity. Telecom and Informatics
Logical languages for the Semantic Web RDF/RDFS The first language (RDF) expresses instance-level semantic relations phrased in terms of a triple: <subject, verb, object>, i. e. , <object 1, relation 1, object 2>. The second (RDFS) expresses class-level relations describing acceptable instance-level relations. RDF/RDFS is considerably less expressive than OWL and DAML+OIL Telecom and Informatics
Logical languages for the Semantic Web An example of the reasoning possibilities of the logical languages <owl: Property rdf: ID=“head”> <rdf: sub. Property. Of rdfs: resource=“member” /> </owl: Property> <owl: Class rdf: ID=“Terrorist”> <owl: same. Class. As> <owl: Restriction> <owl: on. Property rdf: resource=“member” /> <owl: some. Values. From rdf: resource=“Terrorist. Org” /> </owl: Restriction> </owl: same. Class. As> </owl: Class> The head of an organization is also a member of it ¨ A member of a terror organization is a terrorist ¨ Therefore, the head of a terror organization is a terrorist ¨ Henri Parot type Terrorist head ETA type Telecom and Informatics Terror. Org
Metamodel for RDFS Classes Telecom and Informatics
Metamodel for OWL Classes Telecom and Informatics
Metamodel for OWL Restrictions Telecom and Informatics
Metamodel for OWL Properties Telecom and Informatics
Metamodel for OWL Individuals Telecom and Informatics
OWL Purchase. Order <rdf: RDF xmlns: rdf="http: //www. w 3. org/1999/02/22 -rdf-syntax-ns#" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema#" xmlns: rdfs="http: //www. w 3. org/2000/01/rdf-schema#" xmlns: owl="http: //www. w 3. org/2002/07/owl#" <owl: Class rdf: ID="Purchase. Order. Line"> <rdfs: sub. Class. Of> <owl: Class rdf: ID="Priced. Line"/> </rdfs: sub. Class. Of> <rdfs: comment rdf: datatype=http: //www. w 3. org/2001/XMLSchema#string> Inherits from Line and contains information related to delivery. </rdfs: comment> </owl: Class> <owl: Object. Property rdf: ID="changes. Line. Value"> <rdfs: range rdf: resource="#Amount"/> <rdfs: domain rdf: resource="#Priced. Line"/> </owl: Object. Property> </rdf: RDF> Telecom and Informatics
OWL versus UML In OWL and not in UML Explanation Thing, global properties, autonomous individual In OWL, instances as well as some relations (in owl, relations are called properties), can exist without being attached to certain class. This is due to the fact that OWL is based on sets while UML is based on types. Instances and relations in OWL can be a subset of the universal class Thing or binary relation between two Things. Class-specific cardinality redefinition As OWL properties can be declared independent of classes, they can have different cardinality definitions when applied to different classes. all. Values. From, some Values. From “In OWL, property can have its range restricted when applied to particular class, either that the range is limited to a class (subclass of range if declared) (all. Values. From) or that range must intersect a class (some. Values. From). ” [28] Symmetric. Property, Transitive. Property OWL allows properties to be declared symmetric or transitive. In both cases the domain and range must be type compatible. Classes as instances In UML or MOF defined languages, there is a strict separation of metalevels so that population of M 1 classes is distinct from the population of M 2 classes. In OWL full, one class can be an instance of another class, a characteristic inherited form RDF. In OWL DL, this usage is restricted. Telecom and Informatics
UML Ontology profile Telecom and Informatics
Semantic Web Services and SOA Telecom and Informatics
Service Web Telecom and Informatics 39
Semantic web service technologies OWL-S (was DAML-S, US) WSMO (Europe, DERI, STI, OASIS) WSDL-S (basis for SAWSDL) SAWSDL (W 3 C standard) Telecom and Informatics 40
OWL-S Ontology OWL-S is an OWL ontology to describe Web services OWL-S leverages on OWL to Support capability based discovery of Web services Support automatic composition of Web Services Support automatic invocation of Web services "Complete do not compete" OWL-S does not aim to replace the Web services standards rather OWL-S attempts to provide a semantic layer OWL-S relies on WSDL for Web service invocation (see Grounding) OWL-s Expands UDDI for Web service discovery (OWL-S/UDDI mapping) 41 Telecom and Informatics
OWL-S Upper Ontology • Capability specification • General features of the Service • Quality of Service • Classification in Service taxonomies • Mapping to WSDL • communication protocol (RPC, HTTP, …) • marshalling/serialization • transformation to and from XSD to OWL • Control flow of the service • Black/Grey/Glass Box view • Protocol Specification • Abstract Messages 42 Telecom and Informatics
The Web Service Modeling Ontology (WSMO) Telecom and Informatics 43
WSMO – Web Service Modeling Ontology WSMO working group includes the WSML working group, which aims at developing a language called Web Service Modeling Language (WSML) that formalizes the Web Service Modeling Ontology (WSMO). WSMO: an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Taking the Web Service Modeling Framework (WSMF) as a starting point, we refine and extend this framework, and develop an ontology and a description language. WSML: aims developing a language called Web Service Modeling Language (WSML) that formalizes the Web Service Modeling Ontology (WSMO). Hereby, we have a two fold mission: a) developing a proper formalization language for semantic web services and b) providing a rule-based language for the semantic web Telecom and Informatics 44
WSMF [consists of four different main elements for describing semantic Web Services: (1) ontologies that provide the terminology used by other elements, (2) goals that define the problems that should be solved by Web Services, (3) Web Services descriptions that define various aspects of a Web Service, and (4) mediators which bypass interpretability problems. Telecom and Informatics 45
WSMO Web Service Description Model Telecom and Informatics 46
www. wsmo. org WSMO Working Groups Conceptual Model & Axiomatization for SWS WSMO STI 2 CMS WG WSML WSMX Formal Language for WSMO Ontology & Rule Language for the Semantic Web SEE TC Execution Environment for WSMO Telecom and Informatics 47
Lifecycle Discovery find candidate WS to solve a Goal Selection & Ranking select best candidate / determine a priority list Composition combine several WS to solve a Goal Behavioral Compatibility ensure that interaction can take place Mediation resolve & handle possibly occurring heterogeneities Execution automatically invoke & consume WS to solve a Goal Telecom and Informatics 49
Semantically-Enabled Service-oriented Architecture Telecom and Informatics 50
SAWSDL - Semantic Annotations for WSDL and XML Schema W 3 C Standard August, 2007 This specification defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how such semantic annotation is accomplished using references to semantic models, e. g. ontologies 3 constructs: model. Reference, lifting. Schema. Mapping, lowering. Schema. Mapping Telecom and Informatics 51
A Web Service Composition Scenario with Ontology Reasoning Telecom and Informatics 52
Semantic Annotations for WSDL and XML Schema W 3 C Working Draft 10 April 2007 This specification defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how such semantic annotation is accomplished using references to semantic models, e. g. ontologies. SAWSDL does not specify a language for representing the semantic models. Instead it provides mechanisms by which concepts from the semantic models, typically defined outside the WSDL document, can be referenced from within WSDL and XML Schema components using annotations. Telecom and Informatics 53
Semantic Annotation Telecom and Informatics
Semantic Annotation Process overview Reference Ontology Invoice RDF) ACME RFQ ……………. . Item. Proce Totla VAT Annotated resource ( Net. Price Build an annotation expression • Building an annotation expression: 1. 2. • Using an existing concept of RO or Creating a new concept by composing elements of RO Linking the annotation expression to the resource Link Annotation expression { x|9 y(Invoice(x) ^has. Total(x, y)^Total(y)) } Telecom and Informatics
COIN Semantic toolset - streamline for semantic interoperability Telecom and Informatics 56
ARGOS: a Transformation Rules Building tool A graphical environment supporting a user in defining transformation rules guided by Document model Annotations Reference Ontology A set of Rule Templates using an abstract but expressive syntax An intuitive interface supports the user in parametrising transformation automatically transformed by Instantiated Rules aretemplates (Rule Templates) ARGOS into executable code (Jena rules) for the reconciliation engine (ARES) Telecom and Informatics
ARGOS: Rule Templates The most common kinds of interoperability clashes occurring within documents have been analysed Clashes can be solved applying Transformations consisting of one ore more Rule Templates Main ARGOS Rule Templates: Merge Split Map. Value Convert Sum Mult Telecom and Informatics
Ontology-based reconciliation Enterprise A SW App Reference Ontology Semantic Mediation and Reconciliation Platform Local Data Semantic Annotation Reconciliation Rules Local Schema Enterprise B SW App Reconciliation Rules Customized MRE Design phase Run-time phase FWD transf BWD transf Interch. Repres. BWD transf FWD transf Customized MRE Telecom and Informatics Local Schema Local Data
Example of Mismatch Enterpr. B (Supplier) Enterpr. A (Buyer) Sale Order Purchase Order • • • Order_Number Order_Date Buyer_Info – – Name Address • • – • Product_Code Description Quantity Price (unitary) Currency (Dollar, Euro, Pound) Charge Requested. Delivery. Date Organization_Name Contact_Person Location – – • • • Area_Code Number Ext Client_Order_Number Order_Lines – – • • Street_Address City Lo. Code Country Phone_Number – – – Telephone Products_Info – – • • • Street_Name Street_Num City_Post_Code Country • • Product_Code Description Quantity Price (total per line) Currency (USD, Euro, Yen) Total Telecom and Informatics Structuring
Ontology-based Reconciliation Approach Address Location Country Street_Address Street_Name Country City-Post_Code City Lo. Code Street_Number Street Snum Reference Ontology City Zip_Code Country Telecom and Informatics
Example of actual reconciliation Local Schema (LS) Reference Ontology (RO) Purchase Order (PO) … Address … City-Post_Code: literal Address [ … City : literal Zip_Code: literal ] Structuring Clash Semantic Annotation Reconciliation Rule Run-time Reconciliation LS. PO. Address. City-Post_Code =: RO. Address. City AND RO. Address. Zip_Code unpack(LS. PO. Address. City-Post_Code, “-”) (RO. Address. City, RO. Address. Zip_Code) {“Rome - 00185”} {“Rome”, “ 00185”} Telecom and Informatics
From Semantic Annotation to Transformation Rules AIDIMA order RO Split order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name >: Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part _First. Name Å Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part _Surname SSAX SPLIT order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name INTO Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_First. Name Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_Surname Telecom and Informatics Forward Transf Rule
An example of Transformation Rule in the Jena 2 syntax SPLIT order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name INTO Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_First. Name Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_Surname Name. Splitting: [(? x 0 rdf: type ai: order) (? x 0 ai: has_order. Header ? x 1) (? x 1 rdf: type ai: order. Header) (? x 1 ai: has_buyer. Info ? x 2) (? x 2 rdf: type ai: buyer. Info) (? x 2 ai: has_organization. Info ? x 3) (? x 3 rdf: type ai: organization. Info) (? x 3 ai: has_contact. Person ? x 4) (? x 4 rdf: type ai: contact. Person) (? x 4 ai: has_name ? x 5)] Forward Transf Rule in the Jena 2 syntax [(? x 0 rdf: type ro: Purchase. Order_BOD) (? x 0 ro: rel. To_Buyer ? x 2) (? x 2 rdf: type ro: Buyer_BA) (? x 2 ro: rel. To_Contact. Person ? x 4) (? x 4 rdf: type ro: Contact. Person_BA) Split(? x 4, “ ”, ? y 1, ? y 2, 'http: //www. w 3. org/2001/XMLSchema#string') (? x 4 ro: has. Part_First. Name ? y 1) (? x 4 ro: has. Part_Surname ? y 2)] Telecom and Informatics
From Semantic Annotation to Transformation Rules AIDIMA order RO Split order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name >: Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part _First. Name Å Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part _Surname SSAX SPLIT order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name INTO Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_First. Name Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_Surname Telecom and Informatics Forward Transf Rule
An example of Transformation Rule in the Jena 2 syntax SPLIT order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name INTO Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_First. Name Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_Surname Name. Splitting: [(? x 0 rdf: type ai: order) (? x 0 ai: has_order. Header ? x 1) (? x 1 rdf: type ai: order. Header) (? x 1 ai: has_buyer. Info ? x 2) (? x 2 rdf: type ai: buyer. Info) (? x 2 ai: has_organization. Info ? x 3) (? x 3 rdf: type ai: organization. Info) (? x 3 ai: has_contact. Person ? x 4) (? x 4 rdf: type ai: contact. Person) (? x 4 ai: has_name ? x 5)] Forward Transf Rule in the Jena 2 syntax [(? x 0 rdf: type ro: Purchase. Order_BOD) (? x 0 ro: rel. To_Buyer ? x 2) (? x 2 rdf: type ro: Buyer_BA) (? x 2 ro: rel. To_Contact. Person ? x 4) (? x 4 rdf: type ro: Contact. Person_BA) Split(? x 4, “ ”, ? y 1, ? y 2, 'http: //www. w 3. org/2001/XMLSchema#string') (? x 4 ro: has. Part_First. Name ? y 1) (? x 4 ro: has. Part_Surname ? y 2)] Telecom and Informatics
Semantic SOA Telecom and Informatics
Semantic SOA: Discovery / Selection Service X Goal No match Semantic SOA Vision Application Composition based Discovery Goal Service Y Potential candidate Selection on existing building blocks (services) Business Process Flexibility Ranking/ Composition Service Y Concrete Task Requirements Potential candidates Discovery of appropriate candidate services Service Z Selection of the best matching service An Approach for Solution Semantic annotation of service capabilities and requestor’ goals Unambiguous, machine-interpretable formalizations Advantages Business context & data ontologies (Semi-)automatic discovery of candidate services (Semi-)automatic integration of new services Self-adaptable business processes through automatic selection of services Telecom and Informatics 68
Semantic SOA: Mediation Semantic SOA Vision Application Composition based on existing building blocks Requirements Integration of different services Mapping between different message formats An Approach for Solution Semantic annotation of message formats using ontologies Unambiguous, machine-interpretable formalizations Business data ontologies Advantages Semi-automatic creation of necessary transformations Reduced development effort Simplified integration of legacy systems/applications Telecom and Informatics 69
Semantic SOA: Composition Semantic SOA Vision Business Collaboration Ontology Business Process Capability Sales Order Processing Flexibility Requirements Defining placeholders for process steps Matching of business contexts Describing data compatibility Goal Order Process Matching & Mediation Web Service Capability I Purchase Order Processing I Purchase Order I Web Service Capability II Purchase Order Processing Goal Purchase Order II Invoice Processing Invoice An Approach for Solution Goals as placeholders Service semantics described by ontologies Unambiguous, machine-interpretable formalizations Business context & data ontologies (static aspects) Business collaboration ontology (behavioral semantics) Advantages Reasoning allows for automatic composition of processes Automatic integration of new services Self-adjusting business by using placeholders Telecom and Informatics 70
Semantic SOA Discovery/Selection, Mediation, and Composition benefit from using Semantics ‘SOA isn‘t enough’ Semantics – prerequisite for Semantic SOA Telecom and Informatics 71
Conclusion and outlook Support for semantics with ontologies and mediation is available now Short term benefit can be gained in the area of services for semantic interoperability – through the use of ontologies, and use of mappings and transformations for information and service interoperability i. e. – start here from an industrial perspective, establish ontologies, use these directly or mediate through semantic annotation. Semantic Web Services and Service-oriented Semantic Architectures (SESA) is a promising future technology Longer term benefits can be expected related to matching goals with services for process and service composition and process interoperability Telecom and Informatics 72
Скачать презентацию INF 5120 Modellbasert Systemutvikling F 13 Model Driven
a8ec2c7cbff5b706fb1fbdf87d85e092.ppt