Telecom and Informatics INF5120 – Model-based System Development Lecture #13: Model-driven...

Telecom and Informatics

INF5120 – Model-based System Development

Lecture #13: Model-driven interoperability

April 27th, 2009

Arne J. Berre, SINTEF ICT

Based on material developed in the ATHENA (IST-507849), INTEROP (IST-508011), SHAPE, SWING, COIN and EMPOWER/MEMPOWER, JANUS-3 research projects.

Telecom and Informatics 2

Lecture plan - 2009

1: 19/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA (AJB)

2: 26/1: MS I: Business Process Modeling (CIM) - with BPMN and BMM (AJB), Objecteering UML Modeler 3: 2/2: MS II: UML2 and SysML, Objecteering SOA and Scope, – Collaboration /Component models 4: 9/2: MS III: SoaML I (PIM) and Requirements modeling , CIM->PIM and SoaML (AJB) 5: 16/2: MDE I: Metamodeling , DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (AJB) 6: 23/2: MS IV: SOA and Servicve Design, GRASP, Design and SOA Patterns (AJB ) 7: 2/3: MS V: Method Engineering and SPEM / EPF (BRE)

8: 9/3: MDE II: Model transformations with ATL, MOFScript and other technologise (GO) 9 :16/3:: MDE II: Code generation with MOFScript and other technologies (GO) 10: 23/3: MDE IV: SOA Web services, XSD, WSDL and BPEL (PSM) (BRE) 11: 30/3: MDI I: SoaML and Model Driven Interoperability I (AJB)

EASTER

12: 20/4: MDE V: Open ArchitectureWare and BPMN/BPEL with Websphere in practice, (Neil Loughrran, Ismar Slomic) 12: 20/4: Exercise: MagicDraw and ModelPro with SoaMLfor JEE/Web services in pracrtice (Weiqing Zhang) 13: 27/4: MDI II: Model Driven Interoperability - II - Semantic services (AJB) , Microsoft Oslo (Anthe Rugstad) 14: 4/5: Course summary and preparation for Exam 29/5 (AJB)

Exam: May 29th, 2009 (Friday) AJB – Arne J. Berre BRE – Brian Elvesæter GO – Gøran Olsen ARS – Arnor Solberg


OBLIG 2 – Delivery April 27th, Walk through Monday May 4th, 2009

Use MDA technology in Eclipse (with MOFScript) to generate code for web services (with WSDL, XML, and maybe BPEL), maybe also by using JEE, for the system that was specified in obligatory exercise 1. There might be a need for a further refinement of the models from obligatory exercise 1. The models must be transferred to Eclipse EMF by use of XMI as a basis for further transformation/generation.

Look at example for code generation (provisioning) from SoaML models in the new Cameo SOA+ and ModelPro for Eclipse code generation from MagicDraw and ModelDriven.org. This can be downloaded from www.magicdraw.com (license valid until July 1st 2009).

Discuss in what extent techniques from part III of the course (MDI - Model Driven Interoperability) can be used if our system shall integrate with another system which supports parts of the same functionality.


Course literature – available on web – updates available per May 4th, 2009

Material from all lectures and OBLIG

Some selected articles and documents, and subset of standard documents from OMG

Handbook: ”MDE with Objecteering for SOA” , Softeam and A.J. Berre

Handbook: ”Model Driven Engineering - MDE” , A.J. Berre & B. Elvesæter

Handbook: ”Service Oriented Architectures - SOA” , A.J. Berre & B. Elvesæter

Handbook: ” MDE4SOA with COMET-SE” , A.J. Berre & B. Elvesæter

Handbook: ” Model Driven Interoperability - MDI”, A.J. Berre & B. Elvesæter

Practical use of tools (OBLIG):

Objecteering - www.objecteering.com MOFScript -http://www.eclipse.org/gmt/mofscript/

BPMN – http://www.eclipse.org/stp/bpmn

EMF - http://www.eclipse.org/modeling/emf/

GMF - http://www.eclipse.org/gmf/

Papyrus UML2 - http://www.papyrusuml.org

ATL - http://www.eclipse.org/gmt/atl/ og http://www.modelbased.net/

JEE 5.0 - http://java.sun.com/javaee/technologies/


Exam

Case-based (ref. previous exams) All written material can be used

09-12 (3 hours) –

Friday 29 . May 2009


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

6

fenglin Han

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


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


Outline

Introduction Some existing interoperability framework(EIF) European SHAPE project (Service-Oriented Heterganeous

architecture and platform engineering) BMM SoaML Alignment with BMM and SoaML Other on going cases of SoaML and BMM


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


Introduction

BMM: Business motivation model The Business Motivation Model specification provides a scheme or

structure for developing, communicating, and managing business plans in an organized manner. Specifically, the Business Motivation Model does all of the following: • It identifies factors that motivate the establishing of business plans.• It identifies and defines the elements of business plans.• It indicates how all these factors and elements inter-relate. Among these elements are those that provide governance for and guidance to the business — Business Policies and Business Rules.

SoaML: Service-Oriented Architecture Modeling Language OMG-backed, meant to bring a new type of modeling capability to the service-

oriented world (talk in detail later).

ajberre

References to standard documents, and OMG.Status of the standards (FTF), our involvement


Reference

Latest BMM specification. Latest UPMS specification. SoaML community: http://www.soaml.org/

ajberre

Show the references in clear text,Move this slides up front


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


EIF version 2.0 (2009)European Interoperability Framework


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


EIF - Dimensions of Interoperability


Interoperability chain and levels


Interoperability levels


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


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


SHAPE project

20

UPMSUPMS


MDE for SOA / SHA – using OMG MDA principles

Flexible business models

Flexible business models

Interconnectedheterogeneous SOA platform

models

Interconnectedheterogeneous SOA platform

models

Heterogeneous SOA platforms

metamodels

Heterogeneous SOA platforms

metamodels

Business metamodelsBusiness

metamodelsflexible

Business ModelsBusiness

metamodels

Semantically -enabled

heterogeneous SOA model

Unified and standardised

metamodel for SOA & SHA

Transformationrules

Transformer(engine)

according to

according to

transformationengine

Transformationrules

Transformer(engine)

transformationengine


heterogeneous SOA platform

models


heterogeneous SOA platform metamodels

according to

EPCPOP*BPDM, BPMNBMM…

Heterogeneousservice platforms

WSAJXTAOGSAJACK, JADEWSMO, WSMX…

Executable businessprocesses

Service interfacesService contracts

Service enactmentBusiness rules

SLAsParameterized

services…

GoalsBusiness rules

Business processesBusiness services

E- contracts…

Executable artefactsXSD, WSDL, BPEL

Teams and plansResource

managementSemantic Web

Services…

Wh

at s

ervi

ce-

orie

nte

d a

spec

ts t

o ca

ptu

re in

mod

els

Wh

ich

met

amod

els

and

lan

guag

es t

o u

se

CIM

PIM

PSM

UPMSHA Agents

Grid

Semantic WebServices

ServiceVariability

WebServices

P2P

FlexibleBusiness Models

HeterogeneousPlatforms


From CIM to PIM with BMM and SoaML

SoaML

Core

Service Variability

PIM4WS-A

PIM4SWS

PIM4Agents

P2P/Grid/Components

SoaML-SHA

WSDL, WSMO, OWL- S, JACK, JADE, JXTA, OGSA, J2EE, CORBA

J2EE, NetWeaver, .Net, …

BPMN BPDM BMM EPC

PIMs for differentArchitectural Styles

Realization Technologies

PSMImplementation Models

CIMBusiness Models

PIMSystem Models

…


BMM

There are three main parts in the BMM. Firstly, an End comprises things that the enterprise aims at

achieving, for example Goals and Objectives. Secondly, the Means are what the enterprise will employ to

achieve Ends, for example Strategies, Tactics, Business Policies, and Business Rules.

Finally, Influencers can change the elements of the business plans through Assessments. The Ends, Means and Influencers are related to each other in order to answer the following fundamental question: What is needed to achieve what the enterprise wants to achieve?

ajberre

Show the BMM metamodel !!!


BMM and goal modeling

Objective: reduce in cost and time, while

ensuring sufficient quality of the analyses

Means Establish platform secure

exchange of information between health enterprises.

Consume analysis service with lowest cost and shortest process time with sufficient quality.

Influencers


BMM summary

The values of BMM: Secures a holistic assessment of

possible actions and consequences, from business goal, business processes to technology.

Simpler options for following up decisions critical to business. What decisions have been made? Who made these decisions? When were the decisions made?

Enables simpler communication across large enterprises, between people in leading roles.

Enhanced traceability between strategy and actions ensures quicker and more correct decisions. Why do we need to do something about this? Which decisions are necessary? What are our business requirements?

Right hand picture is the companies that support BMM in Norway and UK

ajberre

Other tool vendors ?,, IBM, Oracle, ....


SoaML Profile (part of SoaML - UPMS)

ajberre

Use SoaML - not UPMSReference to the OMG standard


Service models - health care examples

collaboration diagram used for representing contracts between the participants that interoperate.

ajberre

Make diagram larger - too small to see !!!


Service models - health care examples

Service network

ajberre

Make diagram larger - show demo from a tool ???


Goal alignment with BMM and service collaboration with SoaML

30

Figure on the left shows an example of a business motivation model that

captures the followingbusiness requirements concerning the

processing of purchase orders:· Establish a common means of

processing purchase orders.· Ensure orders are processed in a

timely manner, and deliver the required goods.

· Help minimize stock on hand.· Minimize production and shipping

costs This example of a BMM model shows

the business vision, the goals that amplify that vision, and the objectives that quantify the goals. It also shows the business mission, the strategies

that are part of the mission plan, and the tactics that implement the

strategies. Finally the strategies are tied to the goals they support.

The example also shows a Process Purchase Order contract that

formalizes the requirements into specific roles, responsibilities, and interactions. The Contract indicates what motivation elements it realizes

through MeansRealizations.


Conclusion

What we have done: We want to show the capability of SoaML in the organizational

interoperability level. The example is service identification from the Norwegian national Health ICT architecture.

What we want to convince: OMG standard BMM, SoaML can be used not only by business

people but also people in the public health and many other domains to reach agreement on the provided and required service, the goals matching them, which support the organizational interoperability.

31


Conclusion

We suggest a : Organisational Interoperability –by Goal alignment with BMM and service

collaboration with SoaML - requires mutually shared service related goals (ref. Recent EIF v2.0

definition) - we suggest to model goals with BMM and Services with SoaML, and to relate these by fulfillment relationship, in order to provide a concrete basis for the discussion and resolution of organisational interoperability.

More on the current status of the other development On going industrial cases include one from the Norwegian oil

company: StatoilHydro: Production and process optimization

cases One iron producing company from Germany:

Saarstahl -Manufacturing planning and control system, Creation and Optimization of Heats and Sequences,


Semantic Web andSemantic Web Services

OWL-S

WSMO

SAWSDL


The Tree of Knowledge Technologies (Extended fromTop Quadrant)

SAWSDL

EXPRESSISO 15926

CC

WSMOOWL-SWSDL-S


Semantic web service technologies

OWL-S (was DAML-S, US)

WSMO (Europe, DERI, STI, OASIS)

WSDL-S (basis for SAWSDL)

SAWSDL (W3C standard)

35

Telecom and Informatics36

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)

Telecom and Informatics37

OWL-S Upper Ontology

• 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

•Capability specification•General features of the Service

• Quality of Service• Classification in Service

taxonomies


The Web Service Modeling Ontology (WSMO)


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


WSMF

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.


WSMO Web Service Description Model


WSMO Working Groups

Conceptual Model & Axiomatization for SWS

Formal Language for WSMO

Ontology & Rule Language for the Semantic Web

Execution Environment for WSMO

www.wsmo.org

SEE TC

STI2 CMS WG

WSMO

WSML WSMX


Semantically-Enabled Service-oriented Architecture

Semantic Execution Environment (Machine A)

StakeholdersLayer

System Administrator

Developer Tools(ontology management,

monitoring, ...)

Applications(user tools, access portals, ...)

Network(internet, intranet, extranet)

Service Requesters Layer

DomainExpert

Problem Formulation Layer

Software Engineer

Domain Ontologies

Discovery Adaptation

CompositionOrchestration Mediation Grounding

Fault Handling Monitoring

Back-end System Z

BusinessService S3

BusinessService S4SEE

(Machine D)

Middleware Layer

SEE(Machine C)

Back-end System X

BusinessService S1

User 1 User 2

Exe

cutio

n M

an

age

me

nt

Sec

uri

ty

Reasoning CommunicationFormal Languages Storage

Service Providers Layer

vertical broker

base

Shared Message Space

SEE(Machine B)


SAWSDL - Semantic Annotations for WSDL and XML Schema

W3C 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

3 constructs: modelReference, liftingSchemaMapping, loweringSchemaMapping


Model Driven Interoperability(principle)


Run-time

SemAnnot

Set#2

Internet SemRec

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


Model Driven Service Interoperability through use of

Semantic Annotations

I-ESA 2009 paperArne-Jørgen Berre

Fangning LiuJiucheng Xu

Brian ElvesæterSINTEF ICT


Contents

Introduction Description of EMPOWER and MEMPOWER

EMPOWER Project MEMPOWER Project

Comparison Semantic mappings Conclusion & Further work


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


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 Transformations

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.


The EMPOWER Enterprise Interoperable Services Semantic Map

52


SemanticAdaptation Architecture


Interface of demoInterface of demo

A simple example of class annotations on

the PIM level

A simple example of class annotations on

the PIM level

Annotations

Annotations

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.


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


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


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


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

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

OntologyOntologySource.xmlSource.xml

Address annotationAddress

annotation


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


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




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





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



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


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


Contents

Introduction Description of EMPOWER and MEMPOWER Comparison Semantic mappings Conclusion & Further work


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 Ontology

Standard Ontology


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


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.


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)


Ontology-based Reconciliation Approach

Address

Street Snum CountryZip_Code

Location

Street_Address

Reference Ontology

City

Street_Name

Street_Number

City-Post_Code

Country

LoCode

Country

City


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


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)]




ForwardTransf Rule

Rule in the Jena2 syntax


swing.brgm.fr

•Application in SWING•Semantic Discovery of Geospatial services •Dealing with multilinguality (French, English, …)

•Cross-language term-matching demo

swing-project.org


An example of Ontology-based Service: Message Reconciliation


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


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


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]


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)


Ontology-based Reconciliation Approach

Address

Street Snum CountryZip_Code

Location

Street_Address

Reference Ontology

City

Street_Name

Street_Number

City-Post_Code

Country

LoCode

Country

City


…

<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)


Mapping and Transformation Rules


Tansformation Rules

Semantic Annotation as declarative specifications for mismatches solution a conceptual correspondence between resources and concepts in

the ontology

Tansformation Rules as a procedural specification for transforming ground resources (i.e., data) into ontology instances (forward transf.) and viceversa (backward transf.)

In Athena, the reconciliation platform is based on the Jena2 suite (an open-source reasoning platform produced by HP)

Rules are written in accordance with the Jena2 rules syntax The transformation Rules building is supported by the Argos

tool


ARGOS: a Transformation Rules Building toolA 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 templates (Rule Templates)

Instantiated Rules are automatically transformed by ARGOS into executable code (Jena rules) for the reconciliation engine (ARES)


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 MapValue Convert Sum Mult


Jena2 rule structure

The rule specification comprises: a name (optional), the rule’s identifier a list of antecendents, the rule’s body a list of consequents , the rule’s head

In forward-chaining: A rule is satisfied if the body is true Facts in the head of a satisfied rule are inferred

Antecedents ConsequentsName:

Example

[Uncle: (?a fatherOf ?b) (?a brotherOf ?c) -> (?c uncleOf ?b)]


Jena2 rule elements

Each element in the head or body can be a:TriplePattern: a triple of Nodes. A Node can be:

wildcard (*), variable (?x), uri or literal Functor:

in the head represents actions in the body represents builtin predicates.

A functor comprises a: name and a list of arguments (Nodes of any type but not functor). Functors are built-in (i.e., sum, difference) or user definied (i.e.,

stringConcatenation, stringSplitting). Rule

Embedded, therefore, in a rule


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


orgNameorgName

addressdetails

addressdetails

productrecord

productrecord

descriptiondescription

productCodeproductCode

quantityquantity

……

……

……

buyerOrderNumberbuyerOrderNumber

……

……

orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo



OrderLineOrderLine

IDID IssueDateIssueDate

BuyerBuyer

SupplierSupplier

ContactPerson

ContactPerson


ProductProduct

LinePriceLinePriceQuantityQuantity

BOD BOD

AA AA

BODAA

BA

CABA

BA

AA

AA

DescriptionDescriptionAA

NameNameAA

YearYearAA

MonthMonthAA


BuyerBuyer

ContactPerson

ContactPerson



BuyerBuyer

ContactPerson

ContactPerson


Split

SSAX




ForwardTransf Rule


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)]




ForwardTransf Rule

Rule in the Jena2 syntax


WSMO Mediation Heterogeneity as inherent characteristic of the Web:

heterogeneous terminology heterogeneous languages / formalisms heterogeneous functionalities heterogeneous communication protocols and business

processes

WSMO identifies Mediators as top level element levels of mediation: data, functional, protocol, processes WSMO Mediator types

Approach: declarative, generic mismatch resolution classification of possible & resolvable mismatches mediation definition language & mediation patterns execution environment for mediation definitions


WSMO Data Mediation Techniques

Ontology Alignment Ontology Mapping

Mapping Rules

Ontology Merging

Ontology A is made

compatible to ontology B

Ontology Integration Techniques

semi-automatic human intervention needed for “integration decision graphical support for ontology mapping as central technique


Ontology O2

Human - name

Adult Child

Person- name

- age

michael memberOf Person- name = Michael Stollberg

- age = 28

classMapping(unidirectional o2:Person o1.Adult attributeValueCondition(o2.Person.age >= 18))

this allows to transform the instance ‘michael’ of concept person in ontology O2 into a valid instance of concept ‘adult’ in ontology O1

Ontology O1

WSMO Mapping Language Example


Example of WSMO Mapping Rules<Alignment>

<dc:identifier rdf:resource="http://www.human-ontology.org#human_ontology_http://www.people-ontology.org#people_ontology"/>

<onto1><formalism name="WSML" uri="http://www.wsmo.org/wsml"/><uri>http://www.human-ontology.org#human_ontology</uri></onto1>

<onto2><formalism name="WSML" uri="http://www.wsmo.org/wsml"/><uri>http://www.people-ontology.org#people_ontology</uri></onto2>

<map><Cell id="http://www.human-ontology.org#humanhttp://www.people-ontology.org#person"><entity1><Class rdf:about="http://www.human-ontology.org#human"></Class></entity1><entity2><Class rdf:about="http://www.people-ontology.org#person"></Class></entity2><measure>1.0</measure><relation>ClassMapping</relation> </Cell></map>

</Alignment>


Process Level Mediation


Process Level Mediation

Business Partner1

Business Partner2

A

B

C

D

E

E

B

C, D

A

not a priori compatible behavior interfaces for communication & information interchange

partially resolvable by “process mediation patterns”


Business Partner1Business Partner1

Business Partner2Business A

B B



A B

B A



A and BA

B



A

BA and B

PM

PM

PM

PM



A

AckA

APM

Patterns for Resolvable Mismatches


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

101

Telecom and Informatics INF5120 – Model-based System Development Lecture #13: Model-driven...

Documents

Transcript of Telecom and Informatics INF5120 – Model-based System Development Lecture #13: Model-driven...