1

Model-driven development of SOA with Web services – using QVT technology

Master thesis

by

Berge Stillingen

Department of Informatics, University of Oslo

2005

2

Problem domain and scope

SOA– Service Oriented Architecture

Focus is set on Web services MDA

– Model Driven Architecture Framework for model-driven development

QVT– Query/Views/Transformations

Upcoming standard for model-to-model transformations from OMG

MOF2Text– MOF Model to Text Transformations

Upcoming standard for model-to-text transformations from OMG

Thesis approach: – Where is QVT today?– Is QVT the right answer when developing SOA

using MDD?

3

Contents

I: Feature analysis: QVT/MOF2Text candidates

II: MOSUQ: SOA/QVT/MOF2Text framework

– Concepts– Transformation assets for Java Web services

III: Case study: Min/Max replenishment system specified using the

framework

4

(I) Feature analysis

Evaluating proposals to the QVT and MOF2Text standards and belonging software (proof of concept)

– Analyze their features deriving criteria/requirements from the QVT and MOF2Text RFPs (Request For Proposals to standards)

– Add additional tool-specific requirements for the proofs of concept– Give points for each criteria (e.g. 2/5)– The 2 alternatives:

QVT MOF2Text

Alt. 1: QVT-Merge Group

ATL

SINTEF/Softeam

MOFScript

Alt. 2: EXMOF

OptimalJ

MOF2Text-partners

OptimalJ (TPL)

– Sum up and use the “winning” alternative to specify transformations for a SOA-MDD framework and case study

5

Requirements/Evaluation criteriaModel-to-model trans. (QVT)

Declarative transformation definitions/Model querying– Based on OCL

Incremental transformations Reuse of existing OMG specifications

– OCL, UML, MOF (Meta Object Facility) MOF 2.0 based transformations/models Additional transformation data Traceability

– Importing for debugging Graphical and textual notation …

6

Requirements/Evaluation criteriaModel-to-text trans. (MOF2Text)

Reuse of existing OMG language specifications MOF 2.0 based mappings/source models Functions for string manipulation Combining model data with clear text Complex text transformation mappings

– Most mappings are one-to-one (isomorphic)– More non-trivial mappings may occurs

Multiple models and support for UML extensibility mechanism

…

7

Requirements/Evaluation criteriaOther requirements. (tool-specific)

Note: Applies to the proofs-of-concept in both alternatives and both QVT and MOF2Text.

OMG standards– UML 2.0 and XMI 2.0 support

Explicit UML profile support using multiple files Code assistance Debugging facilities Testing well-formedness

8

Feature analysis results

Alternative 1 wins with a 63% score (alt.2 gets a 55% score)– Low scores, especially on model-to-model transformations

Results worst for the tool-specific req. (other req.)– OptimalJ: Gives Alt 2. a better score. A more “easy to use” tool than

ATL/MOFScript

QVT MOF2Text

Alt. 1: QVT-Merge Group

ATL

SINTEF/Softeam

MOFScript

Alt. 2: EXMOF

OptimalJ

MOF2Text-partners

OptimalJ (TPL)

9

(II) MOSUQ – SOA QVT Framework

Model-driven development Of Service Oriented Architectures Using QVT

– Implies use of the MOF2Text standard as well Combined QVT and MOF2Text usage

– Serve conceptual guidelines for MDD of SOA using the two standards

Specified concretely for Java Web services Transformations assets:

– QVT Merge relations (graphical)– QVT Merge mappings (textual)– ATL transformations

– COMET’s Service Architecture modeling

10

MOSUQ concepts

Draw a COMET based Service Architecture Model

– Use COMET stereotypes Define a PSM domain for a SOA

based platform (main platform) Define wanted artifacts at the code

level Identify “sub-platforms” for the PSM

domain– Defined by UML profiles or MOF

metamodels Refine the PSM domain

– Add transformations between the abstraction layers

– Use 3 or more abstraction layers

XML/Code (Text)

PSM (MOF)Models targeted at the Java Web services platform

Java codeWSDL

documentsConfig. documents

PIM (MOF)Service Architecture Model

11

MDD Java Web services

Trans 3

Trans 4

WSDL Model

XML/Code (Text)

UML Model for Java Web Services

Java codeWSDL

documents

Service Architecture

model

Trans 1

Trans 2

PIM (MOF)

PSM (MOF)

4 sub-platforms identified– WSDL (using MOF

metamodel)– JAX-RPC – Java– Sun/J2EE– Details of the three latter

reflected in a UML profile PSM domain refined 4 transformations added

refined

12

Metamodels for the PSMs (1)

UML 2.0 MM With Java Web

services UML profile

13

Metamodels for the PSMs (2)

WSDL metamodel

14

implementing

realizing

MDD Java Web services

Transformation assets:– QVT Merge relations– QVT Merge mappings– ATL code– MOFScript code

def:Definitions

BSPack2Def(bsp: Package, def:Definitions)

bsp.stereoTypeKindOf(’BusinessServiceSpec’) and Interface2WSDL(svci, pt, bind, svc, inputMsgs, outputMsgs)

bsp:Package

service

{ when }

svci:Interface

portType

binding

inputMsgs:MessageoutputMsgs:Message

message message

svc:Service

bind:Binding

pt:PortType

15

Implementing transformations -Working environment

Eclipse based IDE: Rational Software Modeler + ATL transformation engine + MOFScript

XMI

Source metamodel

(EMF)

Target metamodel

(EMF)

ATL engineService Model Platform model(UML profile or MOF metamodel based)

XMI

Source metamodel

(EMF)

ATL code

MOFScript code

Code/textartefacts

Code/textartefacts

MOFScript engineXMI

16

Case study: Min/Max Replenishment - applying the MOSUQ framework

17

Case study: Min/Max Replenishment- Service Architecture Model (COMET)

Component model Interface Model Information Model PIM Data types

18

Case study: Min/Max Replenishment- Platform models (1)

WS UML model– Trans 1. applied

19

Case study: Min/Max Replenishment- Platform models (2)

WSDL model– Shown as object diagram– Trans. 2 applied

20

Case study: Min/Max Replenishment- Code artefacts

Java Code– Transformation 3 applied

Value object classes Web service interface classes Web service implementation classes Validated with Eclipse’s Java compiler

WSDL (XML)– Transformation 4 applied

Example with Rpc/literal messaging style Validated with a WDSL XML Schema

instance

21

Why use MOSUQ?- especially concerning the generation of Java code and WSDL documents

No PSM (traditional) approach:– PIM to text transformation (code generation)

Annotation of PIMs (stereotypes, tagged values)– w/Additional transformation data

No intermediate PSMs One transformation per target artefact at the implementation level (code etc.) Only one language to use

MOSUQ (more MDA adherent):– PIM to PSM transformations– PSM to text and/or PSM to PSM transformations

Commit to multiple ways (languages) of specifying transformation assets Ensures correcting structuring of target specifications reflecting code/text at the

implementation level– Given a well-defined metamodel. – Less chance of generating text artefacts violating syntax

Separation of concerns– Formalizing the details of identified platforms by using MM

22

Conclusions- summary of contributions

Evaluation of proposals to QVT and MOF2Text with their belonging proofs-of-concept

– Feature analysis: 63% score on alt. 1 (QVT Merge/ATL/MOFScript)

Still work to be done, especially on the tool side MOSUQ – SOA/QVT framework

– Transformations assets Subject to reuse/alterations

– ATL code (difficult and time-consuming)– MOFScript code– QVT Merge specifications

– Has proven that the QVT and MOF2Text standards can be combined to realize MDD of SOA

An alternative to MDD of SOA

23

Future work

Alternative QVT-tools:– AMW/AMMA (INRIA)

Lets you define correspondence specifications in the form of weaving models between model artefacts

Capable of expressing symmetric rules Transformations in different languages can be generated (XSLT, ATL)

– Model Transformation Framework (MTF) Consistency-checking capabilities

MOSUQ enhancements– Apply other PSM profiles for SOA impl.:

BPEL/BPMN Configuration files (DD etc) CORBA/IDL XML registries and UDDI dot NET platform