Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
10.05.2010
1
ICT
INF5120 – Modellbasert
Systemutvikling
F13: Model Driven Interoperability and MDA
Industrial Evolution (Genova example)
Lecture 03.05.2010
Arne-Jørgen Berre
ICT 2
INF5120 - Lecture plan - 2010 1: 25/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA, 4 parts: MDE/SSS/MS/MDI
(AJB)
Part I: MDE – Model Driven Engineering
2: 1/2: MDE I: Metamodeling. DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (AJB/BRE)
Part II: SSS – Service Science and Service/SOA technologies
3: 8/2: SSS I: Service science (top down) - Service and SOA Technologies (bottom up) (AJB)
Part I continued: MDE – Model Driven Engineering
4: 15/2: MDE II: Model transformations with MOFScript, ATL and other technologies (GO/JO)
5 :22/2: MDE III: Code generation with MOFScript, ATL and other technologies (GO/JO)
Part III: MOS – Modeling of Services - with SoaML
6: 1/3: MOS I: Business Process Modeling (CIM) - with BPMN 2.0, and BMM, EA with UPDM (AJB)
7: 8/3: MOS II: Soaml, UML2 and SysML, Modelio SOA and Scope, –Collaboration and Component models (AJB)
8: 15/3: MOS III: SoaML (PIM) and Requirements modeling , CIM->PIM and SoaML (AJB)
9: 22/3: MOS IV: Method Engineering and SPEM / EPF - for Service systems (BRE)
EASTER
Part IV – Model Driven Interoperability
10: 12/4: MS V: SOA and Service Design, MDA and ADM - Intro to MDI (AJB )
11: 19/4: MDI I: Semantic Web with Ontologies and Model Driven Interoperability (TIR)
12: 26/4: MDI II: Semantic Services and Model Driven Interoperability (TIR)
13: 3/5: MDE IV: Model Driven Interoperability and Industrial Evolution of MDA/MDE (AJB), Knut Sagli/ESITO)
14: 10/5: Course summary and preparation for Exam 31/5 (AJB)
Exam: May 31st, 2010 (Monday), 0900-1200 (3 hours)
10.05.2010
2
ICT
Agenda
Model Driven Interoperability MODELS 2010, Oslo, 3-8. October 2010
Ref. 2 papers on MDI
Industrial evolution of MDA/MDE
Modeling tools: MagicDraw, Enterprise
Architect, Modeio, IBM Software Architect,
Microsoft Domain Specific Languages, Oracle,
...
Guest lecture, ESITO – Genova, Knut Sagli
ICT
MODELS 2010, Oslo, 3-8. October 2010
See: http://models2010.ifi.uio.no Student volunteers ?
10.05.2010
3
ICT
Model Driven Interoperability
ICT 6
Current MDA Interoperability Architecture
CIM/EM
models
PIM
System
models
PSM
System
models
System
Ref.
ontologySemantic
annotation
Semantic
annotation
Semantic
annotation
CIM/EM
models
PIM
System
models
PSM
System
models
System
Semantic
annotation
Semantic
annotation
Semantic
annotation
Sem.mapping
Technical
mapping
Interoperability
executionIF IF
10.05.2010
4
ICT
Run-time
Sem
Annot
Set
#2
InternetSem
Rec
Rules
#2
Local
Software
&
Data
SwApp#1
Local
Software
&
Data
SwApp#2Sem
Annot
Set
#1
Sem
Rec
Rules
#1
ReferenceOntology
Architecture for semantic annotation and reconciliation
Reconciliation
Design-time
ICT
Model Driven Service
Interoperability through use of
Semantic Annotations
I-ESA 2009 paper
Arne-Jørgen Berre
Fangning Liu
Jiucheng Xu
Brian ElvesæterSINTEF ICT
10.05.2010
5
ICT
Model Driven Interoperability through
Semantic Annotations using SoaML
and ODM
JiuCheng Xu*, ZhaoYang Bai*,
Arne J.Berre*, Odd Christer Brovig**
INCOM’09, Moscow,
3. June. 2009
9
ICT
Contents
Introduction
Description of EMPOWER and MEMPOWER
EMPOWER Project
MEMPOWER Project
Comparison Semantic mappings
Conclusion & Further work
10.05.2010
6
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 CustomizationWeb Services
Repository
Semantic Adaptation Layer
(2)Services
Semantic
Annotator(SAWSDL
)
(3)Ontology
Handling
Utilities(OWL
)
(5)Transformation
s Creator
Interoperable
Enterprise Service
Wrapper
Mediator Services
Web ServerSemantic Services
Registry
Transformations
Repository
Model
Repository
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
ServerSemantic
Services
Registry Transformation
s Repository
Model
Repository
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.
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 Map stores mapping rules.
10.05.2010
7
ICT
The EMPOWER Enterprise
Interoperable Services Semantic Map
13
ICT 14
Semantic
Adaptation
Architecture
10.05.2010
8
ICT
PIM level use of Ontology mappings
15
ICT
Use of SoaML for PIM modeling
16
10.05.2010
9
ICT
SAM – Semantic Annotations tools
17
(SASO: semantic annotation tool using SoaML and ODM)
ICT
Ontology example
18
10.05.2010
10
ICT
Address Ontology
19
ICT
Address in Source and UML
20
10.05.2010
11
ICT
“Address” in the source and target
transformation rules
21
ICT
“Address” transformations from
source.xml and target.xmi
22
10.05.2010
12
ICT
SAM editor realized in tree views
23
ICT
Interface of demo
A simple example of class
annotations on the PIM
level
Annotations
Ontology is represented as a
structured and classified tree view. It
shows the properties and relationships
between those classes.
10.05.2010
13
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>
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
10.05.2010
14
ICT
Example: 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 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
Ontology
Source.xml
Address
annotation
10.05.2010
15
ICT
2.PSM: Direct Mapping Mapping without ontology on the PSM-level
--Map between source.xml and target.xml (xsl:easy)
Target.xml
Source.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.xsd
Address in Source.uml
corresponds to
Source.xsd
10.05.2010
16
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)
2.Mapping Between Models based on ontology on the PIM level
Step 1: Generate meta-models
of models and ontology using EMF
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)
2.Mapping Between Models based on ontology on the PIM level
Step 2:Create mapping rules from
source to ontology, and ontology to
target using ATL
Ontology-
Target
Source-
Ontology
10.05.2010
17
ICT
3.PIM: Ontology-based 1.Transformation From PSM level to PIM level
--Generate sources.uml and target.uml from schema (HyperModel Designer
3.1)
2.Mapping Between Models based on ontology on the PIM level
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.uml
Target.uml
10.05.2010
18
ICT
Conclusion
Ontology -based mapping (S-O-T) VS Direct mapping (S-T) on
the PIM level
2N vs N²
Ontology
model
Model A
Model C
Model F
Model E
Model D
Model B
Model A
Model D
Model C
Model C
Model C
Model B
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
ICT
Conclusion
Mapping PIM-Level VS PSM-Level
Ontology-basedPSM
Direct mapping PSM
Ontology-basedPIM
Direct mappingPIM
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
10.05.2010
19
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
10.05.2010
20
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
Semantic
Annotation
Semantic
Annotation
Reconciliation
Rules
Customized
MRE
Customized
MRE
Reconciliation
Rules
Local Data Local Data
Design phase
Run-time phase
Interch.
Repres.
ReferenceOntology
FWD transf BWD transf
BWD transf FWD transf
SW App SW App
Semantic Mediation
and Reconciliation
Platform
Semantic Mediation
and Reconciliation
Platform
10.05.2010
21
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)
10.05.2010
22
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)
ReconciliationRule
{“Rome - 00185”} {“Rome”, “00185”}Run-time Reconciliation
10.05.2010
23
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
order
header
order
header
products
info
products
info
supplier
info
supplier
info
buyer
info
buyer
infoorg
info
org
info
contact
person
contact
person namename
orgNameorgName
address
details
address
details
product
record
product
recorddescriptiondescription
productCodeproductCode
quantityquantity
……
……
……
buyerOrderNumberbuyerOrderNumber
……
……
orderorder
order
header
order
header buyer
info
buyer
infoorg
info
org
info
contact
person
contact
person namename
orderorder
order
header
order
header buyer
info
buyer
infoorg
info
org
info
contact
person
contact
person namename
PurchaseOrderPurchaseOrder
OrderLineOrderLine
IDID IssueDateIssueDate
BuyerBuyer
SupplierSupplier
Contact
Person
Contact
Person
SurnameSurnameFirstNameFirstName
ProductProduct
LinePriceLinePriceQuantityQuantity
BODBOD
AA AA
BOD
AA
BA
CABA
BA
AA
AA
DescriptionDescriptionAA
NameName
AA
YearYearAA
MonthMonthAA
PurchaseOrderPurchaseOrder
BuyerBuyer
Contact
Person
Contact
Person
SurnameSurnameFirstNameFirstName
PurchaseOrderPurchaseOrder
BuyerBuyer
Contact
Person
Contact
Person
SurnameSurnameFirstNameFirstName
Split
SSAX
SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name
INTO
PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName
PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname
Forward
Transf Rule
10.05.2010
24
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_name
INTO
PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName
PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname
Forward
Transf 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 48