INF5120 – Modellbasert Systemutvikling

1. INF5120 – Modellbasert Systemutvikling F12: Model Driven Interoperability and Service Interoperability Lecture 11.04.2011 Arne-Jørgen Berre

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

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

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

5. Article 2:Model Driven Service Interoperability through use of Semantic Annotations I-ESA 2009 paper Arne-Jørgen Berre Fangning Liu Jiucheng Xu Brian Elvesæter SINTEF ICT

6. Article 3:A Model-driven Approach to Interoperability in B2B Data Exchange I-WEI 2011 paper Dumitru Roman Brice Morin Arne-Jørgen Berre SINTEF ICT

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

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

9. EIF version 2.0 (2009)European Interoperability Framework

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

11. EIF - Dimensions of Interoperability

12. Interoperability chain and levels

13. Interoperability levels

14. Reference model for Interoperability- Link to areas in IT architecture Admin, Business, Citizen A Admin, Business, Citizen B Organisational interoperability Workprocess Goals Organisation Product Concepts Workprocess Goals Organisation Product Concepts Organisational interoperability Organisational interoperability Organisational harmonisation, in particular around process Semantic interoperability Semantic interoperability, Informasjons Innhold med mening for: Semantic interoperability, Informasjons Innhold med mening for: Presentation Process, rules Services Information/Data Presentation Process, rules Services Information/Data Shared understanding of the meaning/semantics i innhold ved bruk av teknologier for presentasjon/prosess/tjeneste/data Technical interoperabilitet (Technicall standards) Presentation Process, rules Services Data Communikasjon Adm/Metadat Security Techn. sem/org Technical interoperability Technical interoperabilitet (Technicall standards) Presentation Process, rules Services Data Communikasjon Adm/Metadat Security Techn. sem/org Interoperable technologies Communikation Communikation

15. Admin, Business, Citizen A Admin, Business, Citizen B Organisational interoperability Workprocess Goals Organisation Product Concepts Workprocess Goals Organisation Product Concepts Organisational interoperability Organisational interoperability Semantic interoperability Semantic interoperability, Informasjons Innhold med mening for: Semantic interoperability, Informasjons Innhold med mening for: Presentation Process, rules Services Information/Data Presentation Process, rules Services Information/Data Technical interoperabilitet (Technicall standards) Presentation Process, rules Services Data Communikasjon Adm/Metadat Security Techn. sem/org Technical interoperabilitet (Technicall standards) Presentation Process, rules Services Data Communikasjon Adm/Metadat Security Techn. sem/org Technical interoperability Communikation Communikation Organisational Interoperablilitet Semantic Interoperability Technical Interoperability Reference model for Interoperability vs IDAbc EIF version 1

16. Model Driven Interoperability

17. Current MDA Interoperability Architecture Ref. ontology CIM/EM models Semantic annotation CIM/EM models Semantic annotation Semantic annotation PIM System models PIM System models Semantic annotation Sem.mapping PSM System models Technical mapping Semantic annotation Semantic annotation PSM System models Interoperability execution System System IF IF

18. SwApp#1 SwApp#2 Local Software & Data Local Software & Data Architecture for semantic annotation and reconciliation Reference Ontology Sem Annot Set #2 Sem Annot Set #1 Design-time Run-time Internet Sem Rec Rules#1 Sem Rec Rules#2 Reconciliation

19. Contents • Introduction • Description of EMPOWER and MEMPOWER • EMPOWER Project • MEMPOWER Project • Comparison Semantic mappings • Conclusion & Further work

20. Semantic Adaptation Layer Mediator Services Web Server Semantic Services Registry Transformations Repository Interoperable Enterprise Service Wrapper (5)Transformations Creator (1)WSDL, OWL-S, WSML (3)Ontology Handling Utilities(OWL) Model Repository Legacy System Wrappers (2)Services Semantic Annotator(SAWSDL) Legacy Systems (4)Semantic Map System Interoperability Layer Interoperable Enterprise Service Designer Wrapper Definition and Customization Web Services Repository EMPOWER • an innovative framework for interoperability between enterprise systems • a flexible and extensible architecture • a system environment

21. Semantic Adaptation Layer Mediator Server Semantic Services Registry Transformations Repository (5)Model Transformation Services Wrapper Model Repository (3)ODM (2)SAM (4)Model Map System Interoperability Layer (1)Model Mapping (SoaML) Web Services Repository Wrapper Semaphore Legacy System Wrappers Legacy Systems • Model Transformation Services support the runtime lifting and lowering transformations among messages and ontologies based on the Model Map. MEMPOWER • a Model Driven variant of EMPOWER, • Compare with advantages and disadvantages of Model Driven Interoperability 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. Semantic Annotation Model editor is used to relate different PIM models and ontology. It is used to annotate the SoaML model with Ontology. • Model Map stores mapping rules. SoaML describes the services models. The Model Mapping in the MEMPOWER includes transformations from models to ontology and ontology to models.

22. The EMPOWER Enterprise Interoperable Services Semantic Map

23. SemanticAdaptation Architecture

24. PIM level use of Ontology mappings

25. Use of SoaML for PIM modeling

26. SAM – Semantic Annotations tools (SASO: semantic annotation tool using SoaML and ODM)

27. Ontology example

28. Address Ontology

29. Address in Source and UML

30. “Address” in the source and target transformation rules

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

32. SAM editor realized in tree views

33. Ontology is represented as a structured and classified tree view. It shows the properties and relationships between those classes. A simple example of class annotations on the PIM level Annotations Interface of demo

34. After annotating and exporting the model, you will get the file with a additional attribute. The annotations are displayed in red. <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>

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

36. Example: Address Address in Ontology is divided into three elements: Address, Region, and Province Address in Source.xsd is divided into three elements: Address, Place, and Province Address in Target.xsd has only one elements: Address

37. 1.PSM: Ontology-based • Annotation based on ontology on the PSM-level --Annotate source.xml and target.xml using Ontology Source.xml Ontology Address annotation

38. 2.PSM: Direct Mapping • Mapping without ontology on the PSM-level --Map between source.xml and target.xml (xsl:easy) Source.xml Target.xml

39. 3.PIM: Ontology-based Address in Source.uml corresponds to Source.xsd • 1.Transformation From PSM level to PIM level --Generate sources.uml and target.uml from schemas (HyperModel Designer 3.1) Address in Source.xsd

40. 3.PIM: Ontology-based Step 1: Generate meta-models of models and ontology using EMF • 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

41. 3.PIM: Ontology-based Step 2:Create mapping rules from source to ontology, and ontology to target using ATL • 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 Source-Ontology Ontology-Target

42. 3.PIM: Ontology-based Step3: Transform source into ontology and ontology into target • 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

43. 4.PIM: Direct Mapping • Transformation Between Models without ontology on the PIM level --Use Semaphore tool to map source to target Source.uml Target.uml

44. Conclusion • Ontology -based mapping (S-O-T) VS Direct mapping (S-T) on the PIM level • 2N vs N² StandardOntology 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

45. Conclusion • Mapping PIM-Level VS PSM-Level

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

47. Another example of Ontology-based Service: Message Reconciliation

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

49. Ontology-based reconciliation Reference Ontology Enterprise A Enterprise B Semantic Mediation and Reconciliation Platform Semantic Mediation and Reconciliation Platform SW App SW App Semantic Annotation Semantic Annotation Local Schema Local Schema Reconciliation Rules Reconciliation Rules Design phase Run-time phase FWD transf BWD transf Customized MRE Customized MRE Interch. Repres. Local Data Local Data BWD transf FWD transf

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