Transcript Document

Model Driven Architecture based
XML Processing
Ivan Kurtev, Klaas van den Berg
University of Twente, the Netherlands
DocEng’03 , Grenoble, November 2003
Sheet 1
Outline







Technologies for XML Processing;
Problem Statement;
Model Driven Architecture (MDA) Concepts;
MDA based XML Processing;
Example;
Transformation Language;
Conclusions;
DocEng’03 , Grenoble, November 2003
Sheet 2
Context
Applications written in an OO language
 Main goal: transform a document into a set of application objects;
Domain
Implements concepts
Application
Classes
Encodes data from
Instances
XML
Document
Transformation
Application
Objects
The Transformation is a recurring task and requires automation
DocEng’03 , Grenoble, November 2003
Sheet 3
Technologies for XML Processing
 Generic interfaces to XML documents (e.g. DOM)
XML
Document
DOM
Parser
Processing
Code
DOM Tree
Application Objects
Tree traversing, class instantiation, type conversions are performed by processing code.
 Data Binding
Compilation
Schema

Application
Classes
Instance of
XML
Document
Instance of
Unmarshalling

Compilation and Unmarshalling are
automated;
Not applicable in case of dissimilarities
between the schema and the
application structure;
Objects
DocEng’03 , Grenoble, November 2003
Sheet 4
Problem Statement
 XML Processing:
 Definition and execution of transformations between XML
documents and application objects;
 Requirements:
 Transformations should be automated;
 Transformations should produce the desired application
objects;
 Current technologies are either low-level or do not
always produce the desired application objects;
 More powerful transformation techniques are required!
 Solution:
 Application of Model Driven Architecture (MDA) model
transformation techniques;
DocEng’03 , Grenoble, November 2003
Sheet 5
Basic MDA Concepts
 Separation of system specification from system implementation;
 Models:
Platform
Independent
Model (PIM)
Platform
Specific
Model (PSM)
 Model Transformations
– The MDA Pattern (from “MDA Guide”):
Transformation
Specification
Source Model
DocEng’03 , Grenoble, November 2003
Transformer
Target Model
Sheet 6
Meta Modeling and XML (1)
 In the MDA models can be defined in the Meta Object Facility (MOF)
based on four meta layers;
 Similar meta layer organization is observed in the XML technology;
XML
MOF
Example:
Level M3
Meta Schema
The MOF
MMM
(Schema for
schemas)
Level M2
The Java MM
The UML MM
An XML
Schema
Level M1
A UML Model
m1
A UML Model
m2
An XML
Document
Level M0
A particular
use of m1
DocEng’03 , Grenoble, November 2003
Another use
of m1
Sheet 7
Meta Modeling and XML (2)


Schemas play the role of models for XML documents;
Schemas may be considered as MOF models if a proper Schema meta-model
is defined;
Example:
In MOF Data Binding is a model transformation. Arbitrary transformation policies
may be specified.
MOF
M3
M2
XML Schema
Meta-model
M1
an XML
Schema
M0
an XML
Document
DocEng’03 , Grenoble, November 2003
Transformation Specification
Transformation Execution
instance of
Java Metamodel
Java Classes
Unmarshaling
Objects
Sheet 8
MDA based XML Processing


Document schema is a Source Model (at level M1);
Application Classes form a Target Model;
MOF
M3
instance of
M2
XML Schema
Meta-model
Transformation
Meta-model
Target Metamodel
M1
an XML
Schema
a Concrete
Transformation
a Target
Model
Executed by
M0
an XML
Document
source


Transformation
Engine
Objects
target
Transformations are specified between the source and the target model;
Transformations are executed over source XML documents and result in a set of
target objects;
DocEng’03 , Grenoble, November 2003
Sheet 9
XML Schema Meta-model
Fragment of the XML Schema Meta-model (based on the W3C specification)
Derivation
0..*
0..*
+substitutedBy
+base
+derivationType
1
1
0..1
+substitutes
+type
ElementDeclaration
+abstract
+topLevel
1
TypeDefinition
1
0..*
+name
+derived
+type
SimpleTypeDefinition
AttributeDeclaration
+topLevel
0..*
1
DocEng’03 , Grenoble, November 2003
ComplexTypeDefinition
+abstract
+mixed
Sheet 10
Target Meta-model
Constructs: Class, Attribute, Method, Generalization
ModelElement
+name
+feature
+child
Feature
GeneralizableElement
0..*
Relationship
1
1
+parent
0..*
+owner
Attribute
Method
+specialization
Classifier
1
Class
+generalization
Generalization
0..*
DataType
Fragment of the target meta-model (subset of UML meta-model)
DocEng’03 , Grenoble, November 2003
Sheet 11
Example: Address and Person
Source Schema
Simplified version of the “canonical” PurchaseOrder
schema from the XML Schema Primer:
Application Classes
(implemented in Java):
<complexType name="Address">
<sequence>
<element name="name“
type="string"/>
<element name="street"
type="string"/>
</sequence>
</complexType>
public class Address{
public String street;
}
<complexType name="USAddress">
<complexContent>
<extension base=’Address’>
<sequence>
<element name="zip "
type="string"/>
</sequence>
</extension>
</complexContent>
</complexType>
public class Person{
private Address address;
public String firstName;
public String lastName;
DocEng’03 , Grenoble, November 2003
public class USAddress extends Address{
public String zip;
}
public Person(Address address){
...
}
}
Sheet 12
Example: Target Model


The target model wraps the application Java classes
Deriving the target model from Java classes:





Java class to a model class;
Extension to generalization;
Public fields to attributes;
Constructor parameters to attributes;
Information not included in the target model:
 Collections that implement multivalued attributes;
 Access to the attributes;
Address
+street
Person
+firstName
+lastName
+address : Address
USAddress
+zip
DocEng’03 , Grenoble, November 2003
Sheet 13
Example: Transformation Specification
Transformation Language:
 Abstract Syntax: MOF-based Transformation Meta-model ;
 Concrete Syntax: specified as a grammar;
 Two types of rules: Class and Attribute Rules;
Class Rules: specify instantiations of classes in the target model based on selection of
source components:
Example:
personRule ClassRule
source [ Address:CT/name:E ]
Pattern
Attribute to be set
prior to the instantiation
target [ Person constructor {address}
{ firstName = getFirstName(source),
lastName = getLastName(source) } ]
Class to be instantiated
DocEng’03 , Grenoble, November 2003
Attribute to be set
after the instantiation
Sheet 14
Example: Transformation Specification
Attribute Rules: specify how the attribute values are obtained from the source.
Example:
addressAttribute rule specifies how to locate the value of the address attribute:
addressAttribute AttributeRule
source [*:E]
target [address]
path=’parent::*’
Attribute to be set
An XPath navigation expression that locates
the source nodes associated with the value
And the address object is created by another class rule:
addressRule ClassRule
source [ Address:CT ]
target [ Address {street} ]
DocEng’03 , Grenoble, November 2003
Sheet 15
Adaptation to Java
 Transformation language does not specify how objects are created
and attributes are set;
 In Java:
 Object creation: constructor, factory method;
 Attribute access: getter and setter methods, public fields;
 Multivalued attributes: implemented as collections (array, Vector,
etc.);
 This is provided separately as additional meta information;
DocEng’03 , Grenoble, November 2003
Sheet 16
Transformation Execution
 There is no predefined execution order over the rules;
 Implicit dependencies among the rules:
 Constructor attributes are calculated before class instantiation;
 Other attributes are set after the instantiation;
 During execution the dependencies are resolved
 Dependency graph is formed;
 Execution order is determined after a topological sort over the
dependency graph;
 Circularity prevents the execution of the transformation;
DocEng’03 , Grenoble, November 2003
Sheet 17
Conclusions
 Approach for XML Processing:
 Based on transformations between source schema and target
application model;
 Declarative language for defining transformations;
 Based on the MDA/MOF technology;
 Allows reuse of existing application classes;
 A prototype of an interpreter that supports the core
transformation language features is implemented;
DocEng’03 , Grenoble, November 2003
Sheet 18
Future Work
 Applying schema matching techniques for rule identification;
 Generalizing the language to the arbitrary model-to-model
transformations in the context of MOF;
 Reuse and composition of transformations following the
composition of the source XML schemas;
 More efficient rule execution;
DocEng’03 , Grenoble, November 2003
Sheet 19