The Generation of the Components Meta-Models of an E-Orientation System Using the WSDL-UML Transformation

Full text

The generation of the components meta-models of an
E-orientation system using the WSDL-UML
transformation
Jihad Adib1, Hicham Moutachaouik2, Abdelaziz Marzak1, Mustapha Hain2
1(Laboratoire de Technologie d'Information et de Modélisation, University of Hassan II - Casablanca, Faculté des Sciences Ben
M’sik, Cdt Driss El Harti, BP 7955 Sidi Othman Casablanca, Maroc)
2(Laboratoire d’Ingénierie des Structures, Systèmes Intelligents et Energie Electrique, ENSAM CASABLANCA, University of
Hassan II Casablanca, Morocco)
Abstract—recently the utility of E-orientation platforms is
important in the student's life to choose the best path of their
academic and professional development. In a first article [1], we
have introduced a comparison and description of the existing E-
orientation platforms, which is based on the WSDL, the purpose
of which is to have a descriptive file enriched by features.
In this research paper we introduced an approach for
transforming the resulting WSDL document [1] (a Web services
description language) that is long and detailed into a visual model
(expressed in the UML Unified Modeling Language). This
modeling will help us to propose a meta-model of E-orientation
platforms to facilitate the guidness of students.
Keywords—e-orientation; wsdl; meta-model; uml; xml
I. INTRODUCTION
Orientation is a process of building or developing an
education or career, in this context E-orientation systems have
appeared to help students find the best solutions for their
academic and professional development, Our goal Is to have an
successful meta-model of the existing E-orientation platforms
to facilitate the orientation of the students. In order to achieve
our objective mentioned above we realized in the previous
paper a study on the existing platforms and we obtained a
WSDL (Web Service Description Language) [2] encompassing
all the functionalities and the attributes [1].
In this work we propose an approach for transforming a
WSDL document to a UML model to ensure a model of the
existing E-orientation platforms enriched by the functionalities
that allow to satisfy the student's orientation. Get to use the
Model Animated Architecture (MDA) which is presented by
the Object Management Group (OMG) [3].
First we represented the WSDL meta-model by a UML
class diagram, and then we proposed a UML extension for the
representation of the WSDL-based web service. This extension
was carried out with the objective of giving a UML notation
that allows to represent a Web service and we show it through
a case study.
This article will be organized as a follow-up: in section II
we present the WSDL meta-model, Section III representation
of the WSDL with UML, describes the UML extension for
WSDL, section IV representation of an application by means of
a study finally, in Section V, we conclude the main
contributions and future work.
II. WSDL METAMODEL
WSDL is an XML language [4] used to describe other Web
services and how to interact with these Web services. WSDL
provides a mechanism to define interfaces that can be used to
generate code, which makes the Web services language
independent. WSDL is implemented as an XML document that
contains a set of definitions for different Web services. WSDL
is a web service described in different XML formats, it is not a
W3C recommendation; rather, it is a proposal from IBM,
Microsoft and ARIBA to the W3C for a future
recommendation.
The content of the WSDL document is named as [5]:
TYPE: A Web service can define its own data types in this
section of the WSDL document. WSDL types must be based
on XSD data types (XML Schema, standard W3C). This
feature can be used to define custom data types that make sense
in the area served by particular Web services.
MESSAGE: This section of a WSDL document defines the
format of the messages transmitted around the different nodes.
For example, in the case of SOAP, this would be the SOAP
Envelope definition.
OPERATION: This section of the document defines the
different services offered by the Web service. Think of this as
the metadata of the remote procedure call for each Web service
to expose itself.
BINDING: special transport protocol. In addition, most
(well-designed) Web services do not force binding to a
particular protocol. In the link section of the WSDL document,
we can define the possible protocol bindings for a given Web
service and the compatibility of these bindings. It is also
important to note that the link must not belong to any particular
type of protocol. For example, WSDL could be used to
describe a Web service that is built on top of SOAP, which in
turn could use HTTP for its transport protocol. Alternatively, it
Electronic copy available at: https://ssrn.com/abstract=3178718

could be used to describe a web service built on the HTTP
itself (with XML- based messages to preserve the definition of
a Web service).
PORT: While operations allow us to describe the metadata
on each procedure call, ports are what we get after the
operation is bound to a transport protocol.
The port is the mechanism used by nodes to send messages
back and forth.
PORT TYPE: Sometimes a given operation can be
supported by one or more ports. If this is the case, we still need
to group the ports that support this operation so that a selection
from this port provides the operation that can be performed.
The port type is a way of consolidating ports, for this purpose,
by the operations they support.
SERVICE: Service is high-level abstraction that allows you
to group endpoints and operations to create a Web service
Fig. 1 shows the WSDL meta-model represented by a UML
class diagram.
The definitions included on the WSDL standard can be
separated into two different groups of components, depending
on the level of abstraction of the respective concept represented
by each class. The dark components represent the concrete
problems of the description of the service, while the rest
represent the abstract problems of this description.
A WSDL document contains a version number and a
DEFINITION root component. It has Name and
TargetNameSpace attributes and zero or more namespaces.
Namespaces are used to avoid naming conflicts when multiple
services or applications are embedded. A DEFINITION
component contains: a TYPES component and zero or more
MESSAGE, PORTTYPE, BINDING, and SERVICE
components. All WSDL components can be associated with a
DOCUMENTATION component.
A TYPES component is used for the data type definitions
that will be used in messages. For this WSDL is based on XML
Schemaet contains a SCHEMA component in which
namespaces and data types are defined. WSDL allows to
include previously defined XML schema documents, using an
INCLUDE component indicating the location of the document.
Similarly, the IMPORT component is used to reuse WSDL
documents, in which case the document name and location are
required The PORTTYPE component is the most important
component of WSDL because it describes the operations that
the service performs, ie the interface.
The OPERATION component consists of all the messages
that will be exchanged between the service provider and the
requestor. Each operation can be associated with one, two or
three messages, either an input message, an output message or
both, and possibly an error message. A MESSAGE contains a
Name attribute and zero or more of the PARTIES components.
The PART component describes a portion of a particular
message that a Web service sends or receives. The type
associated with a PART can be an XSD base type ( float,
String, etc.) or a type defined in the TYPES section. In this
case, the data type can be defined by means of a type or
element attribute.
A BINDING component describes the binding of a
PORTTYPE component and operations associated with a
concrete message format and a communication protocol, such
as SOAP, HTTP or MIME [6]. WSDL defines different
components to describe each of these protocols.
A SERVICE component contains a Name attribute and
describes all of the PORTs that a service provides. A PORT
component contains a Name attribute. It is linked to the
BINDING component that describes how and where (through
the location attribute) to interact with the service interface.
Fig. 1. WSDL metamodel represented in UML
III. REPRESENTATION OF WSDL WITH UML
As described in the previous section, WSDL uses XML to
define data types, which provides facilities for defining new
data types. Such a feature can be mapped to UML.
Since UML [7] does not support the modeling of concepts
conforming to the previous meta-model, we must extend it
using its own extension mechanisms to allow representation of
the components included in the previous meta-model.
UML has been designed to be expanded in a controllable
way.
Before showing the proposed UML extension, we will
explain the design guidelines that have been defined for the
representation of WSDL in Extended UML.
To choose the stereotypes needed to represent all WSDL
meta-model components in UML and the relationships between
them, the following design guidelines are defined:
DEFINITION component has been considered as an
stereotyped class because it is explicitly defined in WSDL and
it constitutes the root component that groups all the used
elements.
• TYPES and SCHEMA components have been considered
compositions stereotyped with <<TypeSchema>> and
represent the relation between a DEFINITION component and
the data type definitions.
• MESSAGE, PART, PORT TYPE, OPERATION,
BINDING, PORT, SERVICE and IMPORT components have
Electronic copy available at: https://ssrn.com/abstract=3178718

been considered stereotyped classes because they represent
important components and they are explicitly defined in
WSDL.
• Each MESSAGE component will be related to the PART
component that it uses by means of a composition.
• The relationship between a PART component and an
ELEMENT component will be represented by means of: an
association stereotyped with <<Part_Type>> if the PART
component uses the ELEMENT as a type; an association
stereotyped with <<Part_Element>> if the PART component
uses the ELEMENT as an element.
• The relation between an OPERATION component and a
MESSAGE component will be represented by means of an
association stereotyped with <<Input>>, <<Output>> or
<<Fault>>, depending on the type of the message: an input
message, an output message or a fault message.
• MESSAGE, PORTTYPE, BINDING, SERVICE and
IMPORT components will be related to the DEFINITION
component by means of a composition.
• PORTTYPE component will be related to the
OPERATION component that it uses by means of an
aggregation.
• BINDING component will be associated to the PORT
TYPE component that it describes.
• SERVICE component will be related to the PORT
components that it provides by means of a composition.
• The PORT component will be associated to the BINDING
component that it uses.
As we have already said, WSDL uses XML Schema for the
definition of the data types that will be used for message
sending. For this reason we use the UML extensions to
represent XML Schemas proposed in [8].
Table 1 provides the most important basics you need to
map WSDL applications to UML and should not be
exhaustive. The references used here describe the mapping of
features and constructs between WSDL and UML.
The UML extension collected in Table 1 defines a set of
stereotypes, marked values and constraints that allow us to
represent WSDL in graphical notation using UML. The UML
extension is defined for the WSDL components included in the
W3C proposal. Each WSDL component should be able to be
represented in graphical notation with this UML extension [9].
TABLE I. UML EXTENTION FOR WSDL
Component
UML
Metamodel
Component
Description
Constraints, Attributes & Tagged Values
DEFINITION
CLASS
A <<DEFINITION>> class
represents a DEFINITION
component of the WSDL
metamodel.
ATTRIBUTE: TargetNameSpace is an URI (Uniform Resource
Identifier). It is mandatory and identifies the namespace which it will
belong all of the component names.
TAGGED VALUES: Other namespaces that will be used in the Web
service description.
ELEMENT
CLASS
An <<ELEMENT>> class
represents an element of the
XML Schema.
It must be related to the <<DEFINITION>> class by means of a
composition stereotyped with <<Type_Schema>>.
TAGGED VALUES: The name of the element, the base type and the
minimum and maximum number of occurrences.
Type_Schema
COMPOSITION
A <<Type_Schema>>
Composition represents a
relationship between the
DEFINITION component of
the WSDL metamodel and
the data types defined by
means of element of the
XML Schema.
It can only be used to join a <<DEFINITION>> class with the
<<ELEMENT>> class that uses it.
TAGGED VALUES: The namespace defined for SCHEMA
component.
MESSAGE
CLASS
A <<MESSAGE>> class
represents a MESSAGE
component of the WSDL
metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition and must be associated to at least one
<<PART>> class.
PART
CLASS
A <<PART>> class
represents a PART
component of the WSDL
metamodel.
It must be related to one <<MESSAGE>> class by means of a
composition.
ATTRIBUTE: Type is a base type XSD. It is optionally and must be
defined when the PART component uses a base type but not when
the PART component uses an element of the XML Schema.
A <<Part_Type>> or
<<Part_Element>>
A <<Part_Type>> association can only be used to join a
<<PART>> class with an <<ELEMENT>> class when a PART
Electronic copy available at: https://ssrn.com/abstract=3178718

Part_Type
and
Part_Element
ASSOCIATION
association represents a
relationship between a PART
component of the WSDL
metamodel and an element of
the XML Schema.
component uses the element as a type. A <<Part_Element>>
association can only be used to join a <<PART>> class with
an <<ELEMENT>> class when a PART component uses the
element as a element.
PORTTYPE
CLASS
A <<PORTTYPE>> class
represents a PORTTYPE
component of the WSDL
metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition and must be associated at less one <<OPERATION>>
class.
OPERATION
CLASS
An <<OPERATION>> class
represents an OPERATION
component of the WSDL
metamodel
It must be related to the <<PORTTYPE>> class by means of an
aggregation.
Input, Output
and
Fault
ASSOCIATION
An <<Input>>, <<Output>>
or <<Fault>> association
represents a relationship
between an OPERATION
component and MESSAGE
component of the WSDL
metamodel.
A <<Input>> association can only be used to join an
<<OPERATION>> class with a <<MESSAGE>> class when the
message is an input message. A << Output>> association can only
be used to join an <<OPERATION>> class with a <<MESSAGE>>
class when the message is an output message.
A <<Fault>> association can only be used to join an
<<OPERATION>> class with a <<MESSAGE>> class when the
message is a fault message.
BINDING
CLASS
A <<BINDING>> class
represents a BINDING
component of the WSDL
metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition and it must be associated to only one
<<PORTTYPE>> class.
SERVICE
CLASS
A <<SERVICE>> class
represents a SERVICE
component of the WSDL
metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition and it must be composed by at least one
<<PORT >> class.
PORT
CLASS
A <<PORT>> class
represents a PORT
component of the
WSDL metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition and must be associated to only one <<BINDING>>
class.
ATTRIBUTE: Location is an URL (Uniform Resource
Locator). It is mandatory and identifies the access point to PORT
CLASS the service.
ATTRIBUTES: Namespace is an URI (Uniform Resource Identifier).
It is mandatory and indicates that the containing WSDL document
can contain references to the WSDL definitions in that namespace.
Location is an URI (Uniform Resource Identifier). It is optional and
indicates the location of some information for the namespace.
IMPORT
CLASS
An <<IMPORT>> class
represents an IMPORT
component of the WSDL
metamodel.
It must be related to the <<DEFINITION>> class by means of a
composition.
ATTRIBUTES: Namespace is an URI (Uniform Resource Identifier).
It is mandatory and indicates that the containing WSDL document
can contain references to the WSDL definitions in that namespace.
Location is an URI (Uniform Resource Identifier). It is optional and
indicates the location of some information for the namespace
IV. A CASE STUDY
In this section, we show, through a case study, that the use
of the UML extension was used for the representation of
WSDL.
The study we are going to present will be applied to the
WSDL file generated in the article [1] which encompasses
several functionalities.
Fig. 2 shows the description of the Web service
"Etablissement" in WSDL. The Web service defines several
operations among them "ConsulterEtablissement" which
includes two messages, an input message and an output
message.
The input message "ConsulterEtablissementRequest"
defines one part, “Parameters”, which uses the element
"ConsulterEtablissement" as a data type.
The output message "ConsulterEtablissementResponse"
defines one part, “Parameters”, which uses the element
"ConsulterEtablissement " as a data type.
Both, the "ConsulterEtablissement" and "
ConsulterEtablissementResponse " elements have been defined
in the section types. The porttype " Etablissement" groups the
operations that will be performed by the service, in this case
there are several operations, set Statut, set Formation, get
Durre_, get Type_ set Sector, get Concour, get Diplome ......
Electronic copy available at: https://ssrn.com/abstract=3178718

The link between this port type and the SOAP protocol is
described by the "EtablissementSoapBinding" element. The
service has only one port "Etablissement" that defines via a
URL the website.
Fig. 2. WSDL description of a “Etablissement” Web Service
Fig. 3 shows the UML representation of the component
DEFINITION. The Name attribute will be the name of the
class and the Target Name Space attribute will be
represented as a class attribute. The namespaces used will be
represented as marked values. For clarity, a marked value
will be represented as a note associated with the element that
uses it.
Fig. 3. Representation of the DEFINITION component
Fig. 4 shows the "TypesSchema" Composition, which
represents a relationship between the "DÉFINITION" Class
and the defined data types, " ConsulterEtablissement " and "
ConsulterEtablissementResponse". The Target Name Space
attribute of the SCHEMA component will be represented as
marked values
Electronic copy available at: https://ssrn.com/abstract=3178718

Fig. 4. Representation of the ELEMENT, TYPES and SCHEMA
components
Fig. 5 shows the representation of the MESSAGE and
PART components. The message "
ConsulterEtablissementRequest" contains a part that has
associated the item " ConsulterEtablissement" as the data
type. Therefore, the existing association between the
"ParametersIn" part and the " ConsulterEtablissement"
element is stereotyped with "Part Element". In the same way,
the existing association between the "ParametersOut" part
and the "ConsulterEtablissementResponse" element is
stereotyped with "Part Element".
Fig. 5. Representation of the MESSAGE and PART components
Fig. 6 shows the representation of the PORTTYPE and
OPERATION components The "Etablissement" uses the
operation "ConsulterEtablissement ", so an aggregation is
represented between them. The operation defines two
messages, the input message "ConsulterEtablissement
Request" is linked to the "ConsulterEtablissement" operation
by the <<InPut>> association and the output message
"ConsulterEtablissementResponse" is related to the operation
"ConsulterEtablissement" by The association <<OutPut>>.
Fig. 6. Representation of the PORTYPE and OPERATION components
Fig. 7 shows the representation of the BINDING
component, without representing the connection with the
SOAP protocol. The "EtablissementSoapBinding" describes
the binding to the port type; Therefore, an association
between the "EtablissementSoapBinding " link and the "
Etablissement" port type is represented.
Fig. 7. Representation of the BINDING component
Finally, Fig. 8 shows the representation of the SERVICE
and PORT components. The "EtablissementService" service
contains a port, "Etablissement ", so the composition is
represented between them. The Location attribute specifies
the URL of the service and is represented as a class attribute.
Electronic copy available at: https://ssrn.com/abstract=3178718

Fig. 8. Representation of the SERVICE and PORT components
Fig. 9 shows the representation of the Web service
"Etablissement" using a defined UML extension.
Fig. 9. UML representation of web service”Etablissement”
CONCLUSION
In this work, we presented the WSDL meta-model to
introduce a WSDL file with UML, and we described the
UML extension for WSDL.
For the definition of the UML extension we first
described each of the components of the WSDL meta-model
using UML, and then we presented the design guidelines for
the definition of the extension. To validate the proposed
extension, we have developed the case of a WSDL file of the
Establishment functionality. In the next article we will
propose a general and enriched meta-model that combines
several features of the e-guidance platforms using the Model
Driven Architecture (MDA).
REFERENCES
[1] J. Adib, A. Marzak, H. Moutachaouik, M. Hain “Towards a Meta-
model of E-orientation platforms”, IOSR Journal of Computer
Engineering e-ISSN: 2278-0661,p-ISSN: 2278-8727, Volume 19,
Issue 4, Ver. IV. (Jul.-Aug. 2017), PP 74-79
[2] Web Services Description Language (WSDL), W3C Note, http://
www.w3.org/TR/wsdl, 2012
[3] OMG. OMG Model Driven Architecture. Miller, J., Mukerji, J. (eds.)
2001. Document number ormsc/2001-07-01. Retrieved from:
http://www.omg.com/mda, 2003
[4] W3C XML Schema Working Group. “XML Schema Parts 0-
2:[Primer, Structures, Datatypes]”. W3C Recommendation. Retrieved
from:
http://www.w3.org/TR/xmlschema-0/,
http://www.w3.org/TR/xmlschema-1/ and
http://www.w3.org/TR/xmlschema-2/, 2004.
[5] R. B’FAR, “Mobile Computing Principles Designing And
Applications With UML And XML Schema”, ISBN-13 978-0-511-
26576-1 eBook (NetLibrary), 2004.
[6] W3C Web Services Description Language (WSDL) Version 1.2:
Bindings. W3C Working Draft 3 March 2003. Retrieved from:
http://www.w3.org/TR/2003/WD-wsdl12- bindings-20030124/, 2003.
[7] J. Conallen. Building Web Applications with UML. Addison Wesley,
2000.
[8] B. Vela and E. Marcos. “Extending UML to represent XML
Schemas”, The 15th Conference On Advanced Information Systems
Engineering CAISE’03 FORUM, Klagenfurt/ Velden, p. 16-20, 2003.
[9] E.Marcos, V.Castro, M. Vara, “ WSDL automatic generation from
UML models in a MDA framework”, Conference PaperDOI:
10.1109/NWESP.2005.87 · Source: IEEE Xplore, 2005
Electronic copy available at: https://ssrn.com/abstract=3178718