A Case Study on the Transformation of Context-Aware
Domain Data onto XML Schemas
Cléver R. G. de Farias
1
, Luís Ferreira Pires
2
and Marten van Sinderen
2
1
Department of Physics and Mathematics, University of São Paulo
Av. Bandeirantes 3900, 14040-901, Ribeirão Preto (SP), Brazil
2
Centre for Telematics and Information Technology, University of Twente
PO Box 217, 7500 AE, Enschede, the Netherlands
Abstract. In order to accelerate the development of context-aware applications,
it would be convenient to have a smooth path between the context models and
the automated services that support these models. This paper discusses how
MDA technology (metamodelling and the QVT standard) can support the trans-
formation of high-level models of context-aware services onto the implementa-
tion of these services using web services. The total transformation process from
context-aware services onto web services involves the following aspects: 1. ser-
vice signatures, which should be translated onto WSDL definitions; 2. context-
aware domain data used as input and output data in service operations, which
should be translated onto XML schemas; and 3. service behaviours, which
should be used to generate the service implementation. This paper concentrates
on the modelling and transformation of the context-aware domain data. The re-
sults of this paper are generally applicable to the transformation of elements of
any domain-specific language expressed in terms of a metamodel onto XML
Schema data.
1 Introduction
Context-aware applications are capable of using information about the application
user’s environment in order to improve the quality of the service provisioning. Such
applications are normally expensive to build and deploy, which justifies the current
research interest on context-aware services platforms meant to facilitate the develop-
ment of these applications [3]. Many context-aware platforms are based on context
models, in which the user’s context and context-aware services can be formalised.
In order to accelerate the development of context-aware applications, it would be
convenient to have a smooth path between the context models and the automated
services that support these models. More specifically, we have decided to experiment
with the transformation of high-level models of context-aware services (as in [2])
onto the implementation of these services using web services. We have investigated
the use of MDA technology, particularly metamodelling and the QVT standard, in
order to perform this transformation.
R. G. de Farias C., Ferreira Pires L. and van Sinderen M. (2007).
A Case Study on the Transformation of Context-Aware Domain Data onto XML Schemas.
In Proceedings of the 3rd International Workshop on Model-Driven Enterprise Information Systems, pages 63-72
DOI: 10.5220/0002431500630072
Copyright
c
SciTePress
The total transformation process from this context-aware service metamodel onto
web services involves the following aspects: 1) service signatures, which should be
translated onto WSDL definitions; 2) context-aware domain data used as input and
output data in service operations, which should be translated onto XML schemas,
and; 3) service behaviours, which should be used to generate the service implementa-
tion. This paper concentrates on the modelling and transformation of the context-
aware domain data. The results of this paper are generally applicable to the transfor-
mation onto XML Schema data of elements of any domain-specific language ex-
pressed in terms of a metamodel.
The paper is further structured as follows: Section 2 describes the context-aware
service metamodel we have used in this paper; Section 3 introduces the XML Schema
metamodel that we have defined for our transformation; Section 4 discusses the trans-
formation specification; Section 5 gives an example to illustrate the benefits of our
approach; and finally Section 6 gives our conclusions.
2 Context-aware Service Metamodel
The Context-Aware Service (CWS) metamodel represents a set of concepts used to
capture service definitions and their association to context-aware information. This
metamodel was defined using the OMG MOF specification [7]. The major motivation
behind the definition of a context-aware service metamodel is the possibility of pro-
ducing general service descriptions independently of a particular platform, and relat-
ing such descriptions to context-aware information. Fig. 1 illustrates the concepts
represented in the CWS metamodel. Our context-aware service metamodel has been
discussed in detail in [2].
The CWS metamodel is organised around the metaclass
Service. This metaclass
represents a (context-aware) service provided by a service provider. Service has a
single meta-attribute called
name, which identifies the service. The metaclass Provider
represents a service provider.
A service consists of a number of operations, represented by the metaclass
Ser-
viceOperation. ServiceOperation has two meta-attributes, viz., name, which identifies
the operation, and
interaction, which defines the type of interaction used by the opera-
tion.
InteractionType defines the domain of possible values of the meta-attribute interac-
tion
, viz., oneway and request-response.
Operations are composed of input, output, or fault messages. A message is repre-
sented by the metaclass
Message. This metaclass has a single meta-attribute, called
name, which represents the message identifier. A message is constructed based on
message parts, represented by the metaclass
MessagePart. This metaclass has two
meta-attributes, viz.,
name, which represents the message part identifier, and type,
which represents the type of the message part. The type of the message part may refer
to a primitive datatype or to a
CWClassifier.
64
Fig. 1. CWS metamodel.
3 XML Schema Definition Metamodel
Our approach towards the model-driven development of context-aware services con-
siders the use of web services as a target platform to implement these services. In
order to facilitate the implementation of these services as web services, we have de-
fined a metamodel for the Web Service Description Language (WSDL) [9] using
MOF. This metamodel is structured around three packages [1], namely XSD,
WSDLCore and BindingExtension. The XML Schema Definition (XSD) package
contains the concepts used to represent XML schemas. This metamodel is a simpli-
fied representation of the XML Schema Definition language [10]. The WSDLCore
package contains most of the concepts related to WSDL. The BindingExtension
package contains the concepts associated to the SOAP [8] binding extension to
WSDL. Since the focus of this paper is on the transformation of context-related in-
formation onto general-purpose XML Schema data, we concentrate on the description
of the XSD package. Fig. 2 shows the concepts represented in the XSD metamodel.
The XSD metamodel is organised around the metaclass
Schema, which represents
the structure of an XML document.
65
Fig. 2. XSD metamodel.
An XML schema defines the structure of an XML document through the specification
of a number of element, attribute and user defined type definitions. The metaclass
XSDElement represents an element definition. This metaclass has a single meta-
attribute called
name, which uniquely identifies the element within the document
namespace.
Each defined XSD element has an associated abstract data type definition, repre-
sented by the abstract metaclass
XSDType. This metaclass has a single attribute called
name, which uniquely identifies the data type within the document namespace. There
are two kinds of datatypes, viz., user-defined datatypes and built-in datatypes, repre-
sented by the abstract metaclasses
UserDefined and BuiltinDatatype, respectively.
The metaclass
BuiltinDatatype represents a number of pre-defined datatypes. In the
context of this work, we consider a subset of the built-in datatypes defined in the
XML schema language specification, namely string, boolean, integer, float, date, date
and time and any URI. Each one of these primitive datatypes is represented by the
metaclasses
String, Boolean, Integer, Float, Date, DateTime and AnyURI, respectively.
The metaclass
UserDefined represents a user-defined datatype specification. This
metaclass was introduced to facilitate the structuring of datatypes. This metaclass is
specialized into the metaclasses
SimpleType and ComplexType.
66
The metaclass SimpleType represents a user-defined datatype that contains only
text, i.e., it cannot contain any other XSD elements or attributes. The metaclass
Com-
plexType
represents a user-defined datatype that can contain other XSD elements
and/or attribute definitions. This metaclass has a single meta-attribute called
orderIndi-
cator
, which defines the ordering of the child XSD elements. Three different ordering
indicators are defined, viz.,
all, choice and sequence. The all ordering indicator specifies
that the child elements can appear in any order, and that each child element must
occur only once. The
choice ordering indicator specifies that only one of the contained
child elements can appear. The
sequence ordering indicator specifies that child ele-
ments must appear in a specific (sequence) order.
The metaclass
Attribute represents an XSD attribute. Attributes are used to provide
additional information about an element. This metaclass has three meta-attributes
called
name, which provides the attribute identification, defaultValue, which can be
used to specify a default value for the attribute, and
fixedValue, which can be used to
specify a fixed value to the attribute. The meta-attributes
defaultValue and fixedValue are
optional and cannot be both present at the same time.
4 Transformation Specification
In the QVT specification [6], there is no clear distinction between the concepts of
mapping and transformation. A transformation is defined in terms of mapping speci-
fications, which can be specified using different languages defined in a two level
declarative architecture, viz., relations, operational mappings and core. However,
some authors distinguish between mapping and transformation (see, e.g., [4, 5]).
According to [4], a mapping can be seen as a correspondence between the elements of
two metamodels, while a transformation can be defined as the activity of transforming
a source model into a target model according to a number of transformation defini-
tions. The benefit of this approach is that it allows a mapping to be defined independ-
ently of the transformation specification.
In the context of this work, we adopt the approach mentioned in [4], in which
mappings and transformations are explicitly separated. Therefore, we developed our
transformation specification between the CWS and the XSD metamodel in two con-
secutive steps: 1) the definition of the mappings for each context-aware information
element onto one or more XML schema elements, using the metamodel for mappings
proposed in [4], and 2) the specification of the transformation itself, i.e., the specifi-
cation of the mappings defined in the first step using the QVT notation [6].
In order to map context-aware information elements onto XML schema language
elements, we have to first consider the different alternative schema definitions and
make proper choices. In order to obtain these alternative schema definitions, we first
instantiated some context-aware information from our CWS metamodel, then created
an alternative schema definition for this sample information, and finally created one
or more XML documents for each alternative schema definition.
67
XSD of the CWEntity PDA:
<xs:element name=“PDA type=“CWClassifier”/>
<xs:complexType name=“CWClassifier”>
<xs:attribute name=ClassifierInfo” type=xs:string”
fixed=“CWEntity”/>
</xs:complexType>
XSD of the CWAttribute DeviceType:
<xs:element name=“DeviceType”>
<xs:complexType>
<xs:attribute name=“CWClassifier” type=xs:string”
fixed=“CWAttribute”/>
<xs:sequence>
<xs:element name=“value” type=“xs:string/>
<xs:element name=“timestamp
type=“xs:dateTime”/>
</xs:sequence>
</xs:complexType>
</xs:element>
XSD of the CWEntity PDA:
<xs:element name=“PDA>
<xs:complexType>
<xs:attribute name=CWClassifier” type=“xs:string”
fixed=“CWEntity”/>
</xs:complexType>
</xs:element>
XSD of the CWAttribute DeviceType:
<xs:element name=“DeviceType”>
<xs:complexType>
<xs:attribute name=CWClassifier” type=“xs:string”
fixed=“CWAttribute”/>
<xs:element name=“Model” type=“Model_Content”/>
</xs:complexType>
</xs:element>
<xs:complexType name=“Model_Content”>
<xs:sequence>
<xs:element name=“value type=“xs:string”/>
<xs:element name=“timestamp” type=“xs:dateTime”/>
</xs:sequence>
</xs:complexType>
(a) (b)
Fig. 3. Alternative schema definitions for context-aware information elements.
Fig. 3 illustrates two alternative schemas for some sample context-aware informa-
tion elements. In the context of this work, we have chosen the structure presented in
Fig. 3(b) because it is simple and allows the separation of the definition of
CWAttribute
and
Content elements, which can be used for traceability purposes.
After determining the schema definition to be applied, we have defined the map-
ping from context-aware information onto XML schema elements. Fig. 4 shows the
mappings between the two metamodel elements using the mapping metamodel pro-
posed by [4].
E2XSD
A2XSD
C2C
XSDElement
Attribute
BuiltinDatatype UserDefined
XSDType
SimpleType
ComplexType
Content
CWEntity CWAttribute
CWClassifier
Fig. 4. Mapping from Context-aware Information elements onto XML Schema elements.
In Fig. 4, a circle represents a correspondence, i.e., a model element used to spec-
ify the relationships between two or more elements (left and right elements). Each
relationship has one left element (represented by a single arrow) and one or more
right elements (represented by a double arrow). A mapping definition contains all
correspondences between two metamodels.
The specification of the transformation was carried out using the QVT Opera-
tional Mappings language. We have chosen this language because it offers a powerful
68
mechanism for specifying transformations using an imperative, procedural-like style.
Fig. 5 shows some fragments of the CWS2XSD transformation specification.
modeltype CWS uses ContextAwareServiceMetamodel;
modeltype WSDL uses WSDLMetamodel;
transformation CWS2WSDL (in cwsModel: CWS out wsdlModel: WSDL);
main(){
-- for each CWEntity create a corresponding XSDElement
cwsModel.objectsOfType(CWEntity)->map E2XSD();
-- for each CWAttribute create a corresponding XSDElement
cwsModel.objectsOfType(CWAttribute)->map A2XSD();
}
constructor Attribute::Attribute(v: String){
name := 'CWClassifier';
type := new String();
fixedValue := v;
}
mapping CWEntity::E2XSD(): result:XSDElement{…}
mapping CWAttribute::A2XSD(): result:XSDElement{
object result:XSDElement{
name := self.name;
type := new ComplexType();
type.attribute := new Attribute('CWAttribute');
type.element := self.content->map C2XSD();
}
}
mapping Content::C2XSD(): result:XSDElement{
object result:XSDElement{
name := self.name+'_Content';
type := new ComplexType();
type.orderIndicator := sequence;
type.element := sequence{
object v:XSDElement{
-- mapping of value meta-attribute
name := 'value';
-- map type of value metaattribute
type := if self.value.isKindOf(String) then
new String(); -- data type is String
elif …;
};
object t:XSDElement{
-- mapping of timestamp meta-attribute
name := 'timestamp';
type := new DateTime();
}
}
}
}
Fig. 5. CWS to XSD transformation specification.
The main clause of the CWS2XSD transformation specification defines that for
each
CWEntity and CWAttribute elements a corresponding XSD element should be cre-
ated through the application of the CWEntity to XSDElement (E2XSD) and CWAt-
tribute to XSDElement (A2XSD) mappings, respectively. Both mappings use a con-
structor called Attribute that creates an
Attribute element with a provided fixedValue.
The A2XSD mapping uses the Content to XSDElement (C2XSD) mapping to cre-
ate a corresponding XSD element for each Content element present in the CWS
model. The C2XSD mapping is straightforward. This mapping basically creates an
69
XSDElement and an associated ComplexType element. This ComplexType element basically
contains two XSD elements with associated built-in datatypes.
5 Transformation Application
In order to illustrate the proposed transformation specification, we have developed a
simple example involving a simple context-aware information model. Fig. 6 illus-
trates our example information model. The proposed example contains a
CWEntity
called
PDA and two associated CWAttributes, namely DeviceId and DeviceType. DeviceId
has a
Content element named Code, while DeviceType has a Content element named
Model. The association between PDA and DeviceId is captured through the identifiedBy
profiled
CWAssociation, while the association between PDA and DeviceType is captured
through a
hasType static CWAssociation. Since the relationships between CWEntity and
CWAttribute are not relevant for the transformation specification, we exempt ourselves
from discussing it further in this work. More information on these relationships can
be found in [2].
cd ContextAwareInformationExample
«cwentity»
PDA
«cwattribute»
DeviceType
«cwattribute»
DeviceId
«static»
hasType
«profiled»
identifiedBy
«content»
Model
+ value: String
+ timestamp: Date
«content»
Code
+ value: int
+ timestamp: Date
+content
+owner
«simpl
+content
+owner
«simple»
«owns»
«owns»
Fig. 6. Sample context-aware information model.
We have applied the proposed transformation rules to the information model above
and obtained an XML schema model as result. Fig. 7 depicts a fragment of the ob-
tained XML schema model. This fragment depicts the result of the mapping applied
onto the
DeviceType CWAttribute and associated Model Content element. The model frag-
ment illustrated in Fig. 7 can be serialized in order to obtain the XML schema defini-
tion represented in Fig. 3b, while Fig. 8 shows a sample XML document that can be
validated by the XML schema definition represented Fig. 3b.
70
cd Conte xt-Aw a re Schema
«xsdElement»
Dev iceType
«complexType»
«cwAttribute»
CWClassifier
- fixedValue: String = "CWAttribute"
«xsdElemen
Model
«datatype»
String
«complexType»
Model_Content
- orderIndicator: OrderIndicatorType = sequence
«xsdElemen
value
«xsdElemen
timestamp
«datatyp
String
«datatyp
DateTime
+type
+type
+owner
+element
+owner +element+type
+type
+element
+owner
+owner
+attribute
+type
Fig. 7. XML schema model for proposed information model.
<DeviceType CWClassifier=“CWAttribute”
<Model_Content>
<value>HP iPAQ hx2190</value>
<timestamp>2007-02-19T21:30:00Z</timestamp>
</Model_Content>
</DeviceType>
Fig. 8. XML document.
6 Conclusion
Model transformation is a key aspect in the model-driven development of software
applications. In general, transformations enable a development approach in which
high level models in a source domain are (automatically) transformed into more con-
crete models in a target domain. Thus, the QVT specification is at the core of the
OMG´s MDA initiative, since this specification defines how transformations can be
defined in a two-level declarative architecture.
This paper presents a case study on the use of QVT to define the transformation
between a (source) context-aware information metamodel and a (target) XML
Schema Definition metamodel. We also describe a number of steps that can be gener-
ally used to accelerate the development XML Schema Definitions from some corre-
sponding domain-specific information metamodel.
The definition of a transformation specification is a complex task involving
knowledge of both the source and target domains. This work has reinforced the no-
tion proposed by [4, 5] that the separation between mappings and transformation
specification helps structure this complexity. Additionally, tool support should be
available not only for the definition of source and target metamodels, but also for the
definition and execution of transformation specifications.
71
The work described in this paper is part of a larger initiative that aims at providing
a model-driven approach for the development of context-aware applications. In this
sense, we intend to work on the transformation specification of service signatures
from our context-aware service metamodel onto the WSDL metamodel. Additional
research is also needed to define a metamodel for service behaviour specification,
before being able to define how this service behaviour metamodel should be trans-
formed to some service implementation metamodel.
Acknowledgements
This work has been supported by the Brazilian National Council for Scientific and
Technological Development (CNPq), under project number 50.6284/2004-2, and by
the Freeband A-MUSE project (http://a-muse.freeband.nl), which is sponsored by the
Dutch government under contract BSIK 03025.
References
1. de Farias, C. R. G., Ferreira Pires, L., van Sinderen, M.: A MOF Metamodel for the Web
Service Description Language (WSDL). Project Deliverable, DBMWare/CNPq/D2.1, v.1.0,
2007.
2. de Farias, C. R. G., Medina Leite, M., Calvi, C. Z., Pessoa, R. M., Pereira Filho, J. G.: A
MOF Metamodel for the Development of Context-Aware Mobile Applications. In Proceed-
ings of the 22
nd
ACM Symposium on Applied Computing (SAC´07), (2007) 947-952.
3. Dockhorn Costa, P., Ferreira Pires, L., van Sinderen, M.J.: Designing a Configurable Ser-
vices Platform for Mobile Context-Aware Applications. International Journal of Pervasive
Computing and Communications, 1 (1) (2005) 13-25. ISSN 1742-7371
4. Lopes, D., Hammoudi, S., Bézivin, J., Jouault, F.: Generating Transformation Definition
from Mapping Specification: Application to Web Service Platform. In Proceedings of the
17th Conference on Advanced Information Systems Engineering (CAiSE'05), LNCS 3520
(2005) 309-325.
5. Lopes, D., Hammoudi, S., Bézivin, J., Jouault, F.: Mapping Specification in MDA: From
Theory to Practice. In: Konstantas, D., Bourrières, J.-P., Léonard, M., Boudjlida, N. (Eds).
Interoperability of Enterprise Software and Applications - INTEROP-ESA. Springer,
(2006) 253-264.
6. OMG: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, OMG
Adopted Specification. Object Management Group (2005).
7. OMG: Meta Object Facility (MOF) Core Specification, OMG Available Specification,
version 2.0. Object Management Group (2006).
8. W3C: Simple Object Access Protocol (SOAP) 1.1 (2000).
9. W3C: Web Services Description Language (WSDL) 1.1 (2001).
10. W3C: XML Schema Part 0: Primer, Second Edition (2004).
72