inf5120 – modellbasert systemutvikling

ICT

INF5120 – Modellbasert Systemutvikling

F12: Model Driven Interoperability and Service Interoperability

Lecture 11.04.2011

Arne-Jørgen Berre

ICT

Agenda

Oblig 2b)

Model Driven Interoperability Intro and 2 articles on MDI

MDI – article 3, A Model-driven Approach to Interoperability in B2B Data Exchange, (Brice Morin, SINTEF)

ICT

Oblig 2b) MDI – ModelDriven Interoperability Write a description on how you could use an MDI (Model Driven

Interoperability, ref. latest lectures) approach in order to deal with semantic and technical interoperability – when integrating your designed part of the Smart House system with an existing system

Voluntary extension parts for potential discussion: Model driven user interfaces (Applause) for iPhone/Android-

http://www.ralfebert.de/blog/xtext/applause_new_app/ RedSeeds – Model driven use case based development -

http://redseeds.iem.pw.edu.pl/ Lego NXT-G domain specific language for sensors and actuators – describe how you

could have related to models in the NXT-G language - http://www.ortop.org/NXT_Tutorial/

Could any of the model based approaches be useful for your Oblig 2 work ?

3

ICT

Article 1:Organizational interoperability

supported through goal alignment with BMM and service collaboration with

SoaML

I-ESA 2009 paper

Han Fenglin, NTNU

Arne J. Berre, SINTEF

Espen Møller, Oslo University Hospital 22. April. 2009

4

fenglin Han

correct date April 22ndAll authors of the paper, with affiliation, ...

ICT

Article 2:Model Driven Service Interoperability through use of Semantic Annotations

I-ESA 2009 paperArne-Jørgen Berre

Fangning LiuJiucheng Xu

Brian ElvesæterSINTEF ICT

ICT

Article 3:A Model-driven Approach to

Interoperability in B2B Data Exchange

I-WEI 2011 paperDumitru Roman

Brice MorinArne-Jørgen Berre

SINTEF ICT

ICT

Introduction

Organizations are collaborating with other organizations in order to meet their business objectives.

For business optimization, organizations re-structure their business realizations by creating new constellations within an enterprise and across the organizational border that need to interoperate.

Key issue: service network, who is to produce the service, who is to consume the service ， business goals.

It seems BMM and SoaML can combine these issues through: Align goals with service-centric approach.

ajberre

SoaML - small letters in Soa

ICT

Interoperability Framework

ATHENA Interoperability Framework ( each system is described by enterprise models and different viewpoints, such as business, process, service, information)

ajberre

Refer to the ATHENA in the context of the I-ESA conference (originator of theconf.series) , and previous paper

ajberre

Define "Organisational Interoperability" related to this picture !!!! - i.e. Business Interoperability

ICT

EIF version 2.0 (2009)European Interoperability Framework

ICT

Definition: Interoperability(Revised in 2008 in EIF v2, to include common goals !)

ICT

EIF - Dimensions of Interoperability

ICT

Interoperability chain and levels

ICT

Interoperability levels

ICT

Reference model for Interoperability- Link to areas in IT architecture

Admin, Business, Citizen A

Organisationalinteroperability

Semanticinteroperability,

InformasjonsInnhold med mening for:

Technicalinteroperabilitet

(Technicallstandards)

PresentationProcess, rules

ServicesInformation/Data


ServicesData

CommunikasjonAdm/Metadat

SecurityTechn. sem/org

WorkprocessGoals

OrganisationProduct

Concepts

Communikation

Organisational harmonisation,in particular around process

Shared understanding of the meaning/semantics i innhold ved

bruk av teknologier forpresentasjon/prosess/tjeneste/data

Interoperable technologies

Organisational interoperability

Semantic interoperability

Technical interoperability

T. sem/org. mod.

Sikkerhet

Adm/ Metadata

Kommunikasjon

Data

Tjenester

Prosess

Presentasjon

T. sem/org. mod.

Sikkerhet

Adm/ Metadata

Kommunikasjon

Data

Tjenester

Prosess

Presentasjon

T. sem/org. mod.

Sikkerhet

Adm/ Metadata

Kommunikasjon

Data

Tjenester

Prosess

Presentasjon

T. sem/org. mod.

Sikkerhet

Adm/ Metadata

Kommunikasjon

Data

Tjenester

Prosess

Presentasjon

Admin, Business, Citizen B









ServicesData



WorkprocessGoals

OrganisationProduct

Concepts

Communikation

ICT

Reference model for Interoperability vs IDAbc EIF version 1

Organisational Interoperablilitet

Semantic Interoperability

Technical Interoperability

Admin, Business, Citizen A









ServicesData



WorkprocessGoals

OrganisationProduct

Concepts

Communikation

Organisational interoperability

Semantic interoperability

Technical interoperability

Admin, Business, Citizen B









ServicesData



WorkprocessGoals

OrganisationProduct

Concepts

Communikation

ICT

Model Driven Interoperability

ICT 17

Current MDA Interoperability Architecture

CIM/EMmodels

PIMSystemmodels

PSMSystemmodels

System

Ref.ontologySemantic

annotation

Semanticannotation

Semanticannotation

CIM/EMmodels

PIMSystemmodels

PSMSystemmodels

System

Semanticannotation

Semanticannotation

Semanticannotation

Sem.mapping

Technicalmapping

Interoperabilityexecution

IF IF

ICT

Run-time

SemAnnot

Set#2

InternetSemRec

Rules#2

Local

Software &

Data

SwApp#1

Local

Software &

Data

SwApp#2Sem

AnnotSet#1

SemRec

Rules#1

ReferenceOntology

Architecture for semantic annotation and reconciliation

Reconciliation

Design-time

ICT

Contents

Introduction Description of EMPOWER and MEMPOWER

EMPOWER Project MEMPOWER Project

Comparison Semantic mappings Conclusion & Further work

ICT

EMPOWER

an innovative framework for interoperability between enterprise systems

a flexible and extensible architecture a system environment

System Interoperability LayerInteroperable

Enterprise Service

Designer

Wrapper Definition and Customization

Web Services Repository

Semantic Adaptation Layer

(2)Services Semantic

Annotator(SAWSDL)

(3)Ontology Handling

Utilities(OWL)

(5)Transformations Creator

Interoperable Enterprise Service

Wrapper

Mediator Services Web Server

Semantic Services Registry

Transformations Repository

ModelRepository

Legacy System Wrappers

Legacy Systems

(1)WSDL, OWL-S, WSML (4)Semantic Map

ICT

a Model Driven variant of EMPOWER, Compare with advantages and disadvantages of Model

Driven Interoperability

MEMPOWER

System Interoperability Layer

SemaphoreWrapperWeb Services Repository

(1)Model Mapping (SoaML)

Legacy System Wrappers

Legacy Systems

(4)Model Map

Semantic Adaptation Layer

(2)SAM (3)ODM

(5)Model Transformation

ServicesWrapper

Mediator Server

Semantic Services Registry Transformation

s Repository

ModelRepository

Ontology Definition Meta-model is a family of MOF meta-models,

mappings between those meta-models, and a set of profiles that

enable ontology modeling through the use of UML-based tools.

Ontology Definition Meta-model is a family of MOF meta-models,

mappings between those meta-models, and a set of profiles that

enable ontology modeling through the use of UML-based tools.

SoaML describes the services models. The Model Mapping in the MEMPOWER includes transformations from models to

ontology and ontology to models.

SoaML describes the services models. The Model Mapping in the MEMPOWER includes transformations from models to

ontology and ontology to models.

Semantic Annotation Model editor is used to relate different PIM models and ontology. It is used to annotate

the SoaML model with Ontology.

Semantic Annotation Model editor is used to relate different PIM models and ontology. It is used to annotate

the SoaML model with Ontology.

Model Transformation Services support the runtime lifting and lowering transformations among messages and ontologies based on the Model Map.

Model Transformation Services support the runtime lifting and lowering transformations among messages and ontologies based on the Model Map.

Model Map stores mapping rules.Model Map stores mapping rules.

ICT

The EMPOWER Enterprise Interoperable Services Semantic Map

22

ICT 23

SemanticAdaptation Architecture

ICT

PIM level use of Ontology mappings

24

ICT

Use of SoaML for PIM modeling

25

ICT

SAM – Semantic Annotations tools

26

(SASO: semantic annotation tool using SoaML and ODM)

ICT

Ontology example

27

ICT

Address Ontology

28

ICT

Address in Source and UML

29

ICT

“Address” in the source and target transformation rules

30

ICT

“Address” transformations from source.xml and target.xmi

31

ICT

SAM editor realized in tree views

32

ICT

Interface of demoInterface of demo

A simple example of class annotations on the PIM

level

A simple example of class annotations on the PIM

levelAnnotationsAnnotations

Ontology is represented as a structured and classified tree view. It

shows the properties and relationships between those classes.

Ontology is represented as a structured and classified tree view. It

shows the properties and relationships between those classes.

ICT

<soaml:Class name="POMessage” saName=“PurchaseOrderMessage” soaml:sterotype="messageType">

</soaml:Class> <soaml:Class name="Customer" saName=“Customer”

soaml:sterotype="DataType"> <soaml:Attribute name="customerId" saName=“hasCompanyRegNo”

type="String" modifier="public" /> <soaml:Attribute name="name" saName=“hasComanyName”

type="Name" modifier="public" /> <soaml:Attribute name=“address“ saName=“hasAddress”

type="String" modifier="public" /> <soaml:Attribute name=“creditScore" type="Integer" modifier="public" /> </soaml:Class>

<soaml:Class name="POMessage” saName=“PurchaseOrderMessage” soaml:sterotype="messageType">

</soaml:Class> <soaml:Class name="Customer" saName=“Customer”

soaml:sterotype="DataType"> <soaml:Attribute name="customerId" saName=“hasCompanyRegNo”

type="String" modifier="public" /> <soaml:Attribute name="name" saName=“hasComanyName”

type="Name" modifier="public" /> <soaml:Attribute name=“address“ saName=“hasAddress”

type="String" modifier="public" /> <soaml:Attribute name=“creditScore" type="Integer" modifier="public" /> </soaml:Class>

After annotating and exporting the model, you will get the file with a additional attribute. The annotations are displayed in red.

ICT

Semantic Mapping

1. Ontology-based mapping on the PSM-Level (EMPOWER) 2. Direct mapping on the PSM-Level 3. Ontology-based mapping on the PIM level(MEMPOWER) 4. Direct mapping on the PIM level

1 2 3 4

Approach Ontology-based PSM

Direct mapping PSM

Ontology-based PIM

Direct mapping PIM

ICT

Example: Address

Address in Target.xsd has only

one elements: Address

Address in Target.xsd has only

one elements: Address

Address in Source.xsd is divided into three elements: Address, Place, and Province

Address in Source.xsd is divided into three elements: Address, Place, and Province

Address in Ontology is divided into three

elements: Address, Region, and Province

Address in Ontology is divided into three

elements: Address, Region, and Province

ICT

1.PSM: Ontology-based Annotation based on ontology on the PSM-level

--Annotate source.xml and target.xml using Ontology

OntologyOntology

Source.xmlSource.xml

Address annotationAddress

annotation

ICT

2.PSM: Direct Mapping Mapping without ontology on the PSM-level

--Map between source.xml and target.xml (xsl:easy)

Target.xmlTarget.xml

Source.xmlSource.xml

ICT

3.PIM: Ontology-based 1.Transformation From PSM level to PIM level

--Generate sources.uml and target.uml from schemas (HyperModel Designer 3.1)

Address in Source.xsdAddress in Source.xsd

Address in Source.uml corresponds to

Source.xsd

Address in Source.uml corresponds to

Source.xsd

ICT



2.Mapping Between Models based on ontology on the PIM level

Step 1: Generate meta-models of models and ontology using

EMF

Step 1: Generate meta-models of models and ontology using

EMF

ICT




Step 2:Create mapping rules from source to ontology, and ontology to

target using ATL

Step 2:Create mapping rules from source to ontology, and ontology to

target using ATL

Ontology-Target

Ontology-Target

Source-OntologySource-Ontology

ICT


--Generate sources.uml and target.uml from schema (HyperModel Designer 3.1)


Step3: Transform source into ontology and ontology into

target

Step3: Transform source into ontology and ontology into

target

ICT

Transformation Between Models without ontology on the PIM level

--Use Semaphore tool to map source to target

4.PIM: Direct Mapping

Source.umlSource.uml

Target.umlTarget.uml

ICT

Conclusion

Ontology -based mapping (S-O-T) VS Direct mapping (S-T) on the PIM level 2N vs N²

Mapping between all model pairs will result in

N-squared mappings

Mapping between each model and ontology will result a linear growth of

number of mappings

Standard OntologyStandard Ontology

ICT

Conclusion

Mapping PIM-Level VS PSM-Level

Ontology-basedPSM

Direct mapping PSM

Ontology-basedPIM

Direct mapping

PIM

Mapping 2N N² 2N N²

StandardOntology

Y N Y N

PlatformIndependent

N N Y Y

Multi-source documents

Input

N N Y Y

Multi-target documents

Output

N N Y Y

ICT

Conclusion & Further work

Conclusion Ontology-based semantic annotations reduces mapping times

from N-squared to 2N, but cost is a standard ontology. Model Driven approach supports the interoperability independent

from platform technologies, compared to a platform specific technical approach.

Further work Implement multiple industrial use cases with five scenarios for

comparing EMPOWER and MEMPOWER.

ICT

Another example of Ontology-based Service: Message Reconciliation

ICT

Ad hoc reconciliation vs Ontology-based Reconciliation

Ad-Hoc Based on ad hoc adapters between pair of partners Not scalable respect to the growing of the number of partners

Ontology-based Highly independent solution, the semantic annotation does not

depend on the other business partners Highly scalable, the complexity of the Semantic Annotation

does not depend on the cardinality of the partners

ICT

Ontology-based reconciliation

Local Schema Local Schema

Enterprise A Enterprise B

SemanticAnnotation

SemanticAnnotation

ReconciliationRules

CustomizedMRE

CustomizedMRE

ReconciliationRules

Local Data Local Data

Design phase

Run-time phase

Interch.Repres.

Reference

Ontology

FWD transf BWD transf

BWD transf FWD transf

SW App SW App

Semantic Mediation and Reconciliation

Platform

Semantic Mediation and Reconciliation

Platform

ICT

Lossless and Lossy Annotations Lossless SA: when the annotation fully captures the intended

meaning A Local Schema (LS) element corresponds exactly to a concept in

the RO The meaning of a LS element can be precisely derived from

concepts in the RO

Lossy SA: when the annotation fails to fully representing the intended meaning The meaning of a LS element does not have a matching concept in

the ontology, nor the possibility of deriving it, since:- the intended meaning is outside the scope of the RO- The LS elem is not sufficiently refined (i.e., it does not match the

accuracy level of e ontology) [underspecification]- The LS element presents a level of refinement not deemed useful

[overspecification]

ICT

Example of Mismatch

Structuring

Purchase Order

• Order_Number

• Order_Date

• Buyer_Info– Name

– Address• Street_Name• Street_Num• City_Post_Code• Country

– Telephone

• Products_Info– Product_Code

– Description

– Quantity

– Price (unitary)

• Currency (Dollar, Euro, Pound)

• Charge

• RequestedDeliveryDate

Sale Order

• Date• Organization_Name• Contact_Person• Location

– Street_Address– City– LoCode– Country

• Phone_Number– Area_Code– Number– Ext

• Client_Order_Number• Order_Lines

– Product_Code– Description– Quantity– Price (total per line)

• Currency (USD, Euro, Yen)• Total

EnterprA (Buyer) EnterprB (Supplier)

ICT

Ontology-based Reconciliation Approach

Address

Street SnumCountryZip_Code

Location

Street_Address

Reference Ontology

City

Street_Name

Street_Number

City-Post_Code

Country

LoCode

Country

City

ICT

Local Schema (LS) Reference Ontology (RO)

Purchase Order (PO)…Address … City-Post_Code: literal

Address [ … City : literal Zip_Code: literal ]

Structuring Clash

Example of actual reconciliation

LS.PO.Address.City-Post_Code =:

RO. Address.City AND RO.Address.Zip_Code

Semantic Annotation

unpack(LS.PO.Address.City-Post_Code, “-”)

(RO.Address.City, RO. Address.Zip_Code)Reconciliation

Rule

{“Rome - 00185”} {“Rome”, “00185”}Run-time Reconciliation

ICT

…

<xsd:element name=“Address”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“Street_Name” type=“xsd:string”/>

<xsd:element name=“Street_Number” type=“xsd:positiveInteger”/>

<xsd:element name=“City-Post_Code” type=“xsd:string”/>

<xsd:element name=“Country” type=“xsd:string”>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

…

…<owl:Class rdf:ID=“Address”/>

<owl: DatatypeProperty rdf:ID=“Street”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Snum”> <rdfs:domain rdf:resource=“Address”/>

<rdfs:range rdf:resource=“&xsd;positiveInteger”/></owl: DatatypeProperty>

<owl: DatatypeProperty rdf:ID=“City”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Zip_Code”>

<rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Country”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty>…

Local Schema (XML Schema) Reference Ontology (OWL)

ICT

From Semantic Annotation to Transformation Rules

order.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson. hasPart _FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart _Surname

>:

AIDIMA order

RO

orderorder

orderheaderorder

header

productsinfo

productsinfo

supplierinfo

supplierinfo

buyerinfo

buyerinfo

orginfoorginfo

contactpersoncontactperson namename

orgNameorgName

addressdetails

addressdetails

productrecord

productrecord

descriptiondescription

productCodeproductCode

quantityquantity

……

……

……

buyerOrderNumberbuyerOrderNumber

……

……

orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


PurchaseOrderPurchaseOrder

OrderLineOrderLine

IDID IssueDateIssueDate

BuyerBuyer

SupplierSupplier

ContactPerson

ContactPerson

SurnameSurnameFirstNameFirstName

ProductProduct

LinePriceLinePriceQuantityQuantity

BOD BOD

AA AA

BODAA

BA

CABA

BA

AA

AA

DescriptionDescriptionAA

NameNameAA

YearYearAA

MonthMonthAA


BuyerBuyer

ContactPerson

ContactPerson



BuyerBuyer

ContactPerson

ContactPerson


Split

SSAX

SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

INTOPurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname

ForwardTransf Rule

ICT

An example of Transformation Rule in the Jena2 syntax

NameSplitting: [(?x0 rdf:type ai:order) (?x0 ai:has_orderHeader ?x1) (?x1 rdf:type ai:orderHeader) (?x1 ai:has_buyerInfo ?x2) (?x2 rdf:type ai:buyerInfo) (?x2 ai:has_organizationInfo ?x3) (?x3 rdf:type ai:organizationInfo) (?x3 ai:has_contactPerson ?x4) (?x4 rdf:type ai:contactPerson)(?x4 ai:has_name ?x5)]

[(?x0 rdf:type ro:PurchaseOrder_BOD) (?x0 ro:relTo_Buyer ?x2) (?x2 rdf:type ro:Buyer_BA)(?x2 ro:relTo_ContactPerson ?x4) (?x4 rdf:type ro:ContactPerson_BA)Split(?x4, “ ”, ?y1, ?y2, 'http://www.w3.org/2001/XMLSchema#string')(?x4 ro:hasPart_FirstName ?y1) (?x4 ro:hasPart_Surname ?y2)]

SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_nam

eINTOPurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname

ForwardTransf Rule

Rule in the Jena2 syntax

ICT

Conclusion and outlook BMM can be used to support discussions on Organisational

interoperability 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

57

inf5120 – modellbasert systemutvikling

Documents