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

Model-driven development of SOA
with Web services – using QVT
technology
Master thesis
by
Berge Stillingen
Department of Informatics, University of Oslo
2005
1
Problem domain and scope

SOA
–
Service Oriented Architecture


MDA
–
Model Driven Architecture


Query/Views/Transformations

MOF Model to Text Transformations

Upcoming standard for model-to-text
transformations from OMG
Thesis approach:
–
–
2
Upcoming standard for model-to-model
transformations from OMG
MOF2Text
–

Framework for model-driven development
QVT
–

Focus is set on Web services
Where is QVT today?
Is QVT the right answer when developing SOA
using MDD?
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
3
(I) Feature analysis

Evaluating proposals to the QVT and MOF2Text standards and
belonging software (proof of concept)
–
–
–
–
QVT
MOF2Text
Alt. 1:
QVT-Merge Group
ATL
SINTEF/Softeam
MOFScript
Alt. 2:
EXMOF
OptimalJ
MOF2Text-partners
OptimalJ (TPL)
–
4
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:
Sum up and use the “winning” alternative to specify
transformations for a SOA-MDD framework and case study
Requirements/Evaluation criteria
Model-to-model trans. (QVT)

Declarative transformation definitions/Model querying
–


Incremental transformations
Reuse of existing OMG specifications
–




5
OCL, UML, MOF (Meta Object Facility)
MOF 2.0 based transformations/models
Additional transformation data
Traceability
–

Based on OCL
Importing for debugging
Graphical and textual notation
…
Requirements/Evaluation criteria
Model-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
–
–


6
Most mappings are one-to-one (isomorphic)
More non-trivial mappings may occurs
Multiple models and support for UML extensibility
mechanism
…
Requirements/Evaluation criteria
Other requirements. (tool-specific)
Note: Applies to the proofs-of-concept in both alternatives and both QVT and MOF2Text.

OMG standards
–




7
UML 2.0 and XMI 2.0 support
Explicit UML profile support using multiple files
Code assistance
Debugging facilities
Testing well-formedness
Feature analysis results

Alternative 1 wins with a 63% score (alt.2 gets a 55% score)
–

Results worst for the tool-specific req. (other req.)
–
8
Low scores, especially on model-to-model transformations
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)
(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:
–
–
–
–
9
QVT Merge relations (graphical)
QVT Merge mappings (textual)
ATL transformations
COMET’s Service Architecture modeling
MOSUQ concepts

Service Architecture Model
PIM (MOF)
Draw a COMET based Service
Architecture Model
–

Models targeted at the Java Web services platform
PSM (MOF)

XML/Code (Text)
Java code
WSDL
documents

Config. documents
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
–
–
10
Use COMET stereotypes
Add transformations between the
abstraction layers
Use 3 or more abstraction layers
MDD Java Web services

Service
Architecture
model
–
PIM (MOF)
Trans
1
4 sub-platforms identified
Trans
2
–
UML Model for
Java Web
Services
WSDL Model
–
PSM (MOF)
–
refined
–
Trans
3
Trans
4
XML/Code (Text)
Java code
11
WSDL
documents


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
Metamodels for the PSMs (1)


12
UML 2.0 MM
With Java Web
services UML
profile
Metamodels for the PSMs (2)

13
WSDL metamodel
MDD Java Web services
BSPack2Def(bsp: Package, def:Definitions)

Transformation assets:
QVT Merge relations
realizing
– QVT Merge mappings
– ATL code
implementing
– MOFScript code
bind:Binding
–
14
binding
def:Definitions
bsp:Package
service
portType
svc:Service
pt:PortType
svci:Interface
message
inputMsgs:Message
message
outputMsgs:Message
{ when }
bsp.stereoTypeKindOf(’BusinessServiceSpec’) and Interface2WSDL(svci, pt, bind, svc, inputMsgs, outputMsgs)
Implementing transformations Working environment
Eclipse based IDE: Rational Software
Modeler + ATL transformation engine
+ MOFScript
ATL code
Service Model
Source
metamodel
(EMF)
Target
metamodel
(EMF)
XMI
XMI
ATL engine
MOFScript engine
Code/
text
artefacts
15
Source
metamodel
(EMF)
MOFScript code
Platform model
(UML profile or MOF metamodel based)
XMI
Case study: Min/Max Replenishment
- applying the MOSUQ framework
16
Case study: Min/Max Replenishment
- Service Architecture Model (COMET)




17
Component model
Interface Model
Information Model
PIM Data types
Case study: Min/Max Replenishment
- Platform models (1)

WS UML model
–
18
Trans 1. applied
Case study: Min/Max Replenishment
- Platform models (2)

WSDL model
–
–
19
Shown as object diagram
Trans. 2 applied
Case study: Min/Max Replenishment
- Code artefacts

Java Code
–
Transformation 3 applied





WSDL (XML)
–
Transformation 4 applied


20
Value object classes
Web service interface classes
Web service implementation classes
Validated with Eclipse’s Java compiler
Example with Rpc/literal messaging style
Validated with a WDSL XML Schema
instance
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)
–




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
–
21
w/Additional transformation data
Formalizing the details of identified platforms by using MM
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
–
–
–
–
Has proven that the QVT and MOF2Text standards can be
combined to realize MDD of SOA

22
ATL code (difficult and time-consuming)
MOFScript code
QVT Merge specifications
An alternative to MDD of SOA
Future work

Alternative QVT-tools:
–
AMW/AMMA (INRIA)



–
Model Transformation Framework (MTF)


Consistency-checking capabilities
MOSUQ enhancements
–
Apply other PSM profiles for SOA impl.:





23
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)
BPEL/BPMN
Configuration files (DD etc)
CORBA/IDL
XML registries and UDDI
dot NET platform