sheet 1 doceng’03, grenoble, november 2003 model driven architecture based xml processing ivan...
Post on 14-Jan-2016
214 Views
Preview:
TRANSCRIPT
Sheet 1DocEng’03 , Grenoble, November 2003
Model Driven Architecture based
XML Processing
Ivan Kurtev, Klaas van den BergUniversity of Twente, the Netherlands
Sheet 2DocEng’03 , Grenoble, November 2003
Outline
Technologies for XML Processing; Problem Statement; Model Driven Architecture (MDA)
Concepts; MDA based XML Processing; Example; Transformation Language; Conclusions;
Sheet 3DocEng’03 , Grenoble, November 2003
Context
Applications written in an OO language
Main goal: transform a document into a set of application objects;
Domain
Domain
XMLDocument
ApplicationObjects
ApplicationClasses
Transformation
Encodes data from
Implements concepts
Instances
The Transformation is a recurring task and requires automation
Sheet 4DocEng’03 , Grenoble, November 2003
Technologies for XML Processing
XMLDocument
Schema
DOMParser
ProcessingCode
DOM Tree Application Objects
Generic interfaces to XML documents (e.g. DOM)
ApplicationClasses
XMLDocument
Objects
Compilation
Unmarshalling
Instance of Instance of
Data Binding
Tree traversing, class instantiation, type conversions are performed by processing code.
Compilation and Unmarshalling are automated;
Not applicable in case of dissimilarities between the schema and the application structure;
Sheet 5DocEng’03 , Grenoble, November 2003
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;
Sheet 6DocEng’03 , Grenoble, November 2003
Basic MDA Concepts
Source Model Transformer Target Model
TransformationSpecification
Model Transformations– The MDA Pattern (from “MDA Guide”):
PlatformIndependentModel (PIM)
PlatformSpecific
Model (PSM)
Separation of system specification from system implementation;
Models:
Sheet 7DocEng’03 , Grenoble, November 2003
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;
The MOFMMM
The UML MM
A UML Modelm1
A particularuse of m1
Level M3
Level M2
Level M1
Level M0
The Java MM
A UML Modelm2
Another useof m1
Meta Schema(Schema forschemas)
An XMLSchema
An XMLDocument
MOF XMLExample:
Sheet 8DocEng’03 , Grenoble, November 2003
Schemas play the role of models for XML documents; Schemas may be considered as MOF models if a proper Schema
meta-model is defined;
MOF
XML SchemaMeta-model
Java Meta-model
an XMLSchema
Java Classes
an XMLDocument
ObjectsM0
M1
M2
M3 instance of
Transformation Specification
Unmarshaling
Transformation Execution
Example:In MOF Data Binding is a model transformation. Arbitrary transformation policiesmay be specified.
Meta Modeling and XML (2)
Sheet 9DocEng’03 , Grenoble, November 2003
MDA based XML Processing Document schema is a Source Model (at level M1); Application Classes form a Target Model;
MOF
XML SchemaMeta-model
TransformationMeta-model
Target Meta-model
an XMLSchema
a ConcreteTransformation
a TargetModel
an XMLDocument
Objects
source target
Executed by
M0
M1
M2
M3
TransformationEngine
instance of
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;
Sheet 10DocEng’03 , Grenoble, November 2003
XML Schema Meta-model
Fragment of the XML Schema Meta-model (based on the W3C specification)
+name
TypeDefinition
SimpleTypeDefinition
+abstract+mixed
ComplexTypeDefinition
+derivationType
Derivation
+abstract+topLevel
ElementDeclaration
+topLevel
AttributeDeclaration
1
+derived
1
+base 10..*
0..*
+type
1
0..*
+type
1
+substitutes
0..1
+substitutedBy0..*
Sheet 11DocEng’03 , Grenoble, November 2003
Target Meta-modelConstructs: Class, Attribute, Method, Generalization
+name
ModelElement
Feature GeneralizableElement Relationship
Classifier
Class DataType
Attribute Method Generalization
+feature
0..*
+owner
1
+child
1
+generalization0..*
+parent1
+specialization
0..*
Fragment of the target meta-model (subset of UML meta-model)
Sheet 12DocEng’03 , Grenoble, November 2003
Example: Address and PersonSource SchemaSimplified version of the “canonical”
PurchaseOrderschema from the XML Schema Primer:
<complexType name="Address"> <sequence> <element name="name“ type="string"/> <element name="street" type="string"/> </sequence></complexType>
<complexType name="USAddress"> <complexContent> <extension base=’Address’> <sequence> <element name="zip " type="string"/> </sequence> </extension> </complexContent></complexType>
Application Classes (implemented in Java):
public class Address{ public String street;}
public class USAddress extends Address{
public String zip;}
public class Person{ private Address address; public String firstName; public String lastName;
public Person(Address address){ ... }}
Sheet 13DocEng’03 , Grenoble, November 2003
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;
+street
Address
+zip
USAddress
+firstName+lastName+address : Address
Person
Sheet 14DocEng’03 , Grenoble, November 2003
Example: Transformation SpecificationTransformation 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:
personRule ClassRule source [ Address:CT/name:E ]
target [ Person constructor {address} { firstName = getFirstName(source), lastName = getLastName(source) } ]
Pattern
Class to be instantiated
Attribute to be setprior to the instantiation
Attribute to be setafter the instantiation
Example:
Sheet 15DocEng’03 , Grenoble, November 2003
Example: Transformation Specification
Attribute Rules: specify how the attribute values are obtained from the source.
addressAttribute AttributeRule source [*:E] target [address]
path=’parent::*’ An XPath navigation expression that locatesthe source nodes associated with the value
Attribute to be set
addressAttribute rule specifies how to locate the value of the address attribute:
And the address object is created by another class rule:
addressRule ClassRule source [ Address:CT ] target [ Address {street} ]
Example:
Sheet 16DocEng’03 , Grenoble, November 2003
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;
Sheet 17DocEng’03 , Grenoble, November 2003
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;
Sheet 18DocEng’03 , Grenoble, November 2003
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;
Sheet 19DocEng’03 , Grenoble, November 2003
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;
top related