Copyright © 2004, Idea Group Inc. International Journal of Web Services Research, 1(4), Oct-Dec 2004
Model-driven Web Service
Development1, 2
Roy Grønmo, SINTEF, Norway
David Skogan, SINTEF, Norway
Ida Solheim, SINTEF, Norway
Jon Oldevik, SINTEF, Norway
ABSTRACT
Web service technologies are becoming increasingly important for integrating systems and services. There is much activity and interest around standardization and
usage of web service technologies. Contemporary web services are described in the
Web Service Description Language (WSDL). However, WSDL documents can be
difficult to understand for service developers. This paper recommends a modeldriven process for web service development combining the graphical modeling language UML with WSDL. The Unified Modeling Language (UML) is developed by
Object Management Group. In the proposed process, web service descriptions (in
WDSL) are converted to UML; their UML models are integrated to form composite
web services; and then the new web service descriptions are exported. The main contribution of this paper is a “pure UML” modeling strategy supported by implementation of two-way conversion rules between the UML models and the WSDL documents.
Keywords: MDA, WSDL, UML
INTRODUCTION
Web services are functional
components, available over the Internet, and described in the Web Service
Definition
Language
(WDSL)
(Christensen et al., 2001). WSDL descriptions are often complex in nature
and are usually automatically generated by web service development
tools such as Apache Axis or .NET.
To humans, WSDL descriptions can
be more or less incomprehensible,
which makes it difficult to decide if
an existing web service is applicable
to a selected task. Comprehension is a
problem, not only regarding the semantics of the operations and their
parameters, but also when it comes to
understanding what the web service
really does.
This paper investigates the use of
the Unified Modeling Language
(UML) to express the content and be-
havior of web services in a more understandable way than WSDL. This
approach is motivated by the Modeldriven Architecture (MDA) initiative
of the Object Management Group
(OMG) (OMG, 2002b). The UML is
a central component of the MDA.
The UML provides different kinds of
model constructs and diagrams with
roots in object-oriented programming.
In model-driven development, models
are used to describe business concerns, user requirements, activities,
information structures, components
and component interactions of a system. Most important are the class
diagrams, which are used to describe
interfaces and classes with their operations and attributes. Such models
govern the system development in
that they can be transformed to program code. In the case of web service
development, the models are transformed into the Web Service Description Language.
UML modeling for automatic
generation of CORBA IDL, Java
code, EJB etc. has been successfully
tried out, e.g. (SINTEF, 2004). When
it comes to web services, two different UML approaches are reported in
the literature (Provost, 2003; Thöne
et al., 2002). Provost (2003) presents
a WSDL-dependent approach by extending UML with WSDL-specific
constructs. On the other hand, Thöne
et al. (2002) presents a WSDLindependent approach with only pure
UML constructs such as classes and
interfaces. This paper questions the
need for WSDL-dependent UML
modeling approaches and investigates
the usefulness of WSDL-independent
UML models for web service specification. The following two questions
are addressed:
(a) Are WSDL-specific UML
constructs necessary to understand
what the web service does? Or does
pure UML provide even better understanding?
(b) Are WSDL-specific UML
constructs necessary for forward
and/or reverse engineering of web
services? Or can pure UML be used
successfully for the same conversions?
Extending UML with platformspecific constructs is quite popular.
An example from code generation is
the UML profile for the Business
Process
Execution
Language
(BPEL4WS), which can be used to
automatically generate BPEL4WS
documents (Gardner, 2003). The Hypermodel tool of Carlson (2003) has
the ability to import XML Schema
into UML, but the resulting UML
model has extensions specific to
XML Schema. Kollman et al. (2002)
give an overview of state of the art in
reverse engineering, in which none of
the referred tools uses platformindependent models. Nevertheless,
we are of the opinion that the pure
UML modeling approach advocated
in this paper, supported by adequate
conversion rules between UML and
WSDL, both aids the comprehension
and suffices for reverse and forward
engineering of web services.
The paper continues with a description of the model-driven web
service development process, followed by the distinction of interface
modeling from workflow modeling.
Then, conversion rules between UML
and WSDL are presented, followed
by a description of a tool used to implement these conversions. Finally,
the approach is evaluated and the
work is concluded.
MODEL-DRIVEN WEB
SERVICE DEVELOPMENT
As the number of web services
available is increasing, it seems natural to reuse existing web services and
thus aim at creating composite web
services. A model-driven web service
development process is depicted in
Figure 1. It shows a UML activity
diagram indicating the steps of
model-driven development of composite web services. In the first step
(Discover Web Services) the developer uses a web-browser, a registry
client (typically UDDI) to search and
discover candidate web services that
may be used in the composite service.
The output of this activity is a list of
web service descriptions, represented
as WSDL documents. The web service descriptions are then converted
into UML by a reverse engineering
transformation (Import Web Service
Descriptions). The output of this step
is one or more UML models of the
discovered web services, e.g. as depicted in Figure 3. It will be easier for
the developer to comprehend the
UML models of the web service interface than to understand the WSDL
documents.
The developer then uses a UML
tool to review and integrate the imported models to form a model of a
composite web service (Model Composite Web Service). This activity
consists of two sub-activities, interface modeling and workflow modeling. The interface modeling specifies
the service's interface and its operations, whereas the workflow modeling specifies the service's internal
processes. The output is a new UML
model representing the new composite web service with its interfaces and
its workflow. This model can now be
used to generate the WSDL description of the composite service (Export
Web Service Descriptions) and to
generate its executable workflow description. The latter is suitable for
implementing the service (Implement
Composite Web Service), for example by means of an execution engine
Figure 1. Model-Driven Web Service Development
MODEL COMPOSITE WEB SERVICE
WSDL
UML
Interface Modeling
Discover
Web Services
Import Web Service
Descriptions
GENERATION TOOL
Export Web Service
Descriptions
CompositeWebServiceWSDL
Workflow Modeling
Implement Composite Web
Service in Workflow Engine
Publish Composite
Web Service
Export Execution
Code
Execution document
BPELWS,
WSCI, BPML etc
(Gardner, 2003). An execution engine
executes the different activities,
specified in a workflow execution
document, in the correct order and
with the required data inputs and outputs. Finally, the service is published
in an appropriate registry, making it
available for use (Publish Composite
Web Service). This paper concentrates on the three activities Import
Web Service Descriptions, Interface
Modeling and Export Web Service
Descriptions.
The next two sections focus on
the core of the model-driven web services development, which is the UML
modeling part. We will concentrate
on capturing the conceptual models
without introducing all the complexity provided by WSDL and other web
service specifications.
INTERFACE MODELING
A web service basically provides
a set of operations. We have developed a metamodel for interface modeling of a web service (Figure 2). A
web service is modeled as a BusinessService. The BusinessService realizes a set of Interfaces. An Interface
has a set of operations with input parameters and return type. The parameter types are defined by a class.
The behavior of the operation is defined by a workflow model. Instances
of this metamodel may be modeled as
UML class models.
UML has two extension mechanisms that allow developers to specify user- defined constructs. The first
extension mechanism is stereotypes
and the second is tagged values. New
stereotypes can be defined and used
to model special types of classes.
Tagged values are name-value pairs
that can be associated with classes,
operations or attributes to signify a
special treatment in transformations
and/or code generation.
Figure 3 shows a possible instance of the metamodel. The BusinessService is mapped to a UML
class with stereotype <<BusinessService>>. The service MyWebService
realizes two interfaces. These two
Figure 2. Metamodel for Interface Modeling of Web Services
BusinessService
1..*
Workflow
Model
0..1
+realizes
Interface
1..*
+behaviour
Operation
+publicOperations
0..*
+inputParameters
Class
1
+type
0..1 +returnType
Parameter
Figure 3. A Web Service Interface Model
BasicWFS
+DescribeFeatureType()
+getCapabilities()
+GetFeature()
CreditCard
-expires : date
-number : string
TransactionWFS
+lockFeature()
+transaction()
Payment
+validate( card : CreditCard ) : boolean
<<BusinessService>>
MyWebService
interfaces have a total of six operations (including the inherited operations) which are provided by MyWebService. The operation validate takes
an input parameter further defined by
the class CreditCard.
WORKFLOW MODELING
We will use the term workflow
even though several other terms are
used in the literature, e.g. composition, business process, orchestration
and choreography. Workflow modeling identifies the internal behavior of
a web service operation, for instance
how existing web services are used
together in order to produce a composite web service. Workflow modeling is about identifying the activities
of the operation and specifying the
order in which they are performed.
Furthermore, each activity may have
input and output data objects. The
activities and data objects will need
to refer to elements already defined in
existing web services. This relationship is illustrated and explained in the
following example.
The left-hand side of Figure 4
expresses a workflow model in a
UML activity diagram. This model
refers to elements used in the reverseengineered UML model of a WSDLdescribed web service (right-hand
side of Figure 4). The workflow reuses three other web services in order
to produce a new composite web service. Each activity is stereotyped
WebService to indicate that it invokes
an operation of a web service. Activity number two, ValidateCreditCard,
takes a credit card object as input and
gives a boolean response indicating if
the credit card is valid or not. The
input data object is of type CreditCard, which refers to a class in the
imported WSDL specification. The
ValidateCreditCard has a set of
tagged values that identifies the exact
web service operation to invoke. The
WSDL value identifies the imported
Figure 4. Imported WSDL Model used in the Workflow Model
Imported
WSDL
WSDL1
<<WebService>>
Activity1
input1 : type1
output1 : type2
MyWebService
<<WebService>>
ValidateCreditCard
{Interface=Paym ent,
WSDL=MyWebService.wsdl,
Operation=validate,
BusinessService=MyWebService}
CreditCard
card : CreditCard
Payment
+validate()
validateResponse : boolean
<<Busines s Service>>
MyWebService
input3 : type5
<<WebService>>
Activity3
output3 : type6
WSDL package, and the tagged values BusinessService, Interface and
Operation provide a unique reference
to the operation. The names of these
tagged values refer to UML elements
in the reverse-engineered UML
model, and are equal to names given
in the corresponding WSDL file.
The example in Figure 4 underlines the need to reverse-engineer
web services so that their elements
are available in the UML environment. The alternative is for the UML
modeler to look into the WSDL files
through an XML viewer and manually create the necessary UML models.
This kind of workflow modeling
is further elaborated in e.g. (Dumas &
Hofstede, 2001; Grønmo & Solheim,
2004; Thöne et al., 2002).
WSDL3
FROM WSDL TO UML
The previous section identified
the need to import the WSDL files
into the UML environment when creating composite web services. We
have defined and implemented conversion rules from WSDL to UML to
automate this import process. We will
investigate how to produce UML
from WSDL by looking at an example web service with WSDL representation. The well-known web
search engine Google provides a web
service that allows developers to use
services related to web searching.
This section identifies two approaches to modeling the WSDL content within UML: WSDL-dependent
and WSDL-independent interface
modeling. These two approaches are
here applied to the Google web ser-
Figure 5. WSDL-dependent UML Model of Google Service
<<wsdl:portType>>
GoogleSearchPortType
+doGetCachedPage( doGetCachedPage : doGetCachedPage ) : doGetCachedPageResponse
+doGoogleSearch( doGoogleSearch : doGoogleSearch ) : doGoogleSearchResponse
+doSpellingSuggestion( doSpellingSuggestion : doSpellingSuggestion ) : doSpellingSuggestionResponse
<<wsdl:port>>
GoogleSearchPort
{URI=http://api.google.com/search/beta2}
<<wsdl:service>>
GoogleSearchService
<<wsdl:message>>
doGetCachedPage
<<wsdl:message>>
doGetCachedPageResponse
-key : string
-url : string
-return : base64Binary
<<wsdl:message>>
doSpellingSuggestion
<<wsdl:message>>
doSpellingSuggestionResponse
-key : string
-phrase : string
-return : string
1
-binding
<<wsdl:binding>>
GoogleSearchBinding
{binding=soap:binding,
style=rpc,
transport=http://schemas.xmlsoap.org/soap/http}
<<wsdl:message>>
doGoogleSearch
<<wsdl:message>>
doGoogleSearchResponse
-filter : boolean
-ie : string
-key : string
-lr : string
-maxResults : int
-oe : string
-q : string
-restrict : strict
-safeSearch : boolean
-start : int
-return : GoogleSearchResult
<<xs:complexType>>
GoogleSearchResult
<<xs:complexType>>
DirectoryCategory
<<xs:complexType>>
ResultElement
-directoryCategories : DirectoryCategoryArray
-documentFiltering : boolean
-endIndex : int
-estimatedTotalResultsCount : int
-estimateIsExact : boolean
-resultElements : resultElementArray
-searchComments : string
-searchQuery : string
-searchTime : double
-searchTips : string
-startIndex : int
-fullViewableName : string
-specialEncoding : string
-cachedSize : string
-directoryCategory : DirectoryCategory
-directoryTitle : string
-hostName : string
-relatedInformationPresent : boolean
-snippet : string
-summary : string
-title : string
-URL : string
vice so that one can compare the results.
A closer look into a WSDLoriented UML profile (Provost, 2003)
shows how UML extension mechanisms may be used to define:
• stereotypes for the specific
WSDL and XML Schema types
such as <<wsdl:portType>>,
<<wsdl:service>>
and
<<xs:complexType>>; and
• tagged values for representing
bindings, access URLs, etc. (Note
that Provost suggests that the
binding information may be left
out at the modeling level.)
According to this profile, a web service should be modeled using the
specified UML stereotypes and
tagged values, resulting in a WSDLdependent model. Figure 5 shows a
WSDL-dependent UML model of the
Google service. The GoogleSearchService represents the web service. It
contains a GoogleSearchPort with
access URL, which in turn refers to
the concrete binding represented by
GoogleSearchBinding.
GoogleSearchBinding defines the transport
protocol to be used with its associated
tagged values (binding, style and
transport) and realizes the GoogleSearchPortType. The GoogleSearchPortType defines the three available
operations. Note that each of these
operations has exactly one input parameter and one output parameter that
directly reflect the WSDL programming model of sending an input message and receiving an output message
as answer. To retrieve the actual details of these messages, it is necessary
to look at the <<wsdl:message>>
stereotyped classes.
The Google service has been remodeled according to the WSDLindependent approach advocated in
this paper. The result is presented in
Figure 6, which is thus an instance of
the metamodel presented in Figure 2.
The UML model in Figure 6 is obviously much simpler than the one in
Figure 5. For the comprehension, it is
a major improvement that the operation signatures now reflect the logical
input and output parameters. The operation doGoogleSearch retrieves a
complete array of results based on a
query string and a set of other configuration parameters. The operation
doGetCachedPage retrieves a cached
web page for a given URL as input.
The last operation, doSpellingSuggestion, provides spelling aid given a
phrase string. Furthermore, no
WSDL or XML Schema stereotypes
have been included, and the information about the access URLs, bindings
and transport protocols are not part of
the model.
We conclude this section by
briefly explaining the main conver-
sion rules for transforming a WSDL
file into WSDL-independent UML. A
WSDL service is converted to a BusinessService. Each WSDL port within
service is converted to a realize relationship of the BusinessService. Each
portType is converted to a UML interface. Finally, all XML Schema defined types in the WSDL file are converted to UML classes.
FROM UML TO WSDL
This section presents conversion
rules from WSDL-independent UML
models to WSDL documents. The
WSDL-independent UML models do
not contain any information about
binding, transport protocol and access
URLs. In order to produce complete
WSDL files, these additional details
are added. The user configures the
proper choices within an XML configuration file. The user may choose
between SOAP RPC, HTTP Get and
HTTP Post as the binding transport
protocol.
The conversion rules are explained by an example. Figure 7 revisits MyWebService that is modeled
Figure 6. WSDL-independent UML Model of Google Service
GoogleSearchPort
+doGetCachedPage( key : string, url : string ) : base64Binary
+doGoogleSearch( key : string, q : string, start : int, maxResults : int, filter : boolean, restrict : string, safeSearch : boolean, lr : string, ie : string, oe : string ) : GoogleSearchResult
+doSpellingSuggestion( key : string, phrase : string ) : string
GoogleSearchResult
-directoryCategories : DirectoryCategoryArray
-documentFiltering : boolean
-endIndex : int
-estimatedTotalResultsCount : int
-estimateIsExact : boolean
-resultElements : ResultElementArray
-searchComments : string
-searchQuery : string
-searchTime : double
-searchTips : string
-startIndex : int
<<BusinessService>>
GoogleSearchService
DirectoryCategory
-fullViewableName : string
-specialEncoding : string
ResultElement
-cachedSize : string
-directoryCategory : DirectoryCategory
-directoryTitle : string
-hostName : string
-relatedInformationPresent : boolean
-snippet : string
-summary : string
-title : string
-URL : string
Figure 7. Conversions from a UML Model to a WSDL Document
Interf
a ce
<types> <schema>
<complexType name="CreditCard">...
<element name="number" type="string"/>
<element name="expires" type="date"/>...
<<Interface>>
</types>
ss
BasicWFS
Cla
<message name="validateRequest">
<part name="card" type="CreditCard"/></message>...
getCapabilities()
CreditCard
<portType name="Payment">
describeFeatureType()
<operation name="validate">
number : string
getFeature()
expires : date
<input message="validateRequest"/>
<output message="validateResponse"/>
C opy
-down
</operation></portType>
Inheri
<portType name="TransactionWFS">
ta nce
<operation name="getCapabilities">...
<operation name="describeFeatureType">...
<operation name="getFeature">...
<<Interface>>
<operation name="lockFeature">...
<<Interface>>
TransactionWFS
<operation name="transaction">...
Payment
ace
rf
te
In
<binding name="PaymentSOAPBinding" type="Payment">
lockFeature()
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" ...>
validate(card : CreditCard) : boolean
transaction()
<operation name="validate">...</binding>
<binding name="TransactionWFSSOAPBinding" type="Payment">
Re
<operation name="getCapabilities">...
ali z
e
<operation name="describeFeatureType">...
<operation name="getFeature">...
<operation name="lockFeature">...
<operation name="transaction">...</binding>
ice
<service name="myWebService">
BusinessServ
<<BusinessService>>
<port name="Payment_Port”
MyWebService
binding="PaymentSOAPBinding">
<soap:address location=”..www.myWebService.com"/>...
<port name="TransactionWFS_Port”
binding="TransactionWFSSOAPBinding">…
WSDL-independently according to
the metamodel in Figure 2. The righthand side of the figure shows the corresponding WSDL document. The
WSDL document is simplified for
clarity by leaving out a few elements
and attributes as well as removing all
the XML namespace information.
MyWebService realizes a web feature
service interface (OGC, 2002) and a
payment interface. The CreditCard
class with the number and expires
attributes, corresponds to a complexType in the type section of the WSDL
file with the same name as the class,
and part elements with the same
names as the UML attributes. The
Payment interface with the validate
operation corresponds to both a
WSDL portType and a WSDL binding. The Payment portType contains
one WSDL operation for each inter-
face operation. For each portType
there must be at least one WSDL
binding with type name equal to the
portType name. Furthermore, the
binding contains one WSDL operation for each operation of the interface.
The TransactionWFS interface
provides operations for delivering
geographic data and possibly updating the data. This interface offers the
operations of the OpenGIS consortium Web Feature Service Specification (WFS) (OGC, 2002). TransactionWFS inherits three operations
from the BasicWFS interface. UML
interface inheritance results in copydown of operations in WSDL, since
WSDL does not support inheritance
of portTypes or bindings. Class inheritance (not shown in the figure) is
handled by XML Schema inheritance.
This means that in a conversion from
a WSDL document to UML, there
will not be any resulting interface inheritance. A possible improvement in
future versions of WSDL will allow
for operation inheritance by enabling
portTypes to inherit from other portTypes.
IMPLEMENTATION
In this paper we have described
conversion rules for two different
transformations, from WSDL to
UML and back. These conversions
have been implemented in the UML
model transformation tool (UMT)
(SINTEF, 2004). UMT is a general
purpose UML transformation tool
that is designed to do different kinds
of transformations: UML model to
UML model, UML model to code
and reverse-engineering of code to
UML model. These kinds of transformations are also identified by the
Object Management Groups Query
View Transformation (QVT) activity
(OMG, 2002a), that aims to establish
standards for model driven development transformations.
Figure 8 shows the high-level
process of UMT and its current support for model-driven web service
development. UMT has an open architecture based on XML Metadata
Interchange (XMI) (OMG, 2002c),
which is the de-facto standard for representation of UML. The developer
needs a UML tool that supports XMI
import or export, since XMI is used
as an input or output format in the
transformation process of UMT. Internally, UMT works with a simplified XMI, called XMI Light, which
eliminates unnecessary complexity
from the XMI representation. In future versions, XMI 2.0 may be used
as the governing representation. XMI
Light is a simplification of XMI and a
common denominator for a set of
XMI versions. Transformers that implement transformations are implemented in either XSLT or Java and
they have XMI Light as input or output depending on the kind of transformations.
XSLT has been used to implement conversions both ways between
WSDL and UML class diagrams.
UMT also has support for the conversions, one way, from UML to the
execution
languages
such
as
BPEL4WS. UMT has a graphical
user interface implemented in Java
where the developer can configure
and run the desired transformations.
Figure 8. Web Service Tool Support
Web Service Specifications
Transformers
C2
WSDL
UMT
UML model
C1
C3
Execution languages
C4
A1
XMI
obj
A3
XMI
Light
Execute
transformer
BPEL4WS
A2
WorkSco
There exist other transformers for
non-web services specifications such
as Java, and SQL. The graphical user
interface of UMT and some of its
transformers, including the web service transformers, are available at
SourceForge with a GNU Lesser open
source
license
(http://umtqvt.sourceforge.net).
EVALUATION
This section evaluates the three
main topics of this paper: The "pure
UML" approach, the WSDL-to-UML
conversion rules, and the UML-toWDSL conversion rules.
The "pure UML" approach.
The use of UML to model web service interfaces has been promoted by
others (Provost, 2003; Carlsson,
2003). However, UML profiles for
this purpose produce WSDLdependent UML models. Such models contain a number of WSDL details being irrelevant for understanding the semantics of the service.
Rather, there is a risk of getting lost
in implementation details.
On the other hand, using pure
UML for web service modeling is
very helpful to the modeler's comprehension, especially when the models
are complex. However, former attempts of WSDL-independent UML
models (Thöne et al., 2002) have not
resulted in automatic generation of
the new WSDL file. The work presented in this paper has provided tool
support all the way from the existing
WDSL files through the modeling
phase and to the automatic generation
of the new WSDL file. The generality
of pure UML models also allows for
conversion to more than one target
platform (WSDL, IDL, Java, etc.), or
to later versions of the same platform.
The conversion rules between
UML and WSDL have been implemented in the UMT tool. This has
enabled testing and practical experience of the conversion rules.
From WSDL to UML. Several
WSDL documents found on the Web
have been reverse-engineered. However, even if the generated UML
models are simple, the quality of the
models is not always good. The reason is that many WSDL documents
do not have proper element names.
Another finding is that the WSDL
documents that are generated from
Java or .NET oriented WSDL-tools
have different naming conventions.
One example is a WSDL document
where all operations have exactly one
input parameter which is always
named "parameters". This input parameter is then of a type consisting of
parts representing each actual parameter. This problem is illustrated
by an example of a UML model generated from a WSDL file provided by
CapeScience (Figure 9). The service
provides several operations, but only
one operation is showed in the figure
to illustrate the point. The getWind
operation takes an arg0 named parameter of type string as input and
produces an output which is a string.
The semantics of the input and output
is unclear. The arg0 input parameter
requires a four character international
airport code, while the output returns
a natural language string describing
the wind condition. It is obvious that
the semantics of the reversegenerated UML model is dependent
on the semantics included in the
WSDL document. Quite often there
are no semantic definitions associated
with the WSDL file, since the way to
do this has not been standardized.
Figure 9. Simplified UML Model
generated from non-informative
WSDL
Station
+getWind( arg0 : string ) : string
From UML to WSDL. Based
on a simple UML model with a class
which realizes some interface one
may quickly come up with a WSDL
document using the conversion rules.
The transport protocol and encoding
styles can be chosen at generation
time and the protocols generated
should follow recommendations of
the Web Services Interoperability Organization (WS-I, 2003). The generation tool provides a good starting
point and the resulting WSDL document can be further improved by a
few manual insertions or corrections,
e.g. by specifying necessary XML
namespaces.
CONCLUSIONS
This paper recommends developers to model web services as conceptual UML models without using
WSDL-specific constructs. Further, it
presents a two-way mapping between
a WSDL-independent interface model
in UML and the corresponding ser-
vice description in WSDL. On the
basis of practical tests, we claim that
WSDL-independent UML models are
better for understanding what a web
service does; and that WSDLindependent UML models are sufficient for forward and/or reverse engineering of web services. The findings
lead to the following conclusions:
(1) A WSDL-independent UML
model of a web service explains that
service better than a WSDLdependent model or pure WSDL does.
This because WSDL-specific UML
constructs obscure rather than clarify
the content and behavior of the web
service. On the contrary, models ignoring the WDSL-specific information contain fewer technical details
and are therefore easier to understand
for humans.
(2) WSDL-independent UML
models simplify building of web services, especially when the services
are complex. This assertion is based
on the fact that it is easier to integrate
existing web services at the abstract
level. The choice of protocols and
bindings can be left to the underlying
infrastructure.
(3) Reverse engineering of
WDSL specifications to WDSLindependent UML models works for
all kinds of services. The nature of
the transformation rules allows us to
reverse engineer any WSDL document. However, it does not always
provide semantically useful models,
due to the low semantic content of
some WSDL documents.
(4) Forward engineering (code
generation) of WDSL-independent
UML models into WSDL service de-
scriptions works for all kinds of services. The transformation rules generate valid WSDL documents based
on the choice of transport protocols
and bindings. Hence, we can in principle produce a web service specification for any UML class that has operations specified.
The recommended approach facilitates the inclusion of existing web
services into a model-driven environment. It also allows the developer
to be more efficient in interpreting
and reusing existing services in new
settings.
ENDNOTES
1. A short version of this paper
was presented at The 2004 IEEE International
Conference
on
eTechnology, e-Commerce and eService (EEE-04), Taipei, Taiwan.
2. This paper has been partially
funded by the European Union project IST-2001-37724, Adaptable and
Composable E-commerce and Geographic Information Services (ACEGIS).
REFERENCES
Carlson, D. (2003). Hypermodel
Tool, from www.ontogenics.com.
Christensen, E., Curbera, F.,
Meredith, G., & Weerawarana, S.
(2001). Web Services Description
Language (WSDL) 1.1, W3C Note,
from www.w3.org/TR/wsdl
Dumas, M., & Hofstede, A. H.
M. t. (2001). UML Activity Diagrams
as a Workflow Specification Language. Paper presented at the The
Fourth International Conference on
the Unified Modeling Language,
UML 2001, Toronto, Ontario, Canada.
Gardner, T. (2003). UML Modelling of Automated Business Processes
with a Mapping to BPEL4WS. Paper
presented at the 17th European Conference on Object-Oriented Programming (ECOOP), Darmstadt,
Germany.
Grønmo, R., & Solheim, I.
(2004). Towards Modeling Web Service Composition in UML. Paper presented at The 2nd International
Workshop on Web Services: Modeling, Architecture and Infrastructure
(WSMAI-2004), Porto, Portugal.
Kollman, R., Selonen, P.,
Stroulia, E., Systä, T., & Zundorf, A.
(2002). A Study on the Current State
of the Art in Tool-Supported UMLBased Static Reverse Engineering.
Paper presented at the Ninth Working
Conference on Reverse Engineering
(WCRE'02), Richmond, Virginia.
OGC. (2002). Web Feature Service Implementation Specification
Version 1.0.0 (OpenGIS Implementation Specification No. OGC 02-058):
Open GIS Consortium Inc.
OMG. (2002a). MOF 2.0
Query/View/Transformation
RFP,
from www.omg.org
OMG. (2002b). Object Management Group's Model Driven Architecture, from www.omg.org/mda
OMG. (2002c). XML Metadata
Interchange (XMI). www.omg.org
Provost, W. (2003). UML for
Web Services. XML.com, from
http://www.xml.com/lpt/a/ws/2003/0
8/05/uml.html.
SINTEF. (2004). UML Model
Transformation tool (UMT), from
http://umt-qvt.sourceforge.net/
Thöne, S., Depke, R., & Engels,
G. (2002). Process-Oriented, Flexible
Composition of Web Services with
UML. Paper presented at the International Workshop on Conceptual
Modeling Approaches for e-Business:
A Web Service Perspective (eCOMO
2002), Tampere, Finland.
WS-I. (2003). Web Services Interoperability Organization, from
http://www.ws-i.org/
ABOUT THE AUTHORS
Roy Grønmo has been working
as a research scientist at SINTEF
since 1998. He holds a master in
computer science from the University
of Oslo, Norway from 1995. During
his time at SINTEF, he has been involved in European and Norwegian
research and industrial projects, focusing on model-driven development,
XML-based technology, The Unified
Modeling Language and geographical information systems.
David Skogan has a Masters degree in computer science from the
Norwegian Technical University in
Trondheim and has been working as
a research scientist at SINTEF since
1994. His fields of interest are geographic information science, objectoriented modeling, interoperability
standards and web service technologies. Hi is working on a PhD at the
University of Oslo on the subject of
multi-resolution geographic information. Currently he is technical coor-
dinator of the European Union project ACE-GIS (IST-2001-37724).
Ida Solheim has been working as
a research scientist at SINTEF since
1997. She has a Master degree from
the University of Oslo (1993) in the
application of computer science to
geography. She has wide experience
in data modeling, systems development and project management, both
from IT industry and applied research. Her research interests are in
the area of data modeling, objectoriented modeling, and interoperability, mainly involving geographic information.
Jon Oldevik has been working as
a research scientist at SINTEF since
1996. He holds a master in computer
science from the University of Oslo,
Norway from 1996. During his time
at SINTEF, he has been involved in
European and Norwegian research
and industrial projects, focusing on
distributed, component-based, and
service-oriented system engineering,
methodologies, integration and interoperability, architecture analysis,
and model driven development. He
has earlier been involved in standardisation efforts towards OMG and
ISO. Currently, he is a task leader in
the European EUREKA project
‘Families’.