Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Version 5
Handouts
AP6 – Model-Driven Development of Interoperable Web Services, Agent and P2P Solutions
http://www.athena-ip.org/
Learn about model transformations from PIM4SOA to Web services, agents and P2P software solutions.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
Course description
• Lectured by– Arne-Jørgen Berre, (SINTEF ICT)– Brian Elvesæter, (SINTEF ICT)– Klaus Fischer (DFKI) – Ricardo Jardim Gonçalves (UNINOVA)
• Narrative summary/Highlights of the course– A PIM4SOA model is a basis for model transformation and code generation.– The course teaches how to refine a PIM4SOA into specific system realisations such as Web services
(XSD, WSDL and BPEL), agents and P2P solutions using for example the transformation tools developed in ATHENA.
– However, an important part of the training is to understand the use of model transformation and be able to develop your own model transformations according to your integration needs.
• Objectives– This course aims to be a method engineering course that will teach the students how to develop their
model transformations to support their own model-driven development methodologies.– This is shown using examples from PIM4SOA, Web services, agents and P2P.– Participants will gain an understanding of the use of model transformations in a software engineering
development and integration process.• Who should attend?
– An advanced academic course targeting post-graduate students and IT developers.• Student requirements
– Students must have pre-knowledge of UML, system modelling and software development.• Recommended precedence
– AP1: Introduction to model-driven interoperability (MDI)– AP2: Principles of model-driven interoperability (MDI)
• Content1. Model mappings and transformations2. Model-driven development with PIM4SOA3. From PIM4SOA to Web services4. From PIM4SOA to agents5. From PIM4SOA to peer-to-peer (P2P)
• Course Type– Classroom
• Technical Requirements– None
• Estimated Time – Three hours without practical exercises– One to two additional hours for the practical ATL exercises
• Contact Person– Arne-Jørgen Berre, SINTEF ICT, Norway, email: [email protected]– Brian Elvesæter, SINTEF ICT, Norway, email: [email protected]
Copyright © 2005-2006 The ATHENA Consortium.
Course description
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 1
© 2005-2006 The ATHENA Consortium.
AP6 – Model-Driven Development of
Interoperable Web Services, Agents
and P2P SolutionsLearn about model transformations from PIM4SOA to Web services, agents and P2P software solutions.
Welcome to the AP6 course titled “Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions”.
In this course you will learn about model transformations from PIM4SOA to Web services, agents and P2P software solutions.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 2
2© 2005-2006 The ATHENA Consortium.
Course description
• A PIM4SOA model is a basis for model transformation and code generation.
• The course teaches how to refine a PIM4SOA into specific system realisations such as Web services (XSD, WSDL and BPEL), agents and P2P solutions using for example the transformation tools developed in ATHENA.
• However, an important part of the training is to understand the use of model transformation and be able to develop your own model transformations according to your integration needs.
A PIM4SOA model is a basis for model transformation and code generation.The course teaches how to refine a PIM4SOA into specific system realisations such as Web services (XSD, WSDL and BPEL), agents and P2P solutions using for example the transformation tools developed in ATHENA.However, an important part of the training is to understand the use of model transformation and be able to develop your own model transformations according to your integration needs.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 3
3© 2005-2006 The ATHENA Consortium.
Course objective
• This course aims to be a method engineering course that will teach the students how to develop their model transformations to support their own model-driven development methodologies.
• This is shown using examples from PIM4SOA, Web services, agents and P2P.
• Participants will gain an understanding of the use of model transformations in a software engineering development and integration process.
This course aims to be a method engineering course that will teach the students how to develop their model transformations to support their own model-driven development methodologies.This is shown using examples from PIM4SOA, Web services, agents and P2P.Participants will gain an understanding of the use of model transformations in a software engineering development and integration process.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 4
4© 2005-2006 The ATHENA Consortium.
MDI training track
<Person>, <Company>, <Country>From PIM4SOA to Web Services• PIM4SOA to XSD ATL Tutorial / Exercise
5-3
<Person>, <Company>, <Country>From PIM4SOA to Agents5-4
<Person>, <Company>, <Country>Model Mappings and Transformations• ATL Tutorial (optional)• MOFScript Tutorial (optional)
5-1AP6
<Person>, <Company>, <Country>Model-Driven Development with PIM4SOA5-2
AP5
AP4
<Person>, <Company>, <Country>From PIM4SOA to Peer-2-Peer (P2P)5-5
<Person>, <Company>, <Country>Method Engineering• Eclipse Process Framework (EPF) Tutorial / Exercise
5-4
<Person>, <Company>, <Country>UML Profiles and Domain-Specific Languages (DSLs)• Eclipse Graphical Modeling Framework (GMF) Tutorial / Exercise
5-3
<Person>, <Company>, <Country>Metamodelling• Eclipse Modeling Framework (EMF) Tutorial / Exercise
5-2
<Person>, <Company>, <Country>ATHENA Model-Driven Interoperability (MDI) Framework5-1
<Person>, <Company>, <Country>Interoperability & Model-Driven Architecture (MDA)4-1
PresenterTopicNo
This course is a part of a larger training track on model-driven interoperability (MDI).The AP4 course introduces MDA in the context of interoperability.The AP5 course focuses on metamodelling, UML profiles and domain-specific languages (DSLs), and method engineering.The AP6 course focuses on model mappings and transformations with a focus on service-oriented development with PIM4SOA, Web services, agents and peer-2-peer (P2P).
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 5
5© 2005-2006 The ATHENA Consortium.
MDI website
http://www.modelbased.net/mdi
The training track is supported by the ATHENA Model-Driven Interoperability (MDI) Framework website that provides guidelines for how model-driven development (MDD) approaches can be applied in developinginteroperable enterprise software systems.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 6
© 2005-2006 The ATHENA Consortium.
6-1. Model Mappings and
Transformations
<Presenter><Company>, <Country><E-mail>
Part 6-1. Model mappings and transformations.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 7
7© 2005-2006 The ATHENA Consortium.
ATHENA Model-Driven Interoperability (MDI) Framework
MDA & Interoperability
Metamodelling
UML Profiles & DSLs
Model Transformations
Method Engineering
Reusable MDI Assets
• Method chunks• Tools and services
• Models and metamodels• Model transformations• DSLs and UML profiles
• Reference examples
This part of the course focuses on model transformations.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 8
8© 2005-2006 The ATHENA Consortium.
Outline
• Foundations of model mappings and transformations
• Model transformation technologies and examples• References
The outline of the course is as follows:Foundations of model mappings and transformationsModel transformation technologies and examplesReferences
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 9
9© 2005-2006 The ATHENA Consortium.
Foundations of model mappings and transformations
Foundations of model mappings and transformations.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 10
10© 2005-2006 The ATHENA Consortium.
About MOF
• MOF is short for Meta-Object Facility• OMG standard• MOF is constructed to store and manage
metamodels and model instances of these.• One can view MOF as a generic storage which
lets you define a (meta)model of what to store, and MOF will manage storage of data according to this (meta)model.
• Is now used in various UML tools.• MOF support for Java in the form of JMI (Java
Metadata Interface)
MOF is short for Meta-Object FacilityOMG standardMOF is constructed to store and manage metamodels and model instances of these.One can view MOF as a generic storage which lets you define a (meta)model of what to store, and MOF will manage storage of data according to this (meta)model. Is now used in various UML tools.MOF support for Java in the form of JMI (Java Metadata Interface)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 11
11© 2005-2006 The ATHENA Consortium.
MOF usage
• Core technology for flexible model repositories– A commonly used term for denoting a structured
storage for information of various kinds.• Define new metamodels in a standardized way.• Base technology for different modelling tools
(UML).
Core technology for flexible model repositoriesA commonly used term for denoting a structured storage for information of various kinds.
Define new metamodels in a standardized way.Base technology for different modelling tools (UML).
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 12
12© 2005-2006 The ATHENA Consortium.
Model mapping (1/2)
• Mapping is performed by defining relations between two models
• The relations can be – 1-to-1, n-to-1, 1-to-n or n-to-n
• Mapping is performed in “design time”
Mapping is performed by defining relations between two models. The relations can be 1-to-1, n-to-1, 1-to-n or n-to-n. Mapping is performed in “design time”.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 13
13© 2005-2006 The ATHENA Consortium.
Model mapping (2/2)
• The mapping is defined with models one meta-level higher than the input and output of the transformation.
• The mapping is used to perform transformation of instances of the mapped models.
• “The mapping describes the rules used for the transformation”.
The mapping is defined with models one meta-level higher than the input and output of the transformation. The mapping is used to perform transformation of instances of the mapped models. “The mapping describes the rules used for the transformation”.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 14
14© 2005-2006 The ATHENA Consortium.
Mapping and transformation
SourceMetamodel
Input Model
OutputModel
TargetMetamodel
Mapping
Transformation
<<InstanceOf>> <<InstanceOf>>
based on
This figure illustrates the mapping as we have already explained.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 15
15© 2005-2006 The ATHENA Consortium.
Different mappings
PSM1metamodel
PSM2metamodel
PIM2metamodel
PIM1metamodel
HorizontalMapping
HorizontalMapping
Vertical Mapping Vertical Mapping
HighAbstraction
LowAbstraction
We can map between models that are on the “same” abstraction level illustrated with horizontal mapping, or we can map between abstraction levels illustrated with vertical mapping in the figure.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 16
16© 2005-2006 The ATHENA Consortium.
Transformations
• Takes input and produces output– One-way process
• Transforms according to a predefined mapping• Transformation is used in “run time”• Two main categories of transformation
– Vertical transformation– Horizontal transformation
A transformations occur at "run-time" and takes input and produces output. A transformation is a one-way process which transforms according to a predefined mapping. Two main categories of transformation:Vertical transformation Horizontal transformation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 17
17© 2005-2006 The ATHENA Consortium.
Horizontal transformation
• Source model has the same level of abstraction as target model– Not to be confused with “meta-levels”
• Examples of horizontal transformation– Refactoring– Merging
In a vertical transformation the source model has the same level of abstraction as target model. Not to be confused with “meta-levels”. Examples of horizontal transformation:RefactoringMerging
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 18
18© 2005-2006 The ATHENA Consortium.
Vertical transformation
• Source model is at a different level of abstraction than the target model
• Examples of vertical transformation– Refinement (specialization)
• PIM PSM transformations
– Abstraction (generalization)
In a horizontal transformation the source model is at a different level of abstraction than the target model. Examples of vertical transformation:Refinement (specialization)
PIM->PSM transformations Abstraction (generalization)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 19
19© 2005-2006 The ATHENA Consortium.
MOF QVT (Query/View/Transformation)
• High-level– Definition of query/view/transformation language for
MOF– Important part of realizing the OMG MDA vision
• Part of the MOF 2.0 specification work in OMG– MOF 2.0 Facility / Object Lifecycle RFP– MOF 2.0 IDL RFP MOF 2.0 Versioning RFP– MOF 2.0 Query / View / Transformation RFP– MOF 2.0 Core
• We focus on the transformation part– But we will need both the Q and the V for it to work
The Object Management Group (OMG) has defined a standard for model transformations in Model Driven Architecture (MDA). This standard is called Query, Views, and Transformation (QVT). Queries are performed on input models to find specific elements or transformation. An example of a query could be to find all classes in a model. Views are models derived from other models. The result of the query is a kind of view. Transformations are, as explained above, the process of transforming an input model to an output model. A more detailed description of QVT can be found at http://umt-qvt.sourceforge.net/
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 20
20© 2005-2006 The ATHENA Consortium.
Involved partners
• Codagen• Compuware• DSTC• France Telecom• IBM• INRIA• Interactive Objects• Kings College London• Softteam
• Sun Microsystems• Tata Consultancy
Services• Thales• TNI-Valiosys• University of Paris VI• University of York
Here is a list of involved partners.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 21
21© 2005-2006 The ATHENA Consortium.
QVT - Query/View/Transformation
• Queries are performed on input models for finding specific elements or information– Example: Return all classes
• Views are models derived from other models– The result of a query is a kind of view
• Transformations takes a model as input and creates a new model– Example: PIM PSM– Defined in Relations language or Core language– Uses Queries and Views
Queries are performed on input models for finding specific elements or information. Example: Return all classes. Views are models derived from other models. The result of a query is a kind of view. Transformations takes a model as input and creates a new model Example: PIM->PSM. Mappings are defined in Relations language or Core language. Uses Queries and Views.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 22
22© 2005-2006 The ATHENA Consortium.
How to define a transformation?
• The abstract syntax must be defined as a metamodel in MOF
• Concrete syntax expressed as text (program code) or models
• Variations– Declarative– Imperative
To define a transformation the abstract syntax must be defined as a metamodel in MOF. Concrete syntax expressed as text (program code) or models.Transformations are defined in two variations: Declarative or imperative.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 23
23© 2005-2006 The ATHENA Consortium.
QVT overview
Core
Relations
BlackBox
OperationalMappings
RelationsToCoreTransformation
The figure gives an overview of QVT.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 24
24© 2005-2006 The ATHENA Consortium.
QVT overview – Declarative part
• Relations– Declarative specification of the mapping between MOF
models– Equivalent with Java code (high-level)
• Relations to Core transformation– Equivalent with compiling Java code into byte code
• Core– Equivalent with Java byte code (low-level)
RelationsDeclarative specification of the mapping between MOF models Equivalent with Java code (high-level) Relations to Core transformationEquivalent with compiling Java code into byte code CoreEquivalent with Java byte code (low-level)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 25
25© 2005-2006 The ATHENA Consortium.
QVT overview – Imperative part
• Operational mappings– Standard language for defining Relations (or Core) in
an imperative way• Black box
– Offers the possibility to plug-in code from any programming language with a MOF binding
Operational mappingsStandard language for defining Relations (or Core) in an imperative way Black boxOffers the possibility to plug-in code from any programming language with a MOF binding
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 26
26© 2005-2006 The ATHENA Consortium.
QVT in practice – most transformation
• Given a defined metamodel for source and target– Metamodels must be well-defined according to MOF
(models on level M2)• One can define transformations between these
two worlds in a general, standardized manner– The transformation can be used on all instances of the
source metamodel– The result will be an instance of the target metamodel
Given a defined metamodel for source and target, metamodels must be well-defined according to MOF (models on level M2). One can define transformations between these two worlds in a general, standardized manner. The transformation can be used on all instances of the source metamodel. The result will be an instance of the target metamodel.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 27
27© 2005-2006 The ATHENA Consortium.
Model transformation technologies and examples
Model transformation technologies and examples.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 28
28© 2005-2006 The ATHENA Consortium.
Technology overview
• Multiple technologies for mapping and transformation– Java– IBM Model Transformation Framework (MTF)– Atlas Transformation Language (ATL)
• Not many QVT-based ones– QVT support in Borland Together Architect 2006
There are multiple technologies for mapping and transformation:Java IBM Model Transformation Framework (MTF) Atlas Transformation Language (ATL) Not many QVT-based ones: QVT support in Borland Together Architect 2006
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 29
29© 2005-2006 The ATHENA Consortium.
Java
• Technologies such as MDR and EMF allow for generation of Java API toward arbitrary metamodels
• Using these APIs mappings can be defined in a Java program
• The transformation is performed by running the Java program on a model instance given as input
• Drawback– API generation for metamodels needed
• Pros– Well known language for mapping definition
Technologies such as MDR and EMF allow for generation of Java API toward arbitrary metamodels. Using these APIs mappings can be defined in a Java program. The transformation is performed by running the Java program on a model instance given as input. The drawback is that API generation for metamodels is needed. The pros are a well-known language for mapping definition.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 30
30© 2005-2006 The ATHENA Consortium.
IBM MTF
• MTF was developed in order to experiment with QVT related concepts
• MTF is not QVT compliant• MTF rules describe the relationships between the
input and the output metamodel• Provides functionality to define mappings
between metamodels• And execute the model transformations
MTF was developed in order to experiment with QVT related concepts,. MTF is not QVT compliant. MTF rules describe the relationships between the input and the output metamodel. Provides functionality to define mappings between metamodels and execute the model transformations.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 31
31© 2005-2006 The ATHENA Consortium.
ATL
• The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as described by the MDA approach.
• It is not QVT, but similar and with the corresponding functionality
• A transformation model in ATL is expressed as a set of transformation rules.
• The recommended style of programming is declarative.• OCL is used to expression constraints on rules
– Guards (constraints) on the entry point for a rule• Different kinds of M3/M2 (meta)metamodel technology
supported: Netbeans MDR and EMF Ecore– Can use either EMF or MDR metamodels as input and output.
• Can also be used to produce textual output.
The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as described by the MDA approach. It is not QVT, but similar and with the corresponding functionality. A transformation model in ATL is expressed as a set of transformation rules. The recommended style of programming is declarative. OCL is used to expression constraints on rules. Guards (constraints) on the entry point for a rule. Different kinds of M3/M2 (meta)metamodel technology supported: Netbeans MDR and EMF Ecore. Can use either EMF or MDR metamodels as input and output. Can also be used to produce textual output.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 32
32© 2005-2006 The ATHENA Consortium.
Example: UML RDBMS
PrimitiveDataType
Classifier
Attributevisibility : String
Association
PackageModelElement
name : Stringkind : String **+ownedElement
Class*
1+attribute
*1
*
1
+forward*
+source1
*
1
+reverse
*
+destination
1
**
+derived*
+super *
TypedElement1
*+type1
+typed*
Operationvisibility : String*
1
+operation
*
1
Parameterkind : String*
1+parameter
*
1
Parts of UMLmetamodel
Let us go through an example where we want to transform a UML model to a RDBMS. The figure shows parts of the UML metamodel that you should already be familiar with.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 33
33© 2005-2006 The ATHENA Consortium.
Example: UML RDBMS
ForeignKey Table
10..1+owner
1
+foreignKey
0..1
Columntype : String
*
1
+column*
+owner1
*
*
+column *
+foreignKey*
Key
1*+refersTo
1
+referredBy*
1 1
+owner
1
+key
1
*
*
+column*
+belongsTo*
ForeignKey Column Table Key
ModelElementname : Stringkind : String
Simple RDBMS metamodel
This figure shows a simple metamodel for RDBMS. It defines the most important constructs for relational databases such as table, column, key and foreign key.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 34
34© 2005-2006 The ATHENA Consortium.
Example: Informal rules
• A persistent class maps to a table, a primary key and an identifying column.
• Attributes of the persistent class map to columns of the table: an attribute of a primitive datatypemaps to a single column; an attribute of a complex data type maps to a set of columns corresponding to its exploded set of primitive datatype attributes; attributes inherited from the class hierarchy are also mapped to the columns of the table.
• An association between two persistent classes maps to a foreign key relationship between the corresponding tables.
A persistent class maps to a table, a primary key and an identifying column. Attributes of the persistent class map to columns of the table: an attribute of a primitive datatype maps to a single column; an attribute of a complex data type maps to a set of columns corresponding to its exploded set of primitive datatypeattributes; attributes inherited from the class hierarchy are also mapped to the columns of the table. An association between two persistent classes maps to a foreign key relationship between the corresponding tables.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 35
35© 2005-2006 The ATHENA Consortium.
Example: Java transformation (1/2)public Model model2model(org.eclipse.uml2.Model inModel){
Model retval = RdbmsFactory.eINSTANCE.createModel();Iterator it = inModel.getOwnedElements().iterator();while (it.hasNext()){
Object element = it.next();if(element instanceof Class){
Class toProcess = (Class)element;retval.getElements().add(class2table(toProcess));
}}return retval;
}
public Table class2table(Class inClass){Table retval = RdbmsFactory.eINSTANCE.createTable();retval.setName(inClass.getName());Iterator it = inClass.getOwnedAttributes().iterator();while (it.hasNext()){
Object attrib = it.next();if(attrib instanceof Property){
Property toProcess = (Property)attrib;retval.getColumns().add(attrib2column(toProcess));
}}return retval;
}
This snippet of code shows the Java code for the model transformation.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 36
36© 2005-2006 The ATHENA Consortium.
Example: Java transformation (2/2)
public Column attrib2column(Property inAttr){Column retval = RdbmsFactory.eINSTANCE.createColumn();retval.setName(inAttr.getName());retval.setType(inAttr.getType().getName());return retval;
}
• It is all about traversing the model tree– And building an output model
It is all about traversing the model tree and building an output model.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 37
37© 2005-2006 The ATHENA Consortium.
Example: MTF transformation/* UML Packages map to EPackages */relate umlpkg2ecore( uml:Package pkg, ecore:EPackage epkg)
when equals(pkg.name, epkg.name){
// map sub-packagesumlpkg2ecore( over pkg.ownedMember, over epkg.eSubpackages),
// map classifiersumlclassifier2ecore( over pkg.ownedMember, over epkg.eClassifiers )
}
/* UML Classifiers map to EClassifiers */abstract relate umlclassifier2ecore( uml:Classifier class,
ecore:EClassifier eclass)when equals(class.name, eclass.name)
/* Map UML Class to EClass */relate umlclass2ecore extends umlclassifier2ecore( uml:Class class,
ecore:EClass eclass){
// check that super classes map to each other check umlclass2ecore(over class.superClass, over eclass.eSuperTypes)
}
Here we see the same example in MTF. In MTF we describe mapping rules using the relate construct.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 38
38© 2005-2006 The ATHENA Consortium.
Example: ATL transformation (1/2)
module uml2rdbms; -- Module Templatecreate OUT : rdbms from IN : uml2;
rule model{from inMod:uml2!Modeltomodi:rdbms!Model(elements <-inMod.ownedMember
)}
rule class2table{from cl:uml2!Class (cl.oclIsTypeOf(uml2!Class))totbl:rdbms!Table(name <- cl.name,columns <- cl.ownedAttribute
)}
And finally, here is the example shown in ATL. Here the rules are described using the rule construct.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 39
39© 2005-2006 The ATHENA Consortium.
Example: ATL transformation (2/2)
rule attr2col{from attr:uml2!Property
tocol:rdbms!Column(
name <- attr.name,type <-attr.type.name
)}
• Compared to Java ATL provides simpler mechanisms for model traversal
Compared to Java ATL provides simpler mechanisms for model traversal.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 40
40© 2005-2006 The ATHENA Consortium.
Example: QVT graphical notation
A persistent class maps to a table, a primary key and an identifying column
c:Class t:Table
name=cnkind=‘Persistent’
name=cn
C E
uml rdbms
p:Package S:Schema
cl:Column
name=cn+’_tid’type=‘NUMBER’
k:Key
name=cn+’_pk’
where
whenPackageToSchema(p,s)
AttributeToColumn(c,t,’’)
QVT has defined a graphical notation for describing a mapping. The figure shows the example in this notation. A persistent class maps to a table, a primary key and an identifying column.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 41
41© 2005-2006 The ATHENA Consortium.
Example: QVT textual notation
top relation ClassToTable {cn, prefix: String; checkonly domain uml c:Class {namespace=p:Package {},
kind='Persistent', name=cn}; enforce domain rdbms t:Table {schema=s:Schema {},name=cn,
column=cl:Column {name=cn+'_tid', type='NUMBER'},key=k:Key {name=cn+'_pk', column=cl}};
when { PackageToSchema(p, s);
} where { prefix = ''; AttributeToColumn(c, t, prefix);
}}
A persistent class maps to a table, a primary key and an identifying column
Here is the example shown in the QVT textual notation.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 42
42© 2005-2006 The ATHENA Consortium.
References
References.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 43
43© 2005-2006 The ATHENA Consortium.
References
• OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", Object Management Group (OMG), Document ptc/05-11-01, November 2005. http://www.omg.org/docs/ptc/05-11-01.pdf
• INRIA, "ATL - The Atlas Transformation Language Home Page". http://www.sciences.univ-nantes.fr/lina/atl/
• Eclipse.org, "ATL Home page". http://www.eclipse.org/gmt/atl/• IBM, "Model Transformation Framework". http://www.alphaworks.ibm.com/tech/mtf/• IBM, "Model Transformation with the IBM Model Transformation Framework".
http://www-128.ibm.com/developerworks/rational/library/05/503_sebas/
List of references.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1
Version 5
© 2005-2006 The ATHENA Consortium. 44
44© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-1
Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
6-1b. Atlas Transformation
Language (ATL) with RSM Tutorial
<Presenter><Company>, <Country><E-mail>
2Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Outline
• Atlas Transformation Language (ATL) tutorial with RSM example– Installation– Book2Publish example– RSM
• References
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-2
3Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL (1/2)
• ATL: Atlas Transformation Language• Developed by:
– LINA (Laboratoire D’Informatique De Nantes Atlantique)– Université de Nantes Faculté des Sciences et Techniques– Building IRIN– 2, rue de la Houssinière, BP 92208– 44322 Nantes cedex 3, France
• Proposal to the OMG MOF/QVT RFP.• Model transformation language
– Hybrid• Declarative => transformations based on simple mappings• Imperative => for complex mappings
– Based on OCL• Documentation
– http://www.eclipse.org/gmt/atl/doc/
4Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL (2/2)
• An ATL transformation program is composed of rules that define how – source model elements are matched and navigated– to create and initialize the elements of the target models
• The ATL programs for model to model transformation are called modules.
• Composed of – Header
• transformation name• variables of source and target models
– Import• libraries to be imported
– Helpers• define (global) variables and functions.
– Rules• describe the transformation from a source model to a target model
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-3
5Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Warning
• To navigate from an element to its attribute, – write the name of the element, then “.” and the name of
the attribute;• If an identifier (variable name, metamodel name,
model element name, etc.) is in conflict with a keyword, – it has to be marked with apostrophes;
• The ATL parser is case sensitive. This concerns– the file names– the source code itself.
6Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL: Installation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-4
7Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Installation (1/2)
• Rational Software Modeler (RSM) 6.0– Based on Eclipse 3.0
• ADT (ATL Development Tools)– Installation guide
• http://www.eclipse.org/gmt/atl/doc/ATL_Installation_Guide[v0.1].pdf
– NB! Download ADT for Eclipse 3.0 and not 3.1• http://www.eclipse.org/downloads/download.php?file=/technol
ogy/gmt/atl/binaries/ADT-20060113/adt-20060113(Eclipse_3.0).zip
• Unzip adt-20060113(Eclipse_3.0).zip into {RSMInstallDir}\eclipse
– C:\Program Files\IBM\Rational\SDP\6.0\eclipse
8Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Installation (2/2)
• Additional elements to download and install for ADT– External libraries not included as part of the standard ADT package
• Download antlr-2.7.5.jar from– http://www.antlr.org/download.html– Rename file to antlr.jar– Copy antlr.jar into …
{RSMInstallDir}\eclipse\plugins\org.atl.eclipse.engine_1.0.7\lib
• Download mdr-standalone.zip from– http://mdr.netbeans.org/download/– Unzip into
{RSMInstallDir}\eclipse\plugins\org.atl.engine.repositories.mdr4atl_1.0.0\lib
• The ADT is now installed. In Eclipse it adds– Plug-in– 2 perspectives
• ATL perspective• Debug perspective
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-5
9Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL: Book2Publish example
10Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Reminder on transformation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-6
11Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Goal
• Transform instances Book into instances of Publication
Sum of chapters' number of pages
List of authors'names
separated by and
12Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL transformation code
• Header• Helper• Rule
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-7
13Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Book2Publication.atl
• Header
module Book2Publication;create OUT : Publication from IN : Book;
14Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
• Helper– To build the authors' list
helper context Book!Book def : getAuthors() : String =self.chapters->
collect(e | e.author)->asSet()->
iterate(authorName; acc : String = '' |acc +if acc = ''
then authorNameelse ' and ' + authorName
endif);
1st helper
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-8
15Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
helper context Book!Book def : getAuthors() : String =self.chapters->
collect(e | e.author)->asSet()->
iterate(authorName; acc : String = '' |acc +if acc = ''
then authorNameelse ' and ' + authorName
endif);
Get the authors of each chapter
Suppress duplicatedvalues
Select the chapters
Build the list
16Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Iterate on a collection
• To iterate on a collection
• acc is an accumulator which gets the initial value • elem is an iterator which iterates on each element of the
collection• For each iteration expression-avec-elem-et-acc is
– Evaluated– And then put into acc
collection->iterate(elem : Type; acc : Type = <expression> | expression-avec-elem-et-acc)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-9
17Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
2nd helper
• Helper– To get the total of pages
helper context Book!Book def : getNbPages() : Integer =self.chapters->
collect(f|f.nbPages)->iterate(pages; acc : Integer = 0 |
acc + pages);
18Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Rules
rule Book2Publication {from
b : Book!Book (b.getNbPages() > 2
)to
out : Publication!Publication (title <- b.title,authors <- b.getAuthors(),nbPages <- b.getNbPages())
}
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-10
19Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
ATL: RSM
20Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
RSM example steps
1. Create an ATL project Book2Publication2. Create the Book.emx metamodel (UML model)3. Export and import the Book.emx metamodel as
Book.ecore4. Create the Publication.emx metamodel (UML
model)5. Export and import the Publication.emx metamodel
as Publication.ecore6. Create an ATL file Book2Publication.atl7. Write the ATL transformation8. Create a source model theBooks.ecore containing
book instances9. Configure the ATL transformation10. Run the ATL transformation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-11
21Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
1. Create an ATL project
22Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
2a. Create the Book metamodel
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-12
23Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
2b. Create the Book metamodel
24Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
2c. Create the Book metamodel
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-13
25Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
3a. Export the Book metamodel as .ecore
26Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
3b. Export the Book metamodel as .ecore
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-14
27Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
3c. Export the Book metamodel as .ecore
28Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Book.ecore file
<?xml version="1.0" encoding="UTF-8"?><ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Book"nsURI="http:///Book.ecore" nsPrefix="Book">
<eClassifiers xsi:type="ecore:EClass" name="Book"><eStructuralFeatures xsi:type="ecore:EAttribute" name="title" lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"defaultValueLiteral=""/>
<eStructuralFeatures xsi:type="ecore:EReference" name="chapters" upperBound="-1"eType="#//Chapter" containment="true"/>
</eClassifiers><eClassifiers xsi:type="ecore:EClass" name="Chapter">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title" lowerBound="1"eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral=""/><eStructuralFeatures xsi:type="ecore:EAttribute" name="author" lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"defaultValueLiteral=""/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="nbPages" lowerBound="1"eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
</eClassifiers></ecore:EPackage>
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-15
29Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
3d. Import the Book metamodel as .ecore
NB! Choose "File system"If you choose "Ecore Model",RSM proposes to replaceyour ".emx' model !!!!!!
30Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
3e. Import the Book metamodel as .ecore
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-16
31Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
4-5. Create the Publication metamodel and export/import as .ecore
• Follow the same procedure as for the Book metamodel (steps 2 and 3) to create and export/import the Publicationmetamodel as .ecore
32Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
6a. Create an ATL file
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-17
33Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
6b. Set IN metamodel
34Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
6c. Set OUT metamodel
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-18
35Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
7. Write the ATL transformation
36Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
8. Create source model
• Set of book instances theBooks.ecore
<?xml version="1.0" encoding="ISO-8859-1"?><xmi:XMI xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"xmlns:Book="http:///Book.ecore">
<Book:Book title="Easy ATL"><chapters title="chapter 1" nbPages="5" author="Jean-Pierre"/><chapters title="chapter 2" nbPages="6" author="Reyes"/>
</Book:Book ><Book:Book title="ATL for Dummies">
<chapters title="chapter 1: A" nbPages="13" author="Reyes"/><chapters title="chapter 2: T" nbPages="17" author="Arne"/><chapters title="chapter 3: L" nbPages="20" author="Jean-Pierre"/>
</Book:Book ></xmi:XMI>
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-19
37Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
9a. Configure the ATL transformation
38Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
9b. Configure the ATL transformation
Change the name
Fill
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-20
39Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
9c. Configure the ATL transformation
Name of the source model (IN) and meta-
model (Book)
The same for the target(OUT, Publication)
Set the pathsIN = source model file (theBooks.ecore)Book = source metamodel (Book.ecore)
OUT = target file (thePublications.ecore)Publication = target metamodel (Publication.ecore)
40Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
10. Run the ATL transformation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-21
41Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
Result: thePublications.ecore
<?xml version="1.0" encoding="ISO-8859-1"?><xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:Publication="http:///Publication.ecore"><Publication:Publication title="ATL for Dummies"
authors="Reyes and Jean-Pierre and Arne"nbPages="50"/>
<Publication:Publication title="Easy ATL"authors="Reyes and Jean-Pierre"nbPages="11"/>
</xmi:XMI>
42Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
To summarize
rule Book2Publication {from
b : Book!Book (b.getNbPages() > 2
)to
out : Publication!Publication (title <- b.title,authors <- b.getAuthors(),nbPages <- b.getNbPages())
}
<?xml version="1.0" encoding="ISO-8859-1"?><xmi:XMI xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"xmlns="Book">
<Book title="Easy ATL"><chapters title="chapter 1" nbPages="5" author="Jean-Pierre"/><chapters title="chapter 2" nbPages="6" author="Reyes"/>
</Book><Book title="ATL for Dummies">
<chapters title="chapter 1: A" nbPages="13" author="Reyes"/><chapters title="chapter 2: T" nbPages="17" author="Arne"/><chapters title="chapter 3: L" nbPages="20" author="Jean-Pierre"/>
</Book></xmi:XMI>
<?xml version="1.0" encoding="ISO-8859-1"?><xmi:XMI xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"xmlns="Publication">
<Publication title="ATL for Dummies" nbPages="50"authors="Reyes and Jean-Pierre and Arne"/>
<Publication title="Easy ATL" nbPages="11"authors="Reyes and Jean-Pierre"/>
</xmi:XMI>
<<instance>> <<instance>>
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-22
43Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
References
44Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
References
• INRIA, "ATL - The Atlas Transformation Language Home Page". http://www.sciences.univ-nantes.fr/lina/atl/
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1b
Version 5
© 2005-2006 The ATHENA Consortium. 1b-23
45Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-1
Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
6-1c. MOFScript -Model to Text
Transformation
<Presenter><Company>, <Country><E-mail>
2Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Outline
• Background• Introducing the MOFScript language• MOFScript and the MOF• MOFScript and the relation to QVT• Details of the MOFScript language• Example1: From UML class diagram to Java• MOFScript advanced features• The MOFScript tool
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-2
3Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Background
4Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
The MOF model to text transformation RFP
• The Model to Text Transformations RFP (ad/2004-04-07)asks for proposals that define a language that provides capabilities for generating text output from MOF models, e.g. in order to support code generation, documentation, etc. Important in this regard, is capabilities to perform string manipulation.
• Proposals shall define a solution for generating text from MOF 2.0 models.
• Proposals shall reuse existing OMG language specifications (e.g. such as QVT capabilities)
• Proposals shall be able to support complex text transformation mappings.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-3
5Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Consortium
• Submitters: (supporter)
• Also supported by the following MODELWARE partners:
6Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript – Background
• Usability– Ease of use: Writing and understanding– Few constructs
• End user recognisability– Similar to programming and scripting languages
• Sequential execution semantics– Rules are called explicitly
• Might also support pattern matching execution
– Contents of rules is executed sequentially• Compatibility
– Alignment with QVT
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-4
7Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Introducing the MOFScriptlanguage
8Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
What is MOFScript?
• The MOFScript tool is an implementation of the MOFScript model to text transformation language– http://umt-qvt.sourceforge.net/mofscript/update
• An Eclipse plug-in (Feature)• Developed by SINTEF ICT in the EU-supported
MODELWARE project• Ongoing standardization process within OMG
– OMG RFP MOF Model to Text Transformation process– MOFScript tool and language is part of this process– Competing proposal: ...
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-5
9Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript in action
Documentation
UML
MOFScript
Program code
XMLRDBMS
BPMN
MOF MODELSMOF MODELS Lexical outputLexical output
10Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript language features (1)
• Rules– Rules are invoked explicitly.
• Output of text– Standard print mechanism (println)– Escaped output
• Files– Generation of named files
• Collections and Iterators– Collection types (List, Hashtable/Dictionary)– Iterators: Loops on collections (or Strings/Integers)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-6
11Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript language features (2)
• String handling– Functions for String manipulation
• Types– String, Boolean, Integer, Real, List, Dictionary/Hashtable
• Variables and constants– Global or local, explicitly or implicitly typed.
• Utility functions– Utility & system functions: time(), date(), getenv(), setenv(),
indent(), tab(), space(), position(), count()• Side effects
– Variables can be modified– MOF Script has side effects, in the sense that variables can be
declared and manipulated during the lifetime of a transformation.It does not, however affect the source models.
12Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Basic QVT extensionsMappingModule
(from QVT::MappingRules)
MT2Module M2TDescriptordes criptor+
M2TRule
0..1ownedM2TRules+
*
M2TRuleBody
0..1
ruleBody+ 0..1
M2TRuleBody
MappingBody(from QVT::MappingRules)
Section(from QVT::MappingRules)0..1 populationSection+
*
M2TSection
Expression(from QVT::Expression)0..1 content+
*
0..1 +populationSection+
*
{refinement}
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-7
13Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Text transformation
MappingOperation(from QVT::QVTMappingOperations)
OperationalTransformation(from QVT::QVTMappingOperations)
owner+
operations+
*
MappingBody(from QVT:: )body+
0..1
TextTransformation TextMappingRuleTextMappingBody
0..1 ownedTextMappings+
*
{refinment}
0..1 ruleBody+
0..1
{refinement}
14Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Mapping body
TextMappingBody
MappingBody(from QVT::QVTMappingOperations)
MappingSection(from QVT::QVTMappingOperations)0..1 populationSection+
*
TextMappingSection
OclExpression(from QVT::QVTBase)
0..1 +populationSection+
*
{refinement}
0..1 content+
*
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-8
15Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Variables and constants
VariableDeclaration(from QVT::QVTBase)VariableInitExp
(from QVT::QVTMappingOperations)
OclExpression(from QVT::QVTBase)
TextTransformation
Property(from MOF 2.0::EMOF)localProperty+
*
(from QVT::Queries::Module)
localVariables+
*/(from QVT::MappingRules)
VariableOwner
TextMappingRule
0..1 referredVariable+
16Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Output expressions• OutputExpression
– OutputExpression represents an expression that generates textual output to some device, typically an output file or standard output console.
• OutputDeviceExpression– concept that represents the
declaration of an output device, such as a file.
• FileDeviceExpression– Device tailored for file output
• StdOutDeviceExpression– Device for std output
• EscapedOutputExpression– Escaped text output
FileDeviceExpression
+directory:String[0..1]+fileName:String+fileExt:String+fileType:String
EscapedOutputExpression
+escapedText:String
OclExpression(from QVT::QVTBase)
OutputExpression
+outputCommand:String={'print', 'println'}0..1
outputBody+
outputContext+
0..1OutputDeviceExpression
+refName:String[0..1]+properties:Property[*]
StdOutDeviceExpression
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-9
17Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Iterator extensions
• QVT defines a range of iterators and block expressions
• QVT also defines block expressions which are blocks executed in sequence
– E.g. while
• ForEachExp and If also as block statements
self.ownedMembers->forEach (p:uml.Package | p.stereotype = “System”) {
<%
// the package declration
package org.mofscript.%> p.name <%
%>if (self.name = “Person”) {
<% This is the person type %>
} else {
<% This is not a person type %>
}
BlockExp(from QVT::QVTMappingOperations)
VariableDeclaration(from QVT::QVTBase)
OclExpression(from QVT::QVTBase)
blockOwner+
0..1
body+
*
IfExp(from QVT::QVTBase)
ForEachExpiterators+
1..*0..1 condition+
0..1
C t d ith P id f UML C it Editi N t f C i l U
18Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Function libraries
• String library– Various string manipulation functions, such as:
• Size, substring, subStringBefore|After, toLower, toUpper, indexOf, trim, endsWith, startsWith, replace, equals, equalsIgnoreCase,…
• Collection library– Standard collection operations…
• Hashtable: put, get, clear, size, isEmpty• List: add, size, clear, isEmpty
• Utility library– Various utility functions, such as
• Time, date, Indent, unindent, newline(count: int), tab(count : int), position() {numbered position within an iterator}, …
• XML library– Functions to support XML manipulation
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-10
19Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Details of the MOFScript language
20Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Textual syntax
• Textmodule• Rules• Iterators• Files• Escaped output
<%public class %> c.name <% extends
Serializable {%>
file f2 (c.name + “.java”)<% package %> c.ownerPackage.name <%;%>f2.println (“public class” + c.name);
uml.Package::mapPackage () { self.ownedMember->forEach(c:uml.Class)<%<class name=”%> c.name <% “/>
%>}
textmodule UML2Java (in uml:uml2)access library variousJavaStuff
("uml2java_include.m2t")
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-11
21Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Textual syntax
• If expression• Printing
• Collections, Vars stdout.println (“\t Printing to standard out…”)dclFile.println (”Print to file” + c.name)print (”\n\n print to declared context”)<% escaped output print …… %> c.name <% …%>
if (self.name = “Person”) {<% This is the person type %>
} else {<% This is not a person type %>
}
var packageNames:Listvar packageIdList:Hashtableself.ownedMember->forEach(p:uml.Package) {
packageNames.add (p.name)packageIdList.put (p.id, p.name)
}
if (packageIdList.size () > 0) {<% Listing the package names that does not start with ‘S’ %>packageIdList->forEach (s:String | not(s.startsWith(“S”)) {
<% Package: %> s}
}
22Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Textual syntax
• Invoking rules• Return results
uml.TypedElement::getType () : String {if (self.type.name.equalsIgnoreCase("string"))
result = "xsd:string"elseresult = self.type.name
}
uml.Package::interfacePackages () {if (self.getStereotype() = “Service”){file (rootdir + self.name.toLower() + ".wsdl") self.wsdlHeader()self.wsdlTypes() self.ownedMember->forEach(i:uml.Interface) {i.wsdlMessages()i.wsdlPortType()i.wsdlBindings()i.wsdlService()
} self.wsdlFooter()
}}
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-12
23Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript extends QVT mappings
Relations Mappings Graphical
QVTMerge
MOFScript •• imperativeimperative•• proceduralprocedural•• sideside--effectseffects•• uniuni--directionaldirectional•• objectobject--orientedoriented•• OCLOCL--basedbased•• lexicallexical
24Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript a transformation language
• Language for writing model to text transformations
• Rules / Operations are called explicit (Procedural language)
• Partly based on the current QVT specification (keeps it within the family)
• Transforms input models to output text files– Input: UML, ecore or your own based on it
• Supports EMF meta-models and models as input– UML2, Ecore, etc..
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-13
25Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
General syntax of a mapping operation
From the last QVTMerge-spec:The general syntax for the body of a mapping operation is:
mapping <dirkind0> X::mappingname(<dirkind1> p1:P1, <dirkind2> p2:P2) : r1:R1, r2:R2
when { … }where { … }
{init { … }population { … }end { … }
}
26Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Example1: From UML classdiagram to Java
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-14
27Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Example (1)textmodule UML2Java (in m1:UML)
property package_name = "org.sintef.no"property package_dir = "org/sintef/no/"property ext = ".java"property author = "Jon Oldevik" /** Entrypoint*/main () {
m1.ownedMember->forEach(p:uml.Package)p.mapPackage ()}
/** mapPackage */void uml.Package::mapPackage () {
p.ownedMember->forEach(c:uml.Class)c.mapClass()
}
28Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Example (2)void uml.Class::mapClass () {
file f1 (name=self.name, ext=”txt”, dir=package_dir, type=”text”)file f2 (“Test.dilldall”)use file f3 (package_dir + self.name + ext)self.standardClassImport ()self.standarClassHeaderComment ()<%public class %> c.name <% extends Serializable {
%>
<% // Attributes %>self.ownedAttribute->forEach(p:uml.Property | p.association = "")
p.classPrivateAttribute(self)newline(2)
self.ownedAttribute->forEach(p:uml.Property | p.association <> "")p.classPrivateAssociations()
newline(2)self.ownedAttribute->forEach(p:uml.Property | p.association = "")
p.attributeGettersSetters()
newline(2)<%
}%>
}
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-15
29Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Example (3)
// classPrivateAttribute
void uml.Property::classPrivateAttribute (uml.Class owner) {
<%
private String _%> self.name.toLower() <% ; %> <% // Visibility:%>
self.visibility <%// Type : ... %> self.type
println(" // This was the private attributes \n\n")
}
30Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript advanced features
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-16
31Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Change management
• Proposed metamodel for handling: – Links from a model toward code blocks– Traces from a model to text blocks– Controlled by user
unprotect {<% // User writes code here %>
}
– The resulting code will be generated with protected blocks• Identifying the start and end the section• Code is protected by user-defined tags• E.g. comment tags
32Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Traceability model
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-17
33Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
The MOFScript tool
34Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
What is MOFScript?
• An Eclipse plug-in (feature)• Developed at SINTEF ICT
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-18
35Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript architecture
36Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
MOFScript a model to text tool
• Provides the means of:– Editing, compiling
and executing the transformations
• Syntax high-lightning• Content assist
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-19
37Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
GUI overview
38Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
Tool (continued)
• Editor– Syntax highlighting– Context sensitive / content assist
• Outline viewer– View the
• Preference pages– Setting global preferences
• File properties– Setting preferences for a single transformation file
• Actions– Compile, execute, convert to model,…
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-20
39Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
References
40Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
References
• OMG MOF Model to Text Transformation RFP. http://www.omg.org/cgi-bin/apps/doc?ad/04-04-07.pdf
• MOFScript submission. http://www.omg.org/cgi-bin/apps/doc?ad/05-05-04.pdf• MOFScript tool. http://www.modelbased.net/mofscript
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-1c
Version 5
© 2005-2006 The ATHENA Consortium. 1c-21
41Based on material developed in ATHENA (IST-507849) and MODELWARE (IST-511731)
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 1
© 2005-2006 The ATHENA Consortium.
6-2. Model-Driven Development with
PIM4SOA
<Presenter><Company>, <Country><E-mail>
Part 6-2. Model-driven development with PIM4SOA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 2
2© 2005-2006 The ATHENA Consortium.
Outline
• PIM4SOA• Rapid prototyping with PIM4SOA• Case study: AIDIMA e-procurement scenario• References
The outline of this course is as follows:PIM4SOARapid prototyping with PIM4SOACase study: AIDIMA e-procurement scenarioReferences
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 3
3© 2005-2006 The ATHENA Consortium.
PIM4SOA
PIM4SOA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 4
4© 2005-2006 The ATHENA Consortium.
The problem
• Currently, enterprises face many difficulties related to lack of interoperability.
• ATHENA Overall objective: Contribution to enabling enterprises to seamlessly interoperate with others
• Seamlessly involves reducing as much as possible the effort required to translate the interoperability rules specified by the business expert to suitable technical platform (SOA).
• PROBLEMS:– Several ways to specify interoperability at business level– Several kinds of SOA platforms– Too big gap
Currently, enterprises face many difficulties related to lack of interoperability. For example, analysts such as Gartner and AMR tend to agree that company budgets for integration projects nowadays add up to 30-40% of companies’ total IT budgets. This figure indicates that significant efforts are undertaken to achieve custom integration rather than general interoperability. The importance of integration solutions is shown by the fact that for 61% of a sample of Chief Information Officers integrating systems and processes is a key priority[1]. Furthermore, application integration license revenue is estimated to go up to 5.4 B$ by 2004[2]. IT professional services budgets related to application integration are expected to grow to $29 billion by 2006[3]. These numbers show that industry and analysts acknowledge that the ability of an enterprise to exchange information and to use the information that has been exchanged is a major concern in industry today.
[1] CIO Magazine, September 2002[2] The Yankee Group, 2001[3] Systems Integrators and Users Advance Web Services Use in 2002, Market Trends, Gartner Group, Jan.2003.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 5
5© 2005-2006 The ATHENA Consortium.
Alternatives 1: Too big gap
Business expert
IT infrastructure
GAP
Aris Grai Metis Moogo
GRIDP2PBDI Teams
WSA
POP* CIM
PSM
-The potential number of transformation to be performed is quadratic-The transformations have to translate from business to platform
-How we distinguies what should be automated?-How we guess the low level details such as type from the businessmodels?
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 6
6© 2005-2006 The ATHENA Consortium.
Alternatives 2: Too big gap
Business expert
IT infrastructure
GAP
Aris Grai Metis Moogo
GRIDP2PBDI Teams
WSA
POP* CIM
PIM
PSM
PIM4SOA
-The potential number of transformation to be performed is quadratic-The transformations have to translate from business to platform
-How we distinguies what should be automated?-How we guess the low level details such as type from the businessmodels?
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 7
7© 2005-2006 The ATHENA Consortium.
The challenge
Business expert
IT infrastructure
GAP
CIM
PIM
PSM
• The goal of creating the PIM4SOA metamodel was to define a language that could be used to describe SOAs at a platform independent level.– Which are the collaborations that need to
be implemented to perform the interoperability objectives stated at the business level?
– What is the sequence of messages exchanged to perform the collaboration?
– Which is the information exchanged?– Which are the non-functional
requirements that the interaction has to meet?
– ….• The resulting PIM4SOA should be
able to support a formal transition between enterprise models and IT implementations
The advantages of the service oriented approach are really not platform dependent, but arise from the conceptual architecture of more or less loosely coupled services. The goal of creating the PIM4SOA metamodel was to define a language that could be used to describe SOAs at a platform independent level. The resulting PIM4SOA should be able to support a formal transition between enterprise models and IT implementations
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 8
8© 2005-2006 The ATHENA Consortium.
PIM4SOA objectives
• Platform independent model for specifying service-oriented architectures– Represent SOA solutions in a platform independent
way– Integrate and define mappings to Web services,
agents, peer-to-peer (P2P) and Grid execution platforms.
– Bridging the gap between the enterprise layer and the technical layer
– Establishing relationships between layers through model-based transformations
– Two-way transformations supporting both• model-driven development (MDD); and• architecture-driven modernisation (ADM)
The objectives of the PIM4SOA are:Represent SOA solutions in a platform independent wayIntegrate and define mappings to Web services, agents, peer-to-peer (P2P) and Grid execution platforms.Bridging the gap between the enterprise layer and the technical layerEstablishing relationships between layers through model-based transformationsTwo-way transformations supporting round-trip engineering
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 9
9© 2005-2006 The ATHENA Consortium.
PIM4SOA requirements
Depending on the source of requirements• From the enterprise or business viewpoint
– Process, Organisation, Product and System (POPS) dimensions
– Mapping enterprise and business model elements to PIM4SOA
• From the platform point of view– What are the necessary PSM elements to be
represented at PIM level?– How do we identify these elements?– We need identify overlapping elements amongst
platforms
Requirements was collected from the enterprise/business view and the platform view:From the enterprise or business viewpoint
Process, Organisation, Product and System (POPS) dimensionsMapping enterprise and business model elements to PIM4SOA
From the platform point of viewWhat are the necessary PSM elements to be represented at PIM level?How do we identify these elements?We need identify overlapping elements amongst platforms
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 10
10© 2005-2006 The ATHENA Consortium.
Characteristics for metamodel
• Suited for target roles– Support domain concepts and scenarios of target roles– Ease-of-use and understandable for business modeller (use terms)– Support precise details and correctness for solution architect
• Avoid unnecessary complexity– Keep it simple stupid (KISS)– Number of elements and associations– Type and navigation of associations
• Make it modular– Provide core with extensions– Define and illustrate possible subsets (”dialects”) that support scenarios– Consider integration and extension points
• Suited for implementation– EMF representation– Transformation from/to UML profile– Transformation to PSM
Here are some of the overall characteristics for the metamodel:Suited for target roles
Support domain concepts and scenarios of target rolesEase-of-use and understandable for business modeller (use terms)Support precise details and correctness for solution architect
Avoid unnecessary complexityKeep it simple stupid (KISS)Number of elements and associationsType and navigation of associations
Make it modularProvide core with extensionsDefine and illustrate possible subsets (”dialects”) that support scenariosConsider integration and extension points
Suited for implementationEMF representationTransformation from/to UML profileTransformation to PSM
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 11
11© 2005-2006 The ATHENA Consortium.
Metamodel for (software) services Metamodel for (automated software) processes
Metamodel for information Metamodel for quality of service (QoS)
PIM4SOA addresses four system aspects
Services are an abstraction and an encapsulation of the functionality provided by an autonomous entity. Service architectures are composed of functions provided by a system or a set of systems to achieve a shared goal.
Web Services Architecture as proposed by W3C (W3C 2004)UML Profile for Enterprise Distributed Object Computing (OMG 2002)
Information is related to the messages or structures exchanged, processed and stored by software systems or software components.
Structural constructs for class modelling in UML 2.0 (OMG 2003)UML Profile for Enterprise Distributed Object Computing (OMG 2002)
Processes describe sequencing of work in terms of actions, control flows, information flows, interactions, protocols, etc.
Business Process Definition Metamodel(BPDM) (IBM et al. 2004)UML Profile for Enterprise Distributed Object Computing (OMG 2002)
Extra-functional qualities that can be applied to services, information and processes.
UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms (OMG 2004)
The PIM for SOA metamodel covers four important aspects: service, process, information and quality of service.Information: in the context of virtual enterprises information represents one of the most important elements that need to be described. In fact the other aspects manage or are based on information elements. Service: our main intention is to be able to describe SOA independently from the technology used. Service represents business accessible functionality. Process: processes describe a set of interactions amongst services in terms of messages exchange. QoS a suitable feature is the description and the modelling of non-functional aspects related with the services described.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 12
12© 2005-2006 The ATHENA Consortium.
Service metamodel
Collaboration– Collaboration represents a pattern of interaction
between participating roles– A binary collaboration specifies a service
CollaborationUse– The model element to represent a usage of a
service
Role– The model element to represent a usage of a
service
RoleBinding– Relates a role with a usage of a service.
RoleType– In a service oriented domain two are the
RoleTypes identified: the requester and the provider
Behaviour– An abstract class for the specification of
messages sequence within a service
ServiceProvider– Specify an entity describing and specifying in its
turn services, roles and constraints
ProviderType– The ServiceProviers can have to types: Abstract
ore Executable
EndPoint– Represents an address identifying a service
Registry– A Registry model element is based on index
approach containing addressable services
RegistryItem– Represents a service and an end point.
CollaborationCollaboration represents a pattern of interaction between participating roles. A binary collaboration specifies a service. A Collaboration definition contains a set of roles (provider, requester) and a set of collaboration use. Eventually it could be related with non-functional aspects. A Collaboration is related with a registry where it is specified the endpoints.CollaborationUseA CollaborationUse represents the usage of collaboration. In other words, a CollaborationUse is the model element to represent a usage of a service. The CollaborationUse contains a reference to the endpoint pointing out the address.RoleA Role represents a part involved in a service. In fact, this part is considered as a composite structure of a service. From a service point of view, a Role could be a requester or a provider. In addition a Role is described as a composite structure of a collaboration or a service provider.RoleBindingA RoleBinding relates a role with a usage of a service. When we specify a collaboration use we need to identify which are the roles involved This relationship is made between two Roles: one inside the collaborationUse and other inside a collaboration definition.RoleTypeIn a service oriented domain two are the RoleTypes identified: the requester and the provider. A RoleType provides a meaning for a specific part inside a collaboration and collaborationuse.BehaviourBehaviour is an abstract class for the specification of messages sequence within a service. This element represents a super class connecting a service aspect with process aspect. ServiceProviderA ServiceProvider specify an entity describing and specifying in its turn services, roles and constraints. ServiceProviderrepresents a service specification containing the specification of other services. Non functional aspects could also be added to specify quality aspects. These aspects are described using the OMG standard for quality of service. EndPointAn EndPoint represents an address identifying a service. This element satisfies the W3C definition and it identifies univocally a service. It contains a name and an address.RegistryA Registry model element is based on index approach containing addressable services. A Registry contains RegistryItemsand it references collaborations and their endpoints. It contains a set of registry items.RegistryItemA RegistryItem represents a service and an end point. A RegistryItem is contained by a registry.MessageA message model element defines a chunk of information sent from one role to other role in a collaboration. A message is owned by a specific role.MessageModeMessageMode differentiates between two kinds of messages.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 13
13© 2005-2006 The ATHENA Consortium.
Information metamodelItem
– Defines the set of elements that a role manages.ItemType
– Represents simple types: string, integer and boolean.
Role– is imported from the service metamodel.
PackageableElement– Extracted from the UML2.0 specification.
Association– Represents the association between two
entities. – It is used to describe complex types
Package– Extracted from the UML2.0 specification.
Document– Represents an object with a specific structure
and composed by entities.
TypeLibrary– defines a packaging structure containing some
types of the application
BusinessTypeLibraryEntity– represents a structure element of information
AttributeNameElement– extracted from the UML2.0 specification.
Element– extracted from the UML2.0 specification.
ItemItem defines the set of elements that a role manages.ItemTypeItemTypes represents simple types: string, integer and boolean.AssociationAssociation represents the association between two entities. It is used to describe complex types. Container, contained and cardinality are the attributes necessary to related elements.DocumentDocument represents an object with a specific structure and composed by entities. Document is a stereotyped package containing the structure of the document.TypeLibraryTypeLibrary defines a packaging structure containing some types of the application TypeLibrary is a stereotyped package containing data types.EntityEntity represents a structure element of information. Entity is a stereotyped class.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 14
14© 2005-2006 The ATHENA Consortium.
Process metamodel
Process elements
Process aspect
Scope– Scope is an abstract container for individual
behavioral steps
Step– Step is a single node in a process, such as
making a decision or calling an external service. The ‘everyday’ specialization of Step is Task
Process– Implements a behaviour for a service provider,
as a set of tasks and decisions (Steps) linked by control flows (Flows), optionally including detail on the exchanged messages / items.
StructuredTask– A composite task consisting of a collection of
Steps related to a specific subsection of a Process
Task– The low level ‘building blocks’ of a process
• calls to another service • require manual intervention
Task– Defines an interface for input or output flows on
a Step
Pin– Input or output for a specific item type when a
flow connects to a Step in the Process
Flow– Provide the links between Steps (tasks etc.) in
the behavior. A flow may be associated with a message type being transported.
ItemFlow– A flow between specific pins on interactions to
show precise relationships between output from one Step/Interaction and input on another
JoinSpecification– Defines convergence behaviour when two flows
provide input to a single Step/Interaction
GuardSpecification– Defines conditions (e.g. in terms of Pin contents)
under which an output flow is or is not activated
The process aspect is closely linked to the Service aspect, the primary link being the abstract class ‘Scope’ above, which can be instantiated as a Process belonging to a ServiceProvider from that aspect.The process contains a set of Steps (generally Tasks), representing actions carried out by the Process. A Process consists of StructuredTasks (sub-processes), Steps (atomic tasks and actions, at the PIM level), and Interactions/Flows linking the tasks together. These essentially fall into two categories, interactions with other Service Providers, or specialised actions requiring implementation beyond the scope of this model. For example, manual tasks to be processed by humans, or extensive computation requiring platform specific code.The Process also contains a set of Flows between these actions, which may be specialises (ItemFlow) to indicate the transfer of specific data. This allows flexibility in that a business modeller bay choose to start by showing only control flow, and later refine the model to include information. This links in to the Item/ItemType parts of the Information aspect. Flows may diverge or reconverge using Guard and Join specifications.ScopeScope is an abstract container for individual behavioural steps. This is subclassed only by Process and StructuredTask(Process is the top level behavioural object, StructuredTask may be used to group related Steps in a ‘subroutine’ like manner.)StepStep is a single node in a process, such as making a decision or calling an external service. The ‘everyday’ specialization of Step is Task.ProcessImplements a behaviour for a service provider, as a set of tasks and decisions (Steps) linked by control flows (Flows), optionally including detail on the exchanged messages / items.Structured TaskA composite task consisting of a collection of Steps related to a specific subsection of a ProcessTaskThe low level ‘building blocks’ of a process – these might be for example calls to another service (which can be transformed largely automatically to an implementation platform, with reference to the relevant collaborations) or might require manual intervention – either in the form of hand coded functions, or human interaction with the process.InteractionDefines an interface for input or output flows on a Step. Can be viewed as a set of Pins, though it is not compulsory to refine the model to this level (depending on aims of the model). If the step is viewed as a service, this is similar to the declaration of a method/function in the interface (specifying a set of parameters or a ‘return value’).PinInput or output for a specific item type when a flow connects to a Step in the Process. An example might be a CheckStockLevel task, with an input interaction, where one pin is tied to the item code being checked (perhaps of item type StockCode). If the step is viewed as a service, this is similar to an individual parameter to a function, or a component of the return value. The Parameter or Attribute referenced should be an appropriate sub-component of the message for the owning interaction.FlowFlows provide the links between Steps (tasks etc.) in the behaviour. A flow may be associated with a message type being transported.ItemFlowA flow between specific pins on interactions to show precise relationships between output from one Step/Interaction and input on another. This is the primary mechanism for data flow in the process model (see Pin)JoinSpecificationDefines convergence behaviour when two flows provide input to a single Step/InteractionGuardSpecification
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 15
15© 2005-2006 The ATHENA Consortium.
Non-functional metamodelNFA
– Represents Non-Functional Aspects for a specific usage of a service.
• defined in Collaboration and ServiceProviderspecification
• related with CollaborationUse element
All Others– Defined in the OMG standard for specifying
quality of service
As starting point this part of the metamodel is based on the quality of service OMG standard called UMLTM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms [24]. Therefore we have extracted a set of elements needed from this standard to describe QoS elements. Our main intention is not to implement the profile in its entirety but only the necessary elements for this domain. Additional elements need to be added to set the relationships between quality aspects and the other aspects.Most of elements in this metamodel have been defined in the OMG standard for specifying quality of service [24].NFANFA represents Non-Functional Aspects for a specific usage of a service. This element is defined in Collaboration and ServiceProvider specification. This element is related with CollaborationUse element.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 16
16© 2005-2006 The ATHENA Consortium.
Rapid prototyping with PIM4SOA
Rapid prototyping with PIM4SOA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 17
17© 2005-2006 The ATHENA Consortium.
Rapid prototyping framework for SOA
PIM4SOA
MDD FrameworkWSDL Documents BDI Teams
WSDL Analyzer
External WSDL Documents
Lyndon
Johnson Jack«invoke» «invoke»
• Johnson and Lyndon provide enactment of all the roles found in an SOA (consumer, provider, intermediary) and flexible communication between Web services through an intuitive user interface• The WSDL Analyzer tool detected syntactical mismatches between service descriptions and provides a basis for runtime mediation of Web service messages
• The Web service extensions to the JACK autonomous agents platform allow SOAs to use agents for brokering, mediation and negotiation between Web services• BDI teams provide a flexible and composablealternative to traditional approaches to Web service composition
• The ATHENA baseline methodology for SOA provides guidelines for developing platform independent models for SOA (PIM4SOA).• Provides a set of modelling tools and services for mapping between PIM4SOA and platform specific models (Web services and BDI agents)
AgentsServices
Modelling
The framework for Rapid Prototyping of SOAs presented here is composed of three parts: a modelling part, a service part and an autonomous agent part.The modelling part is concerned with applying Model-Driven Development (MDD) techniques and tools to the design of SOAs. It defines models and transformations that are specific to the concepts used for SOAs, such as Web Service descriptions and plans for autonomous agents. The service part provides a highly flexible communication platform for Web services. The autonomous agent part deals both with designing and enacting service compositions as well as performing mediation, negotiation and brokering in SOAs.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 18
SemanticSpace
Service-OrientedArchitecture Model
Web ServiceExecution Artefacts
AgentExecution Artefacts
BPELExecution Artefacts
P2PExecution Artefacts
Web ServiceSpecification Model
Agent SpecificationModel
BPEL SpecificationModel
P2P SpecificationModel
Model Transformation
UML Profile for Web ServicesUML Profile for AgentsUML Profile for BPELUML Profile for P2P
Model Transformation
Architecture Specification
ATHENA IntegratedExecution Infrastructure
RegistryRepository
Service Wrappers (Enterprise A)
Evaluation & Negotiation of Available Functionality
Enhanced Service Interconnection Bus
Cross-org.
Intra-org.
Existing Enterprise Applications
PublicInfrastructure Services
Service Wrappers(Enterprise X)
Service Wrappers(Enterprise Y)
InternalInfrastructure Services
Process Execution Platform(BPEL)
Goal-orientedAdaptive ExecutionPlatform(Agents)
Goal-orientedAdaptive ExecutionPlatform(Agents)
ActiveModel Platform(AKMii)
ActiveModel Platform(AKMii)
Legend
Message-OrientedPlatform(MQSeries)
Message-OrientedPlatform(MQSeries)
Server-side Component Platform(.NET, J2EE)
Server-side Component Platform(.NET, J2EE)
ComposedWebServicePlatform(WebServices)
Business Process/Agent
Active (Business) Model
Web/Server Component
Middleware Process/Agent
Middleware Component
Adaptive Distributed Resource Mgt Platform (P2P)
Deployment
UML Profile for SOA• Information• Service• Process• QoSR
efer
ence
Ont
olog
y
annotated with
Model to Model Transformation
Model to TextTransformation
OWLOntology
annotatedwith
annotatedwith
EnterpriseModel
UML Profile for POP*• Process• Organisation• Product• …
Model to ModelTransformation
Business Requirements
Analysis
annotated with
ATHENA baseline methodology for SOA (overview)
The ATHENA baseline methodology for SOA introduces a model-driven development (MDD) approach to specifying interoperable service-oriented architectures realized as Web services. In model-driven development are used models to describe business concerns, user requirements, activities, information structures, components and component interactions. These models govern the system development in that they can be transformed to program code. We aim to develop tools to automate model transformations for service-oriented architectures. Hence, the term model-driven development in our context encompasses both the development of models, and tools for model transformation. The models are expressed in UML, and supported by UML profiles for SOA and Web services. The baseline methodology provides guidelines for how to develop the different kinds of models recommended for SOA. Some of them lay the basis for automated code generation; all of them contribute to the understanding and specification of the system or services to be developed.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 19
Method chunks for SOA andWeb Service Interoperability
ReferenceOntology
annotatedwith
WSDLDocument
OWL-SDocument
BPELDocument
BDIPlan
XSDDocument
WS-?Document
ATHENA Web ServiceExecutionInfrastructure
Model Registry (A6)
Other Com
pany
Internal Service Interconnection Bus
WrappersLegacy Applications
Execution
Service
Service
Composition
Nehem
iah (A2)
JACK
Mediation
ARES (A3)
Evaluation
ServiceModels
PlatformModels
ContractModels
Compo-sition
Models
Negotiation
ExternalRegistry
Publishing
Interaction
...
Brokering
Brokering Tool (A5)
OWLOntology
annotatedwith
UML Profile for POP*• Process• Organisation• Product• …En
terp
rise
Mod
el
ProcessView
OrganisationView
ProductView
…View
1
1
Model to ModelTransformation
Business Requirements
Analysis
SOA
Mod
el
InformationView
ServiceView
ProcessView
QoSView
UML Profile for SOA• Information• Service• Process• QoS
annotatedwith
XMLMessage
ServiceDescription
ProcessExecution
QoSDescriptionW
eb S
ervi
ceM
odel
UML Profile for Web Services• XML Message (XSD)• Service Description (WSDL)• Process Execution (BPEL)• QoS
Model to ModelTransformation
1
1..*
Model to TextTransformation
Web
Ser
vice
Doc
umen
ts
1..*
1..*
ATHENA baselinemethodology for SOA (detailed)
The figure illustrates the full methodology which addresses a complete MDD approach supporting multiple execution platforms.The Service-Oriented Architecture Model is a platform independent model (PIM) which specifies services in a technology independent manner. Here we will describe business services according to a UML profile for SOA.A Web Service Specification Model is a platform specific model (PSM) which refines a business service in the PIM and specifies it as a Web service using the UML Profile for Web Services. From this model we can generate a concrete Web Service Execution Model that can be deployed on a Web service platform in the Integrated Execution Infrastructure.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 20
20© 2005-2006 The ATHENA Consortium.
MDI modelling environment
ATHENA ExecutionInfrastructure
ModelRepository
ModelTransformation
(ATL, MTF)
Execution Platform andInfrastructure Services(WS, Agents, BRMF, …)
Eclipse/RSM Platform
CollaborativeEnterpriseModelling
Cross-Organisational
BusinessProcess
Modelling
ServiceIntegration
andComposition
Modelling
InformationMapping
Modelling
PlatformIntegrationModelling
The intended users of the ATHENA MDI Environment specified are software engineers such as IT architects and developers who are faced with interoperability challenges when integrating existing software applications or services, re-architecting their legacy application systems, and developing new services in a service-oriented architecture.
The figure shows a high-level view of the MDI environment. The focus in this course is on interoperability modelling for SOA and Web services. While tools for collaborative enterprise modelling and cross-organisational business process modelling are presented in other courses. The MDI environment should also provide support for integrating with enterprise/business modelling tools. This enables some alignment and traceability to be managed between enterprise/business models and software models.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 21
21© 2005-2006 The ATHENA Consortium.
PIM for SOAInformation Service Process QoS
CBP
XSD WSDL BPEL WS-?BRMF Jack
ARIS POP*
UML Profile for SOA
UML*
Maestro
Model 2 Model
Model 2 Text
Import / ExportModel 2 Model
Export + XML 2 Model
CBP: Collaborative Business ProcessPIM: Platform Independent ModelSOA: Service-Oriented ArchitectureXSD: XML Schema Definition
BRMF: Business Resource Management FrameworkWSDL: Web Service Description LanguageBPEL: Business Process Execution Language
Tools and services (overview)
A number of transformations to and from the PIM4SOA have been developed.POP* to PIM4SOA: POP* is a metamodel and methodology to enable exchange of
enterprise models between enterprise modelling tools. It plays a similar role to PIM4SOA at the CIM level of the MDA.
Maestro to PIM4SOA: The Maestro is a modelling tool for Collaborative Business Processes. This set of transformations enable business models described using Maestro to be transformed into a platform-independent level.
ARIS to PIM4SOA: The third CIM-to-PIM level transformation provided as part of the MIDE infrastructure is a set of transformations from ARIS Event-driven Process Chain (EPC) models to PIM4SOA with a focus on the requirements on CBPs. Given the immense role of ARIS for industry, there is a high interest in and impact of architectural and tool support for extending the scope of the conceptual extensions to ARIS for CBP from a mere business analyst level down to the ICT level.
Furthermore, model transformations from the PIM4SOA to technology platforms such as Web services, agents and P2P were planned and some of these implemented. We will revisit those transformations in a later part of this course.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 22
22© 2005-2006 The ATHENA Consortium.
RSM and UML profile for PIM4SOA
The figure shows several different screenshots from RSM indicating how to install and use the plugins available in the feature:The PIM4SOA feature can easily be made available as a downloadable and installable feature for RSM.Once installed, the user can select and use the different plugins available, e.g. the Athena pim4soa Profile and the library for PIM Types can also be chosen.After having selected the PIM4SOA plugins you will be able to create PIM4SOA process modelling elements like <<xstructure, task>> in UML models.Specific menus (for e.g. diagrams) can be added to the RSM environment to allow an end-user to more easily develop service-oriented software models in UML.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 23
23© 2005-2006 The ATHENA Consortium.
Case study: AIDIMA e-procurement scenario
Case study: AIDIMA e-procurement scenario.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 24
24© 2005-2006 The ATHENA Consortium.
Introduction to business scenario
• Scenario is based on the current situation of the furniture SMEs regarding the procurement issues
• Value in the furniture industry is concentrated in design, manufacturing, sales and marketing– Clear benefit from the adoption of e-commerce initiatives
• Initiatives in the field of e-procurement of raw and semi-finished materials in the coming years– Significant benefits to be achieved in terms of cost reduction and
efficiency • Distribution in the furniture industry is structured in a
complex way– Extranets and Internet-enabled supply-chain automation should
optimize the relationships• Order management and logistics with e-commerce
implementations– Beneficial to the furniture industry
Scenario is based on the current situation of the furniture SMEsregarding the procurement issuesValue in the furniture industry is concentrated in design, manufacturing, sales and marketing
Clear benefit from the adoption of e-commerce initiativesInitiatives in the field of e-procurement of raw and semi-finished materials in the coming years
Significant benefits to be achieved in terms of cost reduction and efficiency
Distribution in the furniture industry is structured in a complex wayExtranets and Internet-enabled supply-chain automation should optimize the relationships
Order management and logistics with e-commerce implementationsBeneficial to the furniture industry
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 25
R3. Order
R1. Request for QuotationR2. Quotation
R4. Order Confirmation
Interior Decoration
Project
M2. Quotation
M1. Request for Quotation
M3. OrderM4. Order Confirmation
MANUFACTURER
RETAILERPROVIDER
● Retailer-Manufacturer● 1. RFQ● 2. Quote● 3. Order
● Manufacturer-Supplier● 1. RFQ● 2. Quote● 3. Order● 4. Order Confirmation
● Retailer-Manufacturer● 4. Order Confirmation
The following diagram states a first draft of what the scenario implies, as well as the document flowbetween the different actors involved in the e-Procurement scenario: Retailer, Manufacturer andProvider. These documents are marked as follows:o Rn. XXX. This document is part of the Retailer’s side of the scenario. In this part, TheRetailer asks for some pieces of furniture and the Manufacturer serves them.o Mn. XXX. On the other hand, the documents named in this way, are part of the Manufacturerprocurement side. In this part, the Manufacturer asks for some raw material and the Providerserves it.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 26
26© 2005-2006 The ATHENA Consortium.
Selling process: Customer-oriented scenario
Delivery
R5. Delivery NoteR6. Packing List R7. Invoice
Customer communication
R3. Order
R1. Request for QuotationR2. Quotation
R4. Order Confirmation
Interior Decoration Project
Looks for furniture
Invoice
Delivery
MANUFACTURER
RETAILER
This figure includes another element in the document flow: the Interior Decoration Project. The InteriorDecoration Project (Deco project) is a draft performed by the Retailer according to the Consumer’swilling. In a Deco Project, the pieces of furniture are placed in a room and taking into account thespecial configuration of the room (dimensions, shape, walls, painting, …).
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 27
27© 2005-2006 The ATHENA Consortium.
Procurement process: Supplier-oriented scenario
M2. Quotation
M6. Invoice
M1. Request for Quotation
M3. OrderM4. Order Confirmation
MANUFACTURER
PROVIDER
M5. Delivery Note
Delivery
This figure shows the procurement process as viewed from the supplier.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 28
28© 2005-2006 The ATHENA Consortium.
5 main problems
1. Repetitive manual process for regular bulk orders– Much of the manufactured products are generic and this involves
repeated periodic processing of similar or identical orders2. Confusion resulting from poor product descriptions
– Clients very often order the wrong products!3. Missing information (both from supplier and buyer!)
– Permasa have 3 people employed on the client site and 1 person employed on the supplier side to ensure the integrity of orders and RFQs
4. Lag time from product order to delivery could be shorter.– Shortening time from ordering to receiving raw materials from the
supplier has a direct effect on the delivery date of the finished product5. Time spent rating supplier
– Permasa conducts tri-monthly reviews of their suppliers to ensure that standards are kept
Repetitive manual process for regular bulk ordersMuch of the manufactured products are generic and this involves repeated periodic processing of similar or identical orders
Confusion resulting from poor product descriptionsClients very often order the wrong products!
Missing information (both from supplier and buyer!)Permasa have 3 people employed on the client site and 1 person employed on the supplier side to ensure the integrity of orders and RFQs
Lag time from product order to delivery could be shorter.Shortening time from ordering to receiving raw materials from the supplier has a direct effect on the delivery date of the finished product
Time spent rating supplierPermasa conducts tri-monthly reviews of their suppliers to ensure that standards are kept
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 29
29© 2005-2006 The ATHENA Consortium.
5 main expectations
1. Major reduction in false/incorrect orders2. Dramatic shortening of time from order to delivery3. Dramatic reduction in surplus stock in warehouse4. Ability to search new providers and apply Permasa
criteria to rate those providers5. Better integration between internal systems. (i.e. Stock,
purchasing, manufacturing, invoicing sub-systems)
Major reduction in false/incorrect ordersDramatic shortening of time from order to deliveryDramatic reduction in surplus stock in warehouseAbility to search new providers and apply Permasa criteria to rate those providersBetter integration between internal systems. (i.e. Stock, purchasing,
manufacturing, invoicing sub-systems)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 30
30© 2005-2006 The ATHENA Consortium.
Possible solution
Database (OS400)
Sales Mgmt. (ILE)
Manufacturing (ILE)
Purchasing (ILE)
Web Services Layer
Customer Order processing Procurement
Logistics(ILE)
Client Supplier
Design(AutoCAD)
Integration Layer
The Furniture e-Procurement scenario is divided in two parts depending on the role that Permasa is playing. Ineach case, apart from them there is another company implied: either a Supplier either a Retailer. Each of the subapplications identified in the above diagram (Logistics, Sales Management, Manufacturing and Purchasing) arecustom built applications running on an IBM AS/400 system programmed in ILE (Integrated LanguageEnvironment)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 31
31© 2005-2006 The ATHENA Consortium.
Data exchange in e-procurement
RetailerFrontEndSystem
(OMS – Order Management System)
ManufacturerFrontEndSystem
(ERP – Enterprise Resource Planning)
Send RFQ
Respond RFQQuotation
Approve QuotationSend Order
Confirm Order
Change Order
Send Goods & Delivery Note
Return Delivery Note signed
Send Invoice
Confirm Order Changed
In the following we list all the messages to which correspond a suitable xml schema involved in thisprocess:1) Send RFQ – Retailer sends the RFQ to the manufacturer2) Add Quote – Manufacturer send a Quote to Retailer3) Add Order – Retailer accepts the Quote and send the purchase order to Manufacturer4) Confirm Order – Manufacturer confirms the order to the Retailer5) Change Order – Retailer changes Order6) Confirm Order – Manufacturer confirms the changed version of the order7) Order Status Request – Retailer sends a Request of the Status of the order to Manufacturer8) Order Status Response – Manufacturer responds to the Status Request received9) Send Dispatch Advise – Manufacturer sends to Retailer an advise stating the goods are goingto be sent promptly10) Send Delivery Note – Manufacturer send the Delivery Note at the same time as the goods11) Send Receiving Advise – Retailer sends to Manufacturer an advise stating the goods areserved12) Confirm Delivery Note – Retailer signs the Delivery Note after checking the goods areperfectly well and sends back to Manufacturer
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 32
32© 2005-2006 The ATHENA Consortium.
Enterprise model: e-procurement process
This is a model of the e-procurement scenario as modelled in an enterprise modelling tool. This model serves as an input to the PIM4SOA modelling.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 33
33© 2005-2006 The ATHENA Consortium.
PIM4SOA: Order process
This is a model of the order process using the UML profile for PIM4SOA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 34
34© 2005-2006 The ATHENA Consortium.
PIM4SOA: Services interfaces
This is a model of the interface for the service ManufacturerService. It has four operations that handles order, orderResponse, quation and requstForQutiationinformation.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 35
35© 2005-2006 The ATHENA Consortium.
PIM4SOA: Delivery and invoicing collaborations
This is a model of two collaboration for delivery and invoicing that are part of the scenario.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 36
36© 2005-2006 The ATHENA Consortium.
PIM4SOA: Obtain quotation collaboration
This is a model of the obtain quotation collaboration. The requestor and the provider taking part in such a collaboration has to implement the interfaces quotation requestor and the quotation provider respectively.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 37
37© 2005-2006 The ATHENA Consortium.
PIM4SOA: Furniture procurement collaboration
• Three roles – “Retailer”,– ”Manufacturer”– “Supplier”
• Two usage of collaboration – “Goods Supply”– “Materials Supply”
• Relationshipsbetween role and collaboration use
– “RoleBinding”
This is a model of the furniture procurement collaboration with all of the three participating roles. Binary collaborations between the interacting roles are further detailed. Let us look at the collaboration goods purchasing which makes use of the goods supply collaboration.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 38
38© 2005-2006 The ATHENA Consortium.
PIM4SOA: Goods supply collaboration
This is a model of the goods supply collaboration.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 39
39© 2005-2006 The ATHENA Consortium.
PIM4SOA: Documents and type libraries
Documents andtype libraries
Type library
Here we have modelled the information (or documents) that are exchanged in the collaborations. Common type or information fragments are stored in type libraries so they can be reused.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 40
40© 2005-2006 The ATHENA Consortium.
Model of anorder document
PIM4SOA: Order document
This is a model of the the order document.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 41
41© 2005-2006 The ATHENA Consortium.
Conclusions
• The PIM4SOA metamodel is a valid tool to decouple the logical solution from its technical implementation.
• It allows us to derive architectures that later could be implemented in heterogeneous environments.
• The PIM4SOA could be also used as an intermediate step when we plan to obtain platform assets from an enterprise model.
Business expert
IT infrastructure
GAP
CIM
PIM
PSM
The PIM4SOA metamodel is a valid tool to decouple the logical solution from its technical implementation. It allows the definition of an architecture from a more conceptual level, which later can be transformed to platform specific architectures such as the WSA or the agent architecture. Moreover, it can allow us to define architectures that later could be implemented in heterogeneous environments.The PIM4SOA could be also used as an intermediate step when we plan to obtain platform assets from an enterprise model. As we already have transformations from the PIM4SOA to the platform assets, we will only have to implement the transformation from the enterprise model to the equivalent PIM4SOA. Then we will reuse the existing transformations to obtain the platform specific assets for the initial enterprise model.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 42
42© 2005-2006 The ATHENA Consortium.
References
References.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 43
43© 2005-2006 The ATHENA Consortium.
References (ATHENA deliverables)
[ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http://www.athena-ip.org/
[ATHENA A5 2005] ATHENA A5, "D.A5.1: Perspectives on Service-Oriented Architectures and thereapplication in environments that require solutions to be planned and customisable", ATHENA IP, Deliverable D.A5.1, 2005.
[ATHENA A5 2005] ATHENA A5, "D.A5.2: Model and Specification of Service Descriptions and Usage as well as Advanced Concepts", ATHENA IP, Deliverable D.A5.2, 2005.
[ATHENA A5 2006] ATHENA A5, "D.A5.3: Architecture of SOA Platforms", ATHENA IP, DeliverableD.A5.3, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.4: Execution Framework(s) for Planned and CustomisableService-Oriented Architectures", ATHENA IP, Deliverable D.A5.4, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.5: Validation of Research Results", ATHENA IP, DeliverableD.A5.5, 2006.
[ATHENA A6 2005] ATHENA A6, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP, Deliverable D.A6.1, 2005.
[ATHENA A6 2006] ATHENA A6, "D.A6.2: Enhanced Registry/Repository Infrastructure", ATHENA IP, Deliverable D.A6.2, 2006.
[ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006.
[ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.
List of relevant ATHENA deliverables.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 44
44© 2005-2006 The ATHENA Consortium.
References (Papers)
[Benguria, et al. 2006] G. Benguria, X. Larrucea, B. Elvesæter, T. Neple, A. Beardsmore, and M. Friess, ”A Platform Independent Model for Service Oriented Architectures”, to be presented at the 2nd International Conference on Interoperability of Enterprise Software and Applications (I-ESA 2006), Bordeaux, France, 2006.
[Elvesæter, et al. 2005] B. Elvesæter, A. Hahn, A.-J. Berre, and T. Neple, "Towards an Interoperability Framework for Model-Driven Development of Software Systems", in Proc. of the 1st International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA 2005), Geneva, Switzerland, 2005.
[Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134.
[Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B. Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 121-128.
[Fischer, et al. 2006] K. Fischer, B. Elvesæter, A.-J. Berre, C. Hahn, C. Madrigal-Mora, and I. Zinnikus, ”Model-Driven Design of Interoperable Agents”, to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.
[Vayssière, et al. 2006] J. Vayssière, G. Benguria, B. Elvesæter, K. Fischer, and I. Zinnikus, "Rapid Prototyping for Service-Oriented Architectures", to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.
List of relevant papers published from ATHENA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-2
Version 5
© 2005-2006 The ATHENA Consortium. 45
45© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 1
© 2005-2006 The ATHENA Consortium.
6-3. From PIM4SOA toWeb Services
<Presenter><Company>, <Country><E-mail>
Part 6-3. From PIM4SOA to Web services.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 2
2© 2005-2006 The ATHENA Consortium.
PIM4SOAMetamodel
Web ServicesMetamodel
Agent Metamodel(AgentMM)
P2PMetamodel
GridMetamodel
PIM
PSM
s
Symbols
Metamodel
Concept
RelationshipCorrespondence
PIM4SOA → platform specific models
We identified Web services, agents, P2P and GRID as four target platforms for the PIM4SOA metamodel. We will now look more closely at the PIM4SOA metamodel. We will now look into the mappings from PIM4SOA to Web services.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 3
3© 2005-2006 The ATHENA Consortium.
PIM4SOA → platform specific models
PIM4SOAsourcemetamodel
Web servicestargetmetamodels
Mappingmodel
This figure illustrates the three mapping models that we have to define.A mapping model from the PIM4SOA information metamodel to XSD.A second mapping model from the PIM4SOA service metamodel to WSDL.And finally a third mapping model from the PIM4SOA process metamodel to BPEL.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 4
4© 2005-2006 The ATHENA Consortium.
Web services architecture metamodel
Registry<<Metamodel>>
+ UDDI.
Endpoint Description<<Metamodel>>
+ WS-MetadataExchange.+ WS-Policy.
+ WS-PolicyAttachement.
Service Interface Description
<<Metamodel>>
+ WSDL 1.1.+ WSDL 2.0.
Reliability<<Metamodel>>
+ WS-ReliableMessaging.Coordination
<<Metamodel>>
+ WS-Coordination.
Eventing<<Metamodel>>
+ WS-BaseNotification.+ WS-BrokeredNotification.
+ WS-Eventing.+ WS-Topics.
Resource Access and Management
<<Metamodel>>
+ WS-Enumeration.+ WS-Resource.
+ WS-ResourceLifetime.+ WS-ResourceProperty.
+ WS-Transfer.
Transport<<Metamodel>>
+ HTTP.
Messaging<<Metamodel>>
+ SOAP.+ WS-Addressing.
XML<<Metamodel>>
+ XML Core / XSD.+ XML Encryption.+ XML Signature.
+ XPATH.
Security<<Metamodel>>
+ WS-Security.
eContract<<Metamodel>>
+ ATHENA eContract Extensions.
Composition<<Metamodel>>
+ ACE-GIS Composition Extensions.+ WS-BPEL.+ WS-CDL.
The world of Web services is far from being one coherent set of interrelated specifications. The different specifications that make up the so-called WS-* stack arose out of a combination of loosely-coordinated ad-hoc industry efforts, regular standardization processes such as that of the W3C [1] or OASIS [2], and vendors competing by pushing for “their” specification to become a de-facto standard.The total number of WS-* specifications proposed at some point or another in time is not far from a hundred. Some of these specifications have since then been superseded, abandoned or merged together, while others are still in the process of getting finalised. It will probably take a few more years for all parties to agree on a common set of specification. In the meantime, practitioners have to do with a WS-* landscape that is a combination of mature and accepted specifications, such as XML, SOAP and WSDL, nearly-there specifications, such as WS-Addressing and WS-Security, and still-immature specifications, such as WS-ReliableMessaging.The figure above shows a logical grouping of the WS-* metamodels.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 5
5© 2005-2006 The ATHENA Consortium.
WSDL 1.1 metamodel
WSDL DocumentWSDL Component
0..10..1
Port+ Name
Operation+ Name
Part+ Name+ Type+ Element
Service
+ Name
1..*1..*
Binding
+ Name
1
1
1
1
Port Type
+ Name11 11
Message+ Name
1..*
0..1
1..*
+input
0..1 0..1+output
0..10..1+fault 0..1
0..*0..*
Import
+ NameSpace+ Location
Include
+ Location
Element+ Name+ BaseType+ MinOccurs+ MaxOccurs
Definition
+ Name+ TargetNameSpace0..*0..*
0..*0..* 0..*0..*
0..*0..*
0..*0..*
Schema+ TargetNameSpace
Types
0..10..1
A collection of related endpoints
A single endpoint defined as a combination of a binding and a network address
A concrete protocol and data format specification for a particular port type
An abstract set of operations supported by one or more endpoints
An abstract, typed definition of the data being communicated
An abstract, description of an action supported by the service
A container for data type definitions
A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. Services are defined using six major elements:Types, which provides data type definitions used to describe the messages exchanged. Message, which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system. Port type, which is a set of abstract operations. Each operation refers to an input message and output messages. Binding, which specifies concrete protocol and data format specifications for the operations and messages defined by a particular port type. Port, which specifies an address for a binding, thus defining a single communication endpoint. Service, which is used to aggregate a set of related ports.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 6
6© 2005-2006 The ATHENA Consortium.
PIM4SOA model (.uml2)
WS-* model (.uml2)
UML profile for Web services
Web service artefacts
EMF EcoreMetamodels/Models
RSMUML Models and Profiles
XSD
WSDL
BPEL
XSD
WSDL
BPEL
M2M
M2M
UML profilefor PIM4SOA
PIM4SOA model (. ecore)
WS-* models (.ecore)
M2MM2T
M2M
1
2
3 4
X
Eclipse/RSM modelling environment
1. Build your PIM4SOA (.uml2) model in RSM using the UML profile for PIM4SOA and transform it to a PIM4SOA (.ecore) model in EMF.
2. Transform the PIM4SOA (.ecore) model to Web service (.ecore) models.
3. Transform the Web service (.ecore) models to Web service artefacts.
4. Model transformation for UML profiles for Web services
• Eclipse Modelling Framework (EMF)
• Rational Software Modeler (RSM)
Build your PIM4SOA (.uml2) model in RSM using the UML profile for PIM4SOA and transform it to a PIM4SOA (.ecore) model in EMF.
Transform the PIM4SOA (.ecore) model to Web service (.ecore) models.
Transform the Web service (.ecore) models to Web service artefacts.
Model transformation for UML profiles for Web services
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 7
7© 2005-2006 The ATHENA Consortium.
Transformation to XSD
• The XSD artefacts are generated from the Information part of the PIM4SOA model.
• The starting point for the transformation is a PIM4SOA document.
• The strategy is to convert one PIM4SOA Document into one XML schema.
• The mappings between the most relevant PIM4SOA elements and XSD are listed next.
The XSD artefacts are generated from the Information part of the PIM4SOA model. The starting point for the transformation is a PIM4SOA document.The strategy is to convert one PIM4SOA Document into one XML schema. The mappings between the most relevant PIM4SOA elements and XSD are listed next.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 8
8© 2005-2006 The ATHENA Consortium.
PIM4SOA main mappings to XSD
If the ItemType from the PIM4SOA model is not an entity (meaning it is a simple type) a SimpleTypedefinition is created in the schema.
SimpleTypeElement
Attributes having simple types are mapped to Attributes in complex types. Attributes with complex types in the PIM4SOA model are mapped in the same way as Associations.
AttributeAttribute
An association between entities is transformed into an element in the containing type with a reference to the complex type generated for the target Entity
ElementAssociation
ComplexTypeEntity
SchemaDocument
NotesXSD equivalentPIM4SOAelement
The PIM4SOA to XSD transformation has been developed as a model to model transformation using the metamodels for PIM4SOA and XSD as source and target. The XSD metamodel used is the one provided by the Eclipse Modeling Framework project[1]. This EMF based metamodel provides built-in serialisation and de-serialisation of XSD documents. The transformation it self is written in Java and packaged as an Eclipse plugin.
[1] http://www.eclipse.org/emf
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 9
9© 2005-2006 The ATHENA Consortium.
Transformation to WSDL
• The WSDL artefacts are generated from the Service part of the PIM4SOA model.
• While the mapping of the PIM4SOA to XSD was quite straight forward, the mapping to WSDL is a bit more complex.
• The WSDL generated has links to the XML schema, as the messages in the PIM4SOA model get their structural information from the Information part of the PIM4SOA models.
The WSDL artefacts are generated from the Service part of the PIM4SOA model.While the mapping of the PIM4SOA to XSD was quite straight forward, the mapping to WSDL is a bit more complex.The WSDL generated has links to the XML schema, as the messages in the PIM4SOA model get their structural information from the Information part of the PIM4SOA models.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 10
10© 2005-2006 The ATHENA Consortium.
PIM4SOA main mappings to WSDL
A binary Collaboration (only two roles) that does not contain any CollaborationUses (leaf Collaboration) is transformed into an operation. If only one of the Roles in the Collaboration have Messages an asynchronous pattern is generated meaning that two operations are created, each in different PortTypes; one for the provider and one for the consumer.
OperationCollaboration
A role binding within a CollaborationUse is a potential PortType. It is transformed into a PortType if the role it is bound to is part of a binary Collaboration without any CollaborationUses (a leaf collaboration)
PortTypeRoleBinding
If the PIM4SOA Message has a type assigned to it, theWSDL message is created with one Part corresponding to hat type. If not one Part is created for each of the Items contained by the PIM4SOA Message.
MessageMessage
The transformation takes a complete PIM4SOA model asinput and creates on WSDL artefact per model.
DefinitionPackage
NotesWSDLequivalent
PIM4SOAelement
The PIM4SOA to WSDL transformation has been developed as a model to model transformation using the metamodels for PIM4SOA and WSDL as source and target. The WSDL metamodel used is the one provided by the Eclipse Webtoolsproject[1]. This EMF based metamodel provides built-in serialisation and de-serialisation of WSDL documents. The transformation it self is written in Java and packaged as an Eclipse plugin.
[1] http://www.eclipse.org/webtools
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 11
11© 2005-2006 The ATHENA Consortium.
Transformation to BPEL
• Starting point for a BPEL transformation – PIM4SOA ServiceProvider participating in at least one
Collaboration and implementing a Behaviour as a PIM4SOA Process.
• The transformation from PIM4SOA to BPEL are closely tied to the generation of the WSDL interfaces
• The WSDL transformation allows – collaborations in which a ServiceProvider participates
to be converted to Services and Porttypes, and Partnerlink types to be referenced in the BPEL.
Starting point for a BPEL transformation PIM4SOA ServiceProvider participating in at least one Collaboration and implementing a Behaviour as a PIM4SOA Process.
The transformation from PIM4SOA to BPEL are closely tied to the generation of the WSDL interfaces The WSDL transformation allows
collaborations in which a ServiceProvider participates to be converted to Services and Porttypes, and Partnerlink types to be referenced in the BPEL.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 12
12© 2005-2006 The ATHENA Consortium.
PIM4SOA main mappings to BPEL
This defines a specific use of a PartnerLink, alongside what role we are playing, and even the PortType being used. See links to the WSDL transformation described below.
PartnerLink, Role(…) CollaborationUsePath
The CollaborationUses defined for the ServiceProvider tell us what PartnerLinks we will need. See CollaborationUsePath.
PartnerLinkCollaborationUseRoleBinding
All messages sent and received must have appropriate variables defined within the BPEL
VariableMessage
Interactions have a role to play both in determining collaboration type (see Task (ii) above), and passing particular parts of messages between tasks (data flow, a BPEL assign).
AssignInteraction, Pin
The structure of flows between Steps must be analysed to deduce the applicable BPEL structure.
Sequence, Flow, (…)Flow
This might be a task requiring further implementation or human interaction beyond the scope of the PIM4SOA.
EmptyTask (ii) (no collaboration use)
The type of communication with other service providers must be deduced from parameters passed to or from the task in question.
Receive, Invoke, ReplyTask (i) (participating in collaboration)
ProcessServiceProviderProcess
NotesBPELequivalent
PIM4SOA element
The transformation from PIM4SOA to BPEL is closely tied to the generation of the WSDL interfaces. The WSDL transformation allows the collaborations in which a ServiceProvider participates to be converted to Services and Porttypes, and Partnerlink types to be referenced in the BPEL are also generated as part of this process.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 13
13© 2005-2006 The ATHENA Consortium.
Model transformations overview
RTT ATL
EMF RSM
eProcModel(.emx)
BPEL Document(.bpel)
WID
UML Profile forPIM4SOA (.epx)
<<applied>>
EMF: Eclipse Modeling FrameworkRSM: Rational Software Modeler UML modelling toolPIM4SOA Plugin: RSM plugin – UML Profile for PIM4SOARTT: Rational Transformation ToolsMTF: Model Transformation Framework
PIM4SOAPlugin
MTF
eProcModel
(.ecore)
BPELMetamodel
(.ecore)
MOFScript
WSDLMetamodel
(.ecore)
PIM4SOA toWeb Service ModelTransformation (.atl)
WSDL UMLModel (.xmi)
WSDL UML toWSDL DocumentGeneration (.m2t)
WSDL Document(.wsdl)
EclipseWST
a)b)
c)
ATL: Atlas Transformation Language model to model transformation toolMOF Script: SINTEF model to text transformation toolEclipse WST: WSDL graphical editorWID: WebSphere Integration Developer
PIM4SOAMetamodel
(.ecore)
UML 2.0Metamodel
(.ecore)
eProc Model(.ecore)
This picture gives an overview of the technologies used to implement the three different model transformations.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 14
14© 2005-2006 The ATHENA Consortium.
References
References.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 15
15© 2005-2006 The ATHENA Consortium.
References (ATHENA deliverables)
[ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http://www.athena-ip.org/
[ATHENA A5 2005] ATHENA A5, "D.A5.1: Perspectives on Service-Oriented Architectures and thereapplication in environments that require solutions to be planned and customisable", ATHENA IP, Deliverable D.A5.1, 2005.
[ATHENA A5 2005] ATHENA A5, "D.A5.2: Model and Specification of Service Descriptions and Usage as well as Advanced Concepts", ATHENA IP, Deliverable D.A5.2, 2005.
[ATHENA A5 2006] ATHENA A5, "D.A5.3: Architecture of SOA Platforms", ATHENA IP, DeliverableD.A5.3, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.4: Execution Framework(s) for Planned and CustomisableService-Oriented Architectures", ATHENA IP, Deliverable D.A5.4, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.5: Validation of Research Results", ATHENA IP, DeliverableD.A5.5, 2006.
[ATHENA A6 2005] ATHENA A6, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP, Deliverable D.A6.1, 2005.
[ATHENA A6 2006] ATHENA A6, "D.A6.2: Enhanced Registry/Repository Infrastructure", ATHENA IP, Deliverable D.A6.2, 2006.
[ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006.
[ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.
List of relevant ATHENA deliverables.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 16
16© 2005-2006 The ATHENA Consortium.
References (Papers)
[Benguria, et al. 2006] G. Benguria, X. Larrucea, B. Elvesæter, T. Neple, A. Beardsmore, and M. Friess, ”A Platform Independent Model for Service Oriented Architectures”, to be presented at the 2nd International Conference on Interoperability of Enterprise Software and Applications (I-ESA 2006), Bordeaux, France, 2006.
[Elvesæter, et al. 2005] B. Elvesæter, A. Hahn, A.-J. Berre, and T. Neple, "Towards an Interoperability Framework for Model-Driven Development of Software Systems", in Proc. of the 1st International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA 2005), Geneva, Switzerland, 2005.
[Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134.
[Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B. Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 121-128.
[Fischer, et al. 2006] K. Fischer, B. Elvesæter, A.-J. Berre, C. Hahn, C. Madrigal-Mora, and I. Zinnikus, ”Model-Driven Design of Interoperable Agents”, to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.
[Vayssière, et al. 2006] J. Vayssière, G. Benguria, B. Elvesæter, K. Fischer, and I. Zinnikus, "Rapid Prototyping for Service-Oriented Architectures", to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.
List of relevant papers published from ATHENA.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3
Version 5
© 2005-2006 The ATHENA Consortium. 17
17© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 1
© 2005-2006 The ATHENA Consortium.
6-3b. Atlas Transformation Language (ATL)
Tutorial / Exercise
<Presenter><Company>, <Country><E-mail>
Part 6-3b. Atlas Transformation Language (ATL) Tutorial / Exercise.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 2
2© 2005-2006 The ATHENA Consortium.
Exercise
• Objective– Hands-on experience with ATL– Develop a PIM4SOA information to XSD model transformation
• References– The Atlas Transformation Language Home Page
• http://www.sciences.univ-nantes.fr/lina/atl– ATL in Eclipse
• http://www.eclipse.org/gmt/atl/
• Technical requirements– Eclipse 3.2– EMF 2.2.0– ATL needs:
• antlr-2.7.5• mdr-standalone
ObjectiveHands-on experience with ATLDevelop a PIM4SOA information to XSD model transformation
ReferencesThe Atlas Transformation Language Home Page
http://www.sciences.univ-nantes.fr/lina/atlATL in Eclipse
http://www.eclipse.org/gmt/atl/Technical requirements
Eclipse 3.2EMF 2.2.0ATL needs:
antlr-2.7.5mdr-standalone
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 3
3© 2005-2006 The ATHENA Consortium.
Transformation overview
Ecore
PIM4SOAmeta-model
ATL
PIM4SOA-2-XSD
XSDmeta-model
outputXSDmodelPIM
conforms to conforms to
conforms to
conforms to
conforms to
conforms to
is tranformed into
In the scope of model-driven engineering, model transformation aims to providea mean to specify the way to produce target models from a number of source models. In our example we choose to use a single input model.
PIM4SOA to XSD transformation include mapping the elements of the pim4soa meta-model to some elements of XSD meta-model. When the elements aremapped, artifacts from a model that conforms to the pim4soa metamodel( used as an input) are transformed to artifacts in another model that conforms to the XSD metamodel.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 4
4© 2005-2006 The ATHENA Consortium.
PIM4SOA metamodel
PIM4SOA meta-model describes the concepts needed to model information at theplatform indipendent model. In our transformation we are going to use only a subpart of the elements from this meta-model.
In here we describe the elements that are used in the mapping.
ItemTypes are the basic building block and they represend simple types like string, integer or boolean
An Association represent the association between two entities and is used to describe complex types. Container contained and cardinality are the attributesneccessary to related elements.
A Document represents an object with a specific structure and composed by entities.
An Entity represents a structure element of information
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 5
5© 2005-2006 The ATHENA Consortium.
Simple XSD metamodel
This is a conceptual and simplified XSD metamodel that is used only as an example. The elements of this meta-model that will be used in the mapping arethe XSDSchema, which includes XSDComplexTypes that are refered as complexobjects and XSDSimple types that are basic types. XSDElements and XSDAttributes are included in XSDComplexTypes.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 6
6© 2005-2006 The ATHENA Consortium.
The mapping
mapped to
mapped to
mapped to
mapped to
mapped to
This figure shows the mapping:Document from the PIM4SOA metamodel maps to XSDSchema.Entity from the PIM4SOA metamodel maps to XSDComplexType.Attribute from the PIM4SOA metamodel maps to XSDAttribute.Association from the PIM4SOA metamodel maps to XSDElement.ItemType from the PIM4SOA metamodel maps to XSDSimpleType.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 7
7© 2005-2006 The ATHENA Consortium.
The input model
This is a simple Purchase Order modeled in a PIM4SOA editor. The editor is generated with GMF.
In the model we can find a document order, three entities orderHeader, productInfo and productRecord, respectively with their attributes, threeassociations and two itemtypes. This artifacts will be transformed intoXSDSchema artifacts as described in the mapping.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 8
8© 2005-2006 The ATHENA Consortium.
Create an ATL project
Before creating a new ATL project make sure to be in the ATL prospective.
Create the Atl project and than create two folders into it. The folders could be named for metamodels and models, because PIM4SOA and XSDSchemametamodels will be placed in the metamodels folder, while the input model and the generated one will be placed in the models folder.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 9
9© 2005-2006 The ATHENA Consortium.
Models and metamodels
Create :Metamodel for PIM4SOA and XSDSchema using the ecoreexample diagramthe input Purchase Order model using the PIM4SOA_INFO diagram example from GMF
If already created import the input models and metamodels to the specifiedfolders
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 10
10© 2005-2006 The ATHENA Consortium.
Create an ATL file
In this part we create an Atl file that will contain the neccessary Atl code for transforming the Purchase Order from a PIM4SOA model into a XSDSchemamodel.
The model and metamodel specifications required from the ATL File wizard areonly referances. A path to the actuall file must be given to these references beforethe transformation is run.
The ATL file created include has the specifications that we entered in the wizardas the header. The header section defines the name of the transformation moduleand the name of the variables corresponding to the source and target models.Italso encodes the execution mode of the module.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 11
11© 2005-2006 The ATHENA Consortium.
ATL rules and helpers
• Two kind of rules– Matched rules:
• Declarative transormation• Specify source and target• Specify the way to generate target
– Called rules:• Imperative transformation• Seen as some kind of helpers
• Helpers– Viewed as equivalent to Java methods– Factorized code called from different points in
transformation
In Atl there exist two kind of rules: the matched and called rules. In theseexample we are using only matched rules. Matched rules constitute the core of an ATL transformation since they make it possible to specify for which kind ofsource element targets elements must be generated and the way the generatedtarget elements have to be initialized.. The called rules provide ATL developers with convenient imperativeprogramming facilities. Called rules can be seen as a particular type of helpers: they have to be explicitly called to be executed and they can accept parameters. However, as opposed to helpers, called rules can generate target model elementsas matched rules do. A called rule has to be called from an imperative code section, either from a match rule or another called rule.ATL helpers can be viewed as the ATL equivalent to Java methods. They make it possible to define factorized ATL code that can be called from different points of an ATL transformation.The first rule shown transforms a Document element into a Schema element. In these case the schema takes the document name and the target
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 12
12© 2005-2006 The ATHENA Consortium.
Document2Schema
rule Document2Schema{from doc : PIM4SOA!Document
to sch : XSD!XSDSchema(document <- doc.name,targetNamespace <- 'http://www.w3.org/2001/XMLSchema')}
The first rule shown transforms a Document element into a Schema element. In these case the schema takes the document name and the targetNamespace is set to 'http://www.w3.org/2001/XMLSchema
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 13
13© 2005-2006 The ATHENA Consortium.
Entity2ComplexType
helper context PIM4SOA!Entity def : getAssociations() : PIM4SOA!Entity = PIM4SOA!Association.allInstances() ->select(assoc | assoc.container = self);
rule Entity2ComplexType{from ent : PIM4SOA!Entity
to ct : XSD!XSDComplexType(name <- ent.name,xsd_attribute <- Sequence{ent.attribute},xsd_element <- ent.getAssociations() )
}
The entity to complex type rule states that an entity is transformed into a compextype that will take the name of the entity. Every attribute of the entity is transformed into an xsd_attribute and the associations from this entity to othersare transformed into xsd elements.
In these case we can se the use of an helper context that is called from a rule to retrieve all the association coming from this entity.
The helper context retrieves all instances of an association and returnes those thathave as container the source entity.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 14
14© 2005-2006 The ATHENA Consortium.
Association2Element and Attribute2Attribute
rule Association2Element{from assoc : PIM4SOA!Association
to el : XSD!XSDElement(name <- assoc.name,type <-assoc.contained)}
rule Attribute2Attribute{from att : PIM4SOA!Attribute
to el : XSD!XSDAttribute(name <- att.name,type <- att.type )}
These two rules are quite alike the Document2Schema rule where the attributesof the source model and its attribute are transformed into the target model and itsattributes.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 15
15© 2005-2006 The ATHENA Consortium.
ItemType2SimpeType
rule ItemType2SimpleType{from it : PIM4SOA!ItemType(-- transform only ItemTypes and not Entitiesit.oclIsKindOf(PIM4SOA!Entity)= false )
to st : XSD!XSDSimpleType(name <- it.name)
Since an ItemType is a generalization of an Entity in these rules we needed someconstrains in order to transform only the ItemTypes and not the Entities.
Atl makes use of OCL and provides some operations useful in the constrainingprocess. In this case a oclIsKindOf operation is used and it returns a booleanvalue stating whether it is either an instance of an Entity or of one of itssubtypes.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 16
16© 2005-2006 The ATHENA Consortium.
Run the file
On the run configuration window create a new Atl Transformation(dubble clickin ATL Transformation) and set the project name to be the atl project you areworking on and the Atl file is the Atl file included in this project.
On the model choice specify the source and target models and metamodels. Youneed to set a path for these specifications and remember:IN -> input model(*.pim4soa)PIM4SOA -> source metamodel(PIM4SOA Info.ecore)OUT -> output model(choose your file name)XSDSchema -> target metamodel(XSD metamodel.ecore)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 17
17© 2005-2006 The ATHENA Consortium.
The result
<?xml version="1.0" encoding="ISO-8859-1"?><xmi:XMI xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsd="http:///xsd"><xsd:XSDSchema document="Order" targetNamespace="http://www.w3.org/2001/XMLSchema"/><xsd:XSDSimpleType name="String"/><xsd:XSDSimpleType name="Integer"/><xsd:XSDComplexType name="productRecord">
<xsd_attribute name="supplierProductCode" type="/1"/><xsd_attribute name="buyerProductCode" type="/1"/><xsd_attribute name="quantity" type="/2"/><xsd_attribute name="description" type="/1"/><xsd_attribute name="model" type="/1"/><xsd_attribute name="productPrice" type="/1"/><xsd_attribute name="comments" type="/1"/>
</xsd:XSDComplexType><xsd:XSDComplexType name="orderHeader">
<xsd_attribute name="id" type="/2"/><xsd_attribute name="issuedDate" type="/1"/>
</xsd:XSDComplexType><xsd:XSDComplexType name="productsInfo">
<xsd_element name="productRecords" type="/3"/><xsd_attribute name="productName" type="/1"/><xsd_attribute name="productCode" type="/1"/>
</xsd:XSDComplexType></xmi:XMI>
This is the result of running the model transformation with the input model.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-3b
Version 5
© 2005-2006 The ATHENA Consortium. 18
18© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-1
© 2005-2006 The ATHENA Consortium.
6-4. From PIM4SOA to Agents
<Presenter><Company>, <Country><E-mail>
2© 2005-2006 The ATHENA Consortium.
Original Motivation for BDI Reasoning
• Problem: – Assume that a problem solver (Dudley) faces the problem that a
heroin (Nell) is tied to rails on which a train is approaching.
• Idea to solve the problem: – Dudley knows that if Nell is endangered to be crushed by the
train, he has to save her. When Dudley deduces that he has to act, he looks for a plan that he wants to eventually execute. Let us assume that he successfully derives a plan for rescuing Nell
then he will insert the fact, that the plan will be executed, into his knowledge base.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-2
3© 2005-2006 The ATHENA Consortium.
Problems with Implementation
• Dudley needs a consistency checker for his knowledge base, whichshould delete the plan, if it is no longer useful.
• Unfortunately, when a successful plan is inserted into the knowledge base the consistency checker will immediately deduce that Nell is endangered to get crushed by the train is no longer true.
• This means that the original justification for the plan is no longer valid and thus the plan will be immediately deleted again.
• However, this means that the statement Nell is endangered to getcrushed by the train is no longer in contradiction to the world model of Dudley and will therefore be adopted again as a true statement. Ad infinitum ...
McDermott, 1982
4© 2005-2006 The ATHENA Consortium.
Temporal Modalities
rs
rs
rs
rss
pss
q
q
q
optionally( p)p)
optionally( r)r)
inevitably( q)q)
inevitably( s)s)
Temporal Operators:Temporal Operators:(next), (next), (eventually), (eventually), (always), (always), (until)(until)
inevitable(inevitable( ) ) optional(optional( ))
Additionally: Additionally: BEL(BEL( ), GOAL(), GOAL( ), INTEND(), INTEND( ))
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-3
5© 2005-2006 The ATHENA Consortium.
Worlds as Branching Time Trees
t0 t1
t2
t4
t3
e0
e1
e2
e4
t0 t1
t2
t3
e0
e1
e2
t0 t1
t2
t3
e0
e1
e2
6© 2005-2006 The ATHENA Consortium.
Belief, Goal, and Intention accessible Worlds
p
f
p
f
p
f
p
f
d1
s
d2
p
f
p
f
p
f
d1
d2
p
f
p
f
p
f
d1
d2
Belief Worlds Goal Worlds Intention Worlds
p
f
p
f
d1
p
f
p
f
d1
Legend:p ~ painf ~ tooth filleds ~ go shoppingdi ~ go to dentist i
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-4
7© 2005-2006 The ATHENA Consortium.
BDI Theories Formally Specify Agent Behaviour
• Rao&Georgeff specified a theory of basic axioms that allows agents to reason about beliefs, goals, and intentions without forcing the agent to adopt all consequences of goals and intentions as goals and intentions as well.
• Based on this theory they specified commitment strategies for BDI agents, they distinguish:– Fanatic Agents: Stick with a goal until it is finally achieved– Single-Minded Agents: Drop a goal when there locally is no longer an
option to achieve the goal– Open-Minded Agents: Drop a goal when the original reason to adopt the
goal is no longer valid
8© 2005-2006 The ATHENA Consortium.
High-Level BDI Concepts
• Team: Specifies the structure of one or more entities (Teams/Agents) that is formed to achieve a set of desired objectives.
• Role: Specifies a role as a type by a listing the types of the events the role can deal with.
• Named Role: An instance of a specific role type. This concepts allows multiple roles with the same type in teams and team plans.
• Events: The type of stimuli a team, role, or team plan reacts to or posts.
• Team Plan: Specifies the behaviour of a team in reaction to a specific event.
• Named Data: Allows the team to store information/beliefs.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-5
9© 2005-2006 The ATHENA Consortium.
Structure of Plans
• Triggering Condition: Specification of the event the plan reacts to.
• Relevance Condition: Additional constraints on the triggering event.
• Context Condition: Constraints on the state of affairs the plan is designed for to deal with. Usually these constraints access the agents beliefs.
• Body of a Plan: Actions that should be taken when the plan becomes active. Can include pure Java code but allows the use of special concepts to drive BDI reasoning.
• Team plans additionally allow the usage of roles.
10© 2005-2006 The ATHENA Consortium.
Late Binding of Service Requests
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-6
11© 2005-2006 The ATHENA Consortium.
Model Driven Design of BDI Agents
12© 2005-2006 The ATHENA Consortium.
FIPA’s Conctract Net (CNP) Specification
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-7
13© 2005-2006 The ATHENA Consortium.
Design Views for the CNP(Roles, Teams, and Events)
14© 2005-2006 The ATHENA Consortium.
Design Views for the CNP(Teams, Plans, and Events)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-8
15© 2005-2006 The ATHENA Consortium.
PIM4SOAMetamodel
Web ServicesMetamodel
Agent Metamodel(AgentMM)
P2PMetamodel
GridMetamodel
PIM
PSM
s
Symbols
Metamodel
Concept
RelationshipCorrespondence
Mapping from PIM to PSMs
16© 2005-2006 The ATHENA Consortium.
Metamodel for information
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-9
17© 2005-2006 The ATHENA Consortium.
Metamodel for (Automated Software) Processes
18© 2005-2006 The ATHENA Consortium.
Metamodel for (software) services
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-10
19© 2005-2006 The ATHENA Consortium.
Partial view of an BDI agent metamodel
20© 2005-2006 The ATHENA Consortium.
Comparison of the Metamodels forPIM4SOA and AgentMM
Role
Team Plan
TeamService Provider
Collaboration
Role
Collaboration Use
PIM4SOA AgentMM
Behaviour
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-11
21© 2005-2006 The ATHENA Consortium.
ATL Transformation Rule
rule ServiceProvider2Team {from
serviceProvider : SOA!ServiceProviderto
team : AgentMM!Team (name <- serviceProvider.name,Roles_Performed <- rolePerforms,Plans <- plans,Roles_Required <- rolesRequired
),rolePerforms : AgentMM!Roles_Performed (
performs_role <- serviceProvider.roles-> collect(d|thisModule.resolveTemp(d,'roleAgent')).debug('ssssss')
),…}
22© 2005-2006 The ATHENA Consortium.
Model transformation Pim4Soa to Jack
Pim4SoaMM
Jack MM
JackPSMM2
JackPSMM3
Jack
Pim4SoaM1
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-12
23© 2005-2006 The ATHENA Consortium.
Agent-based Service Mediation and Composition
PIM4SOAModels
Descriptionof
existingservices(WSDL)
Transformation ofPIM4SOA modelsto Jack models
Transformation ofservice descriptionsto Jack models
24© 2005-2006 The ATHENA Consortium.
WS Service Composition Framework
BDIPlan/WorkflowLibrary
JACKAgentFrame-work
JACKAgentFrame-work
specify use
OntologyOntology
Services
Service Composition
Planner
MediationSupport
Tool
Run Time
ExecutionPlan
Services
KnowledgeBase
ParameterMapping
Parameter Mediation
Annotation
use
Design Time
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-13
25© 2005-2006 The ATHENA Consortium.
Parameter Mapping
R1 f1 f2 .. fn
ConceptCi
WSDLInputMessage
WSDLOutputMessage
(Domain)Ontology
AgentOntology
Translation
Parameter1 Parameter2 Parameterl
Rk f1 f2..fm
ConceptDjBelief Set
Service Grounding
…
26© 2005-2006 The ATHENA Consortium.
Conclusion
• Agent technologies:– offer support for complex applications– have a solid theoretical background– use concepts that nicely match with modelling
concepts in BPM and enterprise modelling– Offer a powerful execution environment
• Future expectations:– automated transformation of models– seamless integration with service-oriented
architectures
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-4
Version 5
© 2005-2006 The ATHENA Consortium. 4-14
27© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-1
© 2005-2006 The ATHENA Consortium.
6-5. From PIM4SOA to Peer-2-Peer (P2P)
<Presenter><Company>, <Country><E-mail>
2© 2005-2006 The ATHENA Consortium.
Outline
• Distributed Resource Management and Coordination
• References
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-2
3© 2005-2006 The ATHENA Consortium.
Distributed Resource Management and Coordination
4© 2005-2006 The ATHENA Consortium.
Org. Z
Org. B Org. Y
Adaptive architectures (P2P)
• Peer-to-Peer business resource management for virtualization and decentral management of business objects, services, and processes
• Self-healing, -configuring, -optimizing, -protecting properties for distributed enterprise networks• Intelligent agents: pro-active event-driven communication & situated semantic reasoning nodes support
interoperability in decentrally managed, distributed enterprise networks
Support enterprise and business process evolution
Org. A
ResourceP Peer/Agent
PPP
P P
register, retrieve, search,,subscribe
Public Registry/Repository
Infrastructure
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-3
5© 2005-2006 The ATHENA Consortium.
P2P Business Resource Management Framework
• Handling of Structured Business Documents• Security and Access Control• Integration with Business and Backend Storage Systems• Integration with WSDL / SOAP based Web Services • Support for robust execution of BPEL base business processes
BusinessApplication
WebService
ProcessExecution Engine
Resource Management Framework (RMF)
BR
MF Business Object Management Layer Business Actor
Management Layer
WS Discovery(P2P Registrar)
SOAP/HTTPTunneling
Robust Process
Execution
6© 2005-2006 The ATHENA Consortium.
Business Actor Management Layer
End User / Developer
Web ServiceRegistrar
(core)
API
End UserApplication
API
End UserApplication
API
End UserApplication
Robust ProcessExecution Support
(core)HTTP & SOAP
Tunnel
(core)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-4
7© 2005-2006 The ATHENA Consortium.
P2P system model (RMF)
Peer
PeerGroup
Application -represented by
1
1
*
-contains1
ResourceMetadata
-register, deregister
*
*
* *
-query : Query-credentials : RoleSet
RequestContext*-search, lookup, subscribe, retrieve
*-result, notify
-search, lookup, subscribe
*
-return, notify
*
P2P Resource
11
Business Resource
*
-contains 1Reference
*
-contains
1
1 -references
1
DHT PeerNo-Index Peer
8© 2005-2006 The ATHENA Consortium.
P2P domain model (BRMF)
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-5
9© 2005-2006 The ATHENA Consortium.
Business Resource ManagementFramework (BRMF)
10© 2005-2006 The ATHENA Consortium.
Object Binding Components (BOML)
BusinessObject
SchemaBusiness
Object
RMFResource
ResourceBindingProfile
Representation in the P2P-infrastructure
e.g. documentIn a
documentmanagement
system
XML schemaXML binding description
Set of basic functionality (publish, search via generic properties)
Derived from concrete binding specification, may use predefined
profiles for specialized queries(e.g. for WSDL, ebXML)
dynamically plugged backendaccessor component
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-6
11© 2005-2006 The ATHENA Consortium.
Schema + Binding description<xs:schema …><xs:element name="RFQ" type="RFQ_Type">
…</xs:element><xs:complexType name="RFQ_Type">
<xs:sequence><xs:element name="PartID" type="xs:int"/><xs:element name="PartName" type="xs:string"/><xs:element name="Quantity" type="xs:string"/><xs:element name="TechnicalSpec" minOccurs="0"><xs:complexType …>
…</xs:element><xs:element name="Originator" type="Contact_Type" minOccurs="0"/>
</xs:sequence></xs:complexType><xs:complexType name="Contact_Type">
<xs:sequence><xs:element name="ContactName" type="xs:string" minOccurs="0"/><xs:element name="ContactAddress" …/>
</xs:sequence></xs:complexType></xs:schema>
<?xml version="1.0" encoding="UTF-8"?><cbf:binding xmlns:cbf="http://www.castor.org/SourceGenerator/Binding"defaultBindingType='element'>
<cbf:elementBinding name="RFQ"><cbf:rmfBinding inlineWrapper="false" copyRootAccessors="true">
<cbf:keyWords><locationPath>/RFQ/PartName</locationPath>
</cbf:keyWords></cbf:rmfBinding>
</cbf:elementBinding>
</cbf:binding>
Java-Binding-Package
RFQ_RMFResource
12© 2005-2006 The ATHENA Consortium.
Handling business documents from a programmer’s point of view
RFQ_RMFResource rfq =new RFQ_RMFResource();
rfq.setPartName(„Airbag");rfq.setPartID(1003452);rfq.setQuantity("100000");
rfq.requireCredentials(…);
rfq.publish();
// join P2P, set credentials
Enumeration<RFQ_RMFResource>rfqs = RFQ_RMFResource
.search_PartName(„Airbag“);
// select one rfq …rfq.trackRemoteUpdates(this);
rfq.setMaxCost(450);rfq.commitChanges();
natural access to the document content
restrict accessibility
publish the resource
Peer A Peer B
stay informed about the remote state
identify and retrieve objects based on special properties
propagate own changes
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-7
13© 2005-2006 The ATHENA Consortium.
Realization of the CPD application
OEM
PU
T1-Supplier
T2-Suppliers
RfQ
references
Document Management
System
provideaccess
Mapping of EPC seems naturalTo a P2P system supportingPropagation of content based event
change of RfQ statecauses event at T1-Supplier
Then what is our relationship to theDifferent modelling layers/levels?
14© 2005-2006 The ATHENA Consortium.
Components for backend access
locatable & loadable on demand
components managedwithin the system itself
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-8
15© 2005-2006 The ATHENA Consortium.
Layers, models & relationships (1/2)
WS
SOA
EM
CBP
Pla
tform
PS
MP
IMC
IM
WS
SOA
EM
CBP
RMF
P2P
„cross“-mappings exist
WS
SOA
EM
CBP
RMF
P2P
adaptive technologies may be used for WS
16© 2005-2006 The ATHENA Consortium.
Layers, models & relationships (2/2)
WS
SOA
EM
CBP
Pla
tform
PS
MP
IMC
IM
WS
SOA
EM
CBP
RMF
P2P
WS
SOA
EM
CBP
RMF
P2P
in order to use them, theyshould be reflected in themodeling layer(s) above
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-9
17© 2005-2006 The ATHENA Consortium.
References
18© 2005-2006 The ATHENA Consortium.
References
• ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006.
• ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.
Model-Driven Development of Interoperable Web Services, Agents and P2P Solutions - Part 6-5
Version 5
© 2005-2006 The ATHENA Consortium. 5-10
19© 2005-2006 The ATHENA Consortium.
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.