Date post: | 18-Dec-2015 |
Category: |
Documents |
View: | 213 times |
Download: | 0 times |
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
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
17
Case study: Min/Max Replenishment- Service Architecture Model (COMET)
Component model Interface Model Information Model PIM Data types
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