ap6 â€“ model-driven development of interoperable web services

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.


Version 5


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.


Version 5



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.


Version 5



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


Version 5



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.


Version 5



6-1. Model Mappings and

Transformations

<Presenter><Company>, <Country><E-mail>

Part 6-1. Model mappings and transformations.


Version 5



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.


Version 5



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


Version 5



Foundations of model mappings and transformations

Foundations of model mappings and transformations.


Version 5



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)


Version 5



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


Version 5



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


Version 5



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


Version 5



Mapping and transformation

SourceMetamodel

Input Model

OutputModel

TargetMetamodel

Mapping

Transformation

<<InstanceOf>> <<InstanceOf>>

based on

This figure illustrates the mapping as we have already explained.


Version 5



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.


Version 5



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


Version 5



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


Version 5



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)


Version 5



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/


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



QVT overview

Core

Relations

BlackBox

OperationalMappings

RelationsToCoreTransformation

The figure gives an overview of QVT.


Version 5



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)


Version 5



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


Version 5



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.


Version 5



Model transformation technologies and examples

Model transformation technologies and examples.


Version 5



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


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



References

References.


Version 5



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.


Version 5






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


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


Version 5



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/


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


Version 5



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.


ATL: Installation


Version 5



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


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


Version 5



ATL: Book2Publish example


Reminder on transformation


Version 5



Goal

• Transform instances Book into instances of Publication

Sum of chapters' number of pages

List of authors'names

separated by and


ATL transformation code

• Header• Helper• Rule


Version 5



Book2Publication.atl

• Header

module Book2Publication;create OUT : Publication from IN : Book;


• 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


Version 5



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


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)


Version 5



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


Rules

rule Book2Publication {from

b : Book!Book (b.getNbPages() > 2

)to

out : Publication!Publication (title <- b.title,authors <- b.getAuthors(),nbPages <- b.getNbPages())

}


Version 5



ATL: RSM


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


Version 5



1. Create an ATL project


2a. Create the Book metamodel


Version 5



2b. Create the Book metamodel


2c. Create the Book metamodel


Version 5



3a. Export the Book metamodel as .ecore


3b. Export the Book metamodel as .ecore


Version 5



3c. Export the Book metamodel as .ecore


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>


Version 5



3d. Import the Book metamodel as .ecore

NB! Choose "File system"If you choose "Ecore Model",RSM proposes to replaceyour ".emx' model !!!!!!


3e. Import the Book metamodel as .ecore


Version 5



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


6a. Create an ATL file


Version 5



6b. Set IN metamodel


6c. Set OUT metamodel


Version 5



7. Write the ATL transformation


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>


Version 5



9a. Configure the ATL transformation


9b. Configure the ATL transformation

Change the name

Fill


Version 5



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)


10. Run the ATL transformation


Version 5



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>


To summarize

rule Book2Publication {from

b : Book!Book (b.getNbPages() > 2

)to

out : Publication!Publication (title <- b.title,authors <- b.getAuthors(),nbPages <- b.getNbPages())

}


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>


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


Version 5



References


References

• INRIA, "ATL - The Atlas Transformation Language Home Page". http://www.sciences.univ-nantes.fr/lina/atl/


Version 5





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


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


Version 5



Background


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.


Version 5



Consortium

• Submitters: (supporter)

• Also supported by the following MODELWARE partners:


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


Version 5



Introducing the MOFScriptlanguage


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


Version 5



MOFScript in action

Documentation

UML

MOFScript

Program code

XMLRDBMS

BPMN

MOF MODELSMOF MODELS Lexical outputLexical output


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)


Version 5



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.


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}


Version 5



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}


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+

*


Version 5



Variables and constants

VariableDeclaration(from QVT::QVTBase)VariableInitExp

(from QVT::QVTMappingOperations)


TextTransformation

Property(from MOF 2.0::EMOF)localProperty+

*

(from QVT::Queries::Module)

localVariables+

*/(from QVT::MappingRules)

VariableOwner

TextMappingRule

0..1 referredVariable+


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


OutputExpression

+outputCommand:String={'print', 'println'}0..1

outputBody+

outputContext+

0..1OutputDeviceExpression

+refName:String[0..1]+properties:Property[*]

StdOutDeviceExpression


Version 5



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)


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


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


Version 5



Details of the MOFScript language


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


Version 5



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}

}


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

}}


Version 5



MOFScript extends QVT mappings

Relations Mappings Graphical

QVTMerge

MOFScript •• imperativeimperative•• proceduralprocedural•• sideside--effectseffects•• uniuni--directionaldirectional•• objectobject--orientedoriented•• OCLOCL--basedbased•• lexicallexical


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


Version 5



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 { … }

}


Example1: From UML classdiagram to Java


Version 5



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

}


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

}%>

}


Version 5



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

}


MOFScript advanced features


Version 5



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


Traceability model


Version 5



The MOFScript tool


What is MOFScript?

• An Eclipse plug-in (feature)• Developed at SINTEF ICT


Version 5



MOFScript architecture


MOFScript a model to text tool

• Provides the means of:– Editing, compiling

and executing the transformations

• Syntax high-lightning• Content assist


Version 5



GUI overview


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


Version 5



References


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


Version 5






Version 5



6-2. Model-Driven Development with

PIM4SOA


Part 6-2. Model-driven development with PIM4SOA.


Version 5



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


Version 5



PIM4SOA

PIM4SOA.


Version 5



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.


Version 5



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?


Version 5



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?


Version 5



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


Version 5



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


Version 5



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


Version 5



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


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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


Version 5



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.


Version 5



Rapid prototyping with PIM4SOA

Rapid prototyping with PIM4SOA.


Version 5



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.


Version 5


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.


Version 5


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


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


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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



Case study: AIDIMA e-procurement scenario

Case study: AIDIMA e-procurement scenario.


Version 5



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


Version 5


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.


Version 5



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, …).


Version 5



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.


Version 5



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


Version 5



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)


Version 5



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)


Version 5



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


Version 5



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.


Version 5



PIM4SOA: Order process

This is a model of the order process using the UML profile for PIM4SOA.


Version 5



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.


Version 5



PIM4SOA: Delivery and invoicing collaborations

This is a model of two collaboration for delivery and invoicing that are part of the scenario.


Version 5



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.


Version 5



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.


Version 5



PIM4SOA: Goods supply collaboration

This is a model of the goods supply collaboration.


Version 5



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.


Version 5



Model of anorder document

PIM4SOA: Order document

This is a model of the the order document.


Version 5



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.


Version 5



References

References.


Version 5



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.


Version 5



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.


Version 5







Version 5



6-3. From PIM4SOA toWeb Services


Part 6-3. From PIM4SOA to Web services.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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


Version 5



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.


Version 5



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


Version 5



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.


Version 5



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


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



References

References.


Version 5



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.


Version 5



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.


Version 5







Version 5



6-3b. Atlas Transformation Language (ATL)

Tutorial / Exercise


Part 6-3b. Atlas Transformation Language (ATL) Tutorial / Exercise.


Version 5



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


Version 5



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.


Version 5



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


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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


Version 5



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.


Version 5



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


Version 5



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


Version 5



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.


Version 5



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.


Version 5



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.


Version 5



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)


Version 5



The result


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.


Version 5







Version 5

© 2005-2006 The ATHENA Consortium. 4-1


6-4. From PIM4SOA to Agents



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.


Version 5



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


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


Version 5



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


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


Version 5



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


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.


Version 5



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.


Late Binding of Service Requests


Version 5



Model Driven Design of BDI Agents


FIPA’s Conctract Net (CNP) Specification


Version 5



Design Views for the CNP(Roles, Teams, and Events)


Design Views for the CNP(Teams, Plans, and Events)


Version 5



PIM4SOAMetamodel

Web ServicesMetamodel

Agent Metamodel(AgentMM)

P2PMetamodel

GridMetamodel

PIM

PSM

s

Symbols

Metamodel

Concept

RelationshipCorrespondence

Mapping from PIM to PSMs


Metamodel for information


Version 5



Metamodel for (Automated Software) Processes


Metamodel for (software) services


Version 5



Partial view of an BDI agent metamodel


Comparison of the Metamodels forPIM4SOA and AgentMM

Role

Team Plan

TeamService Provider

Collaboration

Role

Collaboration Use

PIM4SOA AgentMM

Behaviour


Version 5



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

),…}


Model transformation Pim4Soa to Jack

Pim4SoaMM

Jack MM

JackPSMM2

JackPSMM3

Jack

Pim4SoaM1


Version 5



Agent-based Service Mediation and Composition

PIM4SOAModels

Descriptionof

existingservices(WSDL)

Transformation ofPIM4SOA modelsto Jack models

Transformation ofservice descriptionsto Jack models


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


Version 5



Parameter Mapping

R1 f1 f2 .. fn

ConceptCi

WSDLInputMessage

WSDLOutputMessage

(Domain)Ontology

AgentOntology

Translation

Parameter1 Parameter2 Parameterl

Rk f1 f2..fm

ConceptDjBelief Set

Service Grounding

…


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


Version 5






Version 5



6-5. From PIM4SOA to Peer-2-Peer (P2P)



Outline

• Distributed Resource Management and Coordination

• References


Version 5



Distributed Resource Management and Coordination


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


Version 5



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


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)


Version 5



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


P2P domain model (BRMF)


Version 5



Business Resource ManagementFramework (BRMF)


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


Version 5



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


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


Version 5



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?


Components for backend access

locatable & loadable on demand

components managedwithin the system itself


Version 5



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


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


Version 5



References


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.


Version 5



