RESOLVING INCOMPATIBILITY DURING THE EVOLUTION OF

WEB SERVICES WITH MESSAGE CONVERSION

Vadym Borovskiy, Alexander Zeier

Hasso-Plattner-Institut, Potsdam, Germany

Jan Karstens, Heinz Ulrich Roggenkemper

Business Process Renovation, SAP AG, Walldorf, Germany

Keywords:

Incompatibility resolution, message conversion, change management, web service evolution.

Abstract:

One of the challenges that Web service providers face is service evolution management. In general, the

challenge is to ensure the substitutability of service versions, i.e. correct functioning of all ongoing client

applications relying on the old version of a service after the version has been substituted with a new one.

Unfortunately, no currently available design approach can guarantee a perfectly extensible architecture that

preserves full backward compatibility during its evolution. Hence, incompatibilities are very likely to occur

if an old version of a service is replaced with a new one. This paper addresses the incompatibility problem

and describes a solution to the problem. This solution is based upon the already known design pattern of mes-

sage translation and the ASP.NET 2.0 Web service platform. Using the platform’s API the standard ASP.NET

pipeline has been augmented with an additional step of applying XSL transformations to the XML payload of

the messages. The solution is then veriﬁed against the Electronic Commerce Service from Amazon.com web

services suite. Thus, the contribution of the work is a new .NET implementation of the translator pattern.

1 INTRODUCTION

Nowadays software systems are expected to share

their data and functionality. Achieving this level of

interoperability has required creating custom compo-

nents to bridge incompatible systems. The main rea-

son of the failure to create truly interoperable systems

has been having lots of competitive proprietary pro-

tocols based on individual goals instead of a single

widely accepted standard (Hall Gailey, 2004). The

emergence of Web services (WS) promises to intro-

duce such a standard. Based on platform neutral pro-

tocols, WS achieve interoperability at lower cost.

When considering the time factor, WS, however,

don’t differ from other technologies and show vul-

nerability with regards to change management (CM).

The lack of CM techniques results in the inconsistent

evolution of a Web service, which in turn leads to in-

compatibility between different versions of the same

service. In the short run resolving only the latter prob-

lem is sufﬁcient, but in the long run a service provider

must ﬁnd a solution to the former problem and im-

prove the substitutability of versions of a service.

In this paper the incompatibility problem is ad-

dressed and a possible solution to the problem is pre-

sented. Section 2 delves into the nature of the incom-

patibility problem with regards to WS and builds the

foundation for solving the problem. Section 3 advo-

cates message conversion as a solution to the problem

and contributes to already known work with a new

way of implementing the translator pattern using the

.NET environment. The section also presents a proto-

type that demonstrates the solution in work with a real

world Web service. Section 4 discusses the related

work. Section 5 concludes the article and outlines the

future direction of the research.

2 INCOMPATIBILITY PROBLEM

2.1 Problem Description

To consume a Web service a client application per-

forms a number of necessary steps. Firstly, the client

must locate the service. Secondly, the client must ob-

152

Borovskiy V., Zeier A., Karstens J. and Ulrich Roggenkemper H. (2008).

RESOLVING INCOMPATIBILITY DURING THE EVOLUTION OF WEB SERVICES WITH MESSAGE CONVERSION.

In Proceedings of the Third International Conference on Software and Data Technologies - SE/GSDCA/MUSE, pages 152-158

DOI: 10.5220/0001880101520158

 SciTePress

Figure 1: A client consumes a service.

Figure 2: Incompatible interface.

tain a WS description, that is a communication con-

tract that speciﬁes the available functionality of the

service and how to invoke the functionality. Thirdly,

the client must build a proxy from the WS description

and integrate the one into their system. The proxy

creates an illusion of seamless integration between

the client’s system and the remote service. Thus the

client’s application consumes the interface the service

provides (see Figure 1).

Over time a Web service may change, which will

cause its description to change as well. In this situa-

tion new clients developed from scratch will not ex-

perience any incompatibility. However, older clients

designed for the previous version of the service might

face an incompatible interface and fail to interact with

the new version of the service (see Figure 2).

2.2 Roots of Incompatibility

Messaging is the core of communication mechanism

of WS. It is based on open standards (XML, SOAP

and HTTP) and decouples Web services from their

clients (Dahan, 2006). To access a service clients

need only the address of the service and the XML

schemas of request and response messages. This in-

formation forms the description of a service and is

included in a .wsdl ﬁle that is published on the Web.

The description is used to generate a proxy via which

the clients will interact with the service.

The fact that a .wsdl ﬁle includes the description

of messages to be exchanged with the service, means

that a client must comply with communication rules

of a service. Such a requirement in turn creates a

dependency between the implementation of the client

and the description of the service. Because of this de-

pendency the client becomes sensitive to the changes

to the WS description. If a change to the description

occurs, the client may not be able to interact with the

service any longer. The reason for this possible failure

is that the client will produce messages according to

the older version of the communication contract. The

signature of operation calls deserialized from these

messages will not match the signature of service’s op-

erations. Thus, the roots of the incompatibility prob-

lem are on the message level of WS.

2.3 Classiﬁcation of Changes

Changes of a WS description result in changes of the

messages that a service expects and sends. The un-

derstanding of the changes and the way they affect

communication will deﬁnitely help to ﬁnd a solution

to the incompatibility problem. The ﬁrst step in the

analysis of possible changes is to outline all relevant

parts of a WS description. The second step is to un-

derstand how each of the parts can change.

2.3.1 Content of Web Service Description

WSDL is an XML-based language that is used to de-

ﬁne a Web service and the mechanisms to access it.

WSDL deﬁnes a service in two parts: abstract and

concrete. The abstract part describes the interface to

the service without any details about how to access the

service and includes three elements: portType, mes-

sage and types. The concrete part builds upon the

abstract part to add protocol-speciﬁc details and de-

scribe how to access the Web service. The concrete

part includes two elements service and binding.

<types>

<xs:schema>

<xs:element name="Request">

.......

</xs:element>

<xs:element name="Response">

.......

</xs:element>

</xs:schema>

</types>

</message>

</message>

</operation>

</portType>

<binding name="EcsBinding"

type="tns:EcsPortType">

<soap:binding style="document"

transport="http://..../soap/http"/>

.......

</operation>

</binding>

<port name="EcsPort"

binding="tns:EcsBinding">

<soap:address location="http://..../>

</port>

RESOLVING INCOMPATIBILITY DURING THE EVOLUTION OF WEB SERVICES WITH MESSAGE

CONVERSION

153

</service>

</definitions>

The listing above shows all ﬁrst-level elements

that

are related to the ItemSearch operation of the Ama-

zon Electronic Commerce Service 4.0

. From the list-

ing one can see that to invoke the ItemSearch opera-

tion RequestMsg message must be sent to the service

(see portType element). The message protocol must

be SOAP and the transport must be HTTP (see bind-

ing element). The message must contain at least one

part that consists of an element of Request type. Re-

quest is a self-deﬁned type and described inside types

element. If ItemSearch operation completes success-

fully the result will be sent back to the client inside

ResponseMsg message. The payload of the message

is deﬁned by Response element.

2.3.2 Changes of Web Service Description

Both parts of a .wsdl ﬁle can change over time. This

subsection presents the analysis of possible changes

of WS description and their effect on communication

between a service and its client.

The change of the service element implies the

change of endpoints to which messages are sent. The

change affects neither the contents nor the format of

messages. Storing endpoints in a conﬁguration ﬁle

will help to safeguard clients from this kind of change.

A change of the binding element implies changing

either message protocol (SOAP, HTTP-POST, HTTP-

GET, etc.) or parameter encoding if SOAP over

HTTP is chosen. Such a change alters the structure

of the messages, but their content stays the same.

The portType element deﬁnes the signature of

each operation of the Web service. This part of the

description is most likely to change over time. The

change might happen to either the name of an opera-

tion or the message attribute of the input/output ele-

ments of an operation. Changing the attribute means

that another message will be used to communicate

with the service. In addition existing operations may

be removed and new ones added.

A change of the message element means either

changing the type or element that is referenced by any

of the message parts or adding/removing a message

part. In practice most messages consist of one part,

therefore the second type of change is rare.

The last element to consider is types. The element

includes the deﬁnitions of data types used in mes-

For the ease of reading and comprehending all names-

pace attributes and URLs have been omitted.

ItemSearch operation searches the Amazon.com prod-

uct catalog for items that meet a user-speciﬁed criterion

(e.g. have certain title, manufacturer, etc.).

sages. This element represents the payload of mes-

sages. The types element is very likely to change:

new type deﬁnitions can be added and existing ones

can be removed or altered. A change of the types el-

ement most probably implies the semantic change of

message payload.

Generally speaking, a change of the abstract part

implies a change of service’s functionality, whereas a

change of the concrete part alters the way this func-

tionality is invoked. If changing the interface or im-

plementation of a service breaks ongoing client ap-

plications the new version of the service should be

created (Lublinsky, 2007). The most notable version-

ing approaches for WS are described in (Lublinsky,

2007). According to Lublinsky versioning may take

place at three levels: message level, method level and

service level. On the message level versioning is ap-

plied by placing message elements in a unique names-

pace that is related to the speciﬁc version of a service.

This is done by appending a version identiﬁer or a

date stamp to the namespace attribute of message el-

ements. On the method and service levels versioning

is applied by assigning different endpoints to the ver-

sions of a method and a service respectively.

3 MESSAGE CONVERSION

3.1 The Approach

Web services use XML to represent messages ﬂow-

ing between a service and its clients. A client con-

structs a message encapsulating a function call and

sends the message to the service. The service pro-

cesses the message and constructs an output message

if required and sends the message to back to the client.

An important detail is that after request and response

messages have been sent, they become independent

of the client and the service. As shown in the subsec-

tion 2.2 the reason of incompatibility is the discrep-

ancy between the service’s and the client’s commu-

nication protocols resulted in incompatible messages.

To reconcile this incompatibility message conversion

can be used. The main idea of the solution is to trans-

form XML messages using XSL transformation be-

fore they reach their destination. Figure 3 shows how

the solution ﬁts into the existing interaction process.

Note that there is no necessity to use converters on

the service and the client sides for each communica-

tion direction at the same time.

The solution is based on the translator pattern

that in turn derives from the pipes-and-ﬁlters pattern

(Hohpe and Woolf, 2004). In their work Hohpe and

Woolf introduced the translator as a part of messag-

ICSOFT 2008 - International Conference on Software and Data Technologies

154

Figure 3: Message conversion.

ing system, that acts as an external entity intervening

in communication process between different compo-

nents. Hence, the translator stands out of WS in-

frastructure. With the advent of new technologies

the message translator can be implemented more ef-

ﬁciently by means of closer integration into the com-

munication process between a service and its client.

In its essence the current approach takes an advantage

of new technology, ASP.NET 2.0, and suggests a new

way of including message conversion into WS infras-

tructure.

To successfully use the approach one requirement

must be met. The semantic relationships between

the payload of messages addressed to different ser-

vice versions must be discoverable. Therefore, the

approach assumes that the business logic of the older

version is not removed but substituted, meaning that

the old functionality stays essentially the same, but

is offered in a new way. An important consequence

of the assumption is that by using message conver-

sion any incompatibility resulting from a change of

the concrete part of a WS description (i.e. the bind-

ing and the service elements) can be resolved if the

abstract part of the description stays the same.

To use the approach in practice two tasks must be

done. The ﬁrst one is to create a converter and plug in

the one into the existing application. The second task

is to develop message transformation scripts in XSLT.

A solution to the ﬁrst challenge largely depends on the

concrete situation and ﬁrst of all the implementation

technology used to develop the client and the service.

The main factors here are the accessibility and exten-

sibility of message processing of the WS implemen-

tation for a given technology. The second challenge

is about understanding and discovering semantic re-

lationships between the messages of different formats

and creating XSLT scripts out of the relationships.

3.2 Implementing Converter with .NET

To demonstrate the approach described in this article

Microsoft .NET platform was chosen. The main rea-

son for the choice was the very ﬂexible customization

API that .NET provides. The API allows for build-

ing custom extensions on top of the existing ASP.NET

development stack (Esposito, 2006). The extensions

are plugged in to the ASP.NET pipeline, which is re-

sponsible for handling Web service requests and re-

sponses. At a certain stage of the processing

the cus-

tom extension is invoked to perform a user-deﬁned

operation on the message (in this case conversion).

Using a .NET development kit an application was

built. Powered by Amazon.com ECS 3.0

, the appli-

cation implements keyword search against the book

catalog of Amazon.com. To simulate the evolution

of the service all requests composed by the applica-

tion were redirected to the newer version of the ser-

vice, by changing service endpoint. ECS 4.0 is not

backwards compatible with ECS 3.0, meaning that

the fourth version cannot process requests addressed

to the third version and the clients of ECS 3.0 can-

not handle responses coming from ECS 4.0. Hence,

simply changing the endpoint URL would not work.

On the other hand the functionality of ECS 3.0 is

present in ECS 4.0, but provided in a different way.

Therefore, to reconcile the incompatibility between

the old client and the new version of the service mes-

sage conversion was used. There were two steps in

implementing the conversion. The ﬁrst one was to de-

velop the converter itself and the second was to plug

in the converter to .NET infrastructure.

Creating a converter is a simple task when us-

ing .NET. The platform provides a powerful API for

working with XML and XSLT. Using the API the con-

verter loads source XML and XSL transformation to

memory and then produces result XML by applying

the XSL transformation to the source XML.

To plug in the converter to ASP.NET pipeline

SOAP extension technology was used. A SOAP ex-

tension embodying the converter was built as a sepa-

rate DLL and is completely independent of the client

application. To deploy and invoke the SOAP ex-

tension to perform the conversion the DLL must be

copied to the client’s installation directory and regis-

.NET can invoke an extension at the four following pro-

cessing stages: before deserialization, after deserialization,

before serialization and after serialization.

Electronic Commerce Service 3.0 was formerly known

as the Amazon Web Service. For details on E-Commerce

Service see http://aws.amazon.com.

RESOLVING INCOMPATIBILITY DURING THE EVOLUTION OF WEB SERVICES WITH MESSAGE

CONVERSION

155

tered with the help of a conﬁguration ﬁle. No change

of the client application code is needed!

The solution required two converters: one for re-

quest and the other for response conversion. Both

converters were essentially the same. The only differ-

ence between them is the stage of message processing

at which they are invoked. The request converter is

invoked at after serialize stage and the response con-

verter at before deserialize stage. Since the service-

side processing chain is not accessible, the two con-

verters were plugged in to the client side.

The biggest advantage of the SOAP extension

technology of .NET is that the client stays unchanged,

which is very important for complex applications be-

cause of high costs of retesting and redebugging.

With SOAP extensions .NET infrastructure’s behav-

ior is changed, but not the application’s behavior.

3.3 Generation of Transformation

Scripts

Message conversion approach described above re-

quires a developer to create XSLT scripts that deﬁne

how incompatible messages must be brought to cor-

respondence with a new communication contract. To

create XSLT scripts correspondences between source

and target message schemas must be found. This op-

eration is knows as schema mapping. Mapping can

be speciﬁed by a domain expert or by an automated

schema matching algorithm. Manual matching even

supported by a graphical user interface is a tedious,

time-consuming and error-prone process (Rahm and

Bernstein, 2001). On the other hand automated al-

gorithms do not perform well in all situations and

may produce incorrect mappings. Although there are

many algorithms, none of them produces fully reli-

able results (Legler and Naumann, 2007). A combi-

nation of the both approaches, i.e. manual matching

supported by automated algorithms, represents a rea-

sonable trade-off (Bernstein et al., 2006).

Once mappings have been found, they must be in-

terpreted as data transformation in terms of XSLT lan-

guage. During this step developers can be supported

by a wide range of software products that create XSLT

script for a given mapping, e.g. Altova Map-Force,

BEA WebLogic Workshop, IBM WebSphere, Stylus

Studio, and Microsoft BizTalk Mapper.

3.4 Achieved Results

This subsection presents the results achieved with the

help of the developed prototype. As described in the

Section 3.2 the main responsibility of the application

was to convert messages from ECS 3.0 to ECS 4.0

format and vice versa.

The listing below shows a request message

in-

voking the KeywordSearchRequest operation of ECS

3.0. In response to this message the service would

send all books with speciﬁed keyword in their title.

<Body>

</KeywordSearchRequest>

<KeywordRequest id="id1"

type="KeywordRequest">

<mode type="string">books</mode>

</KeywordRequest>

</Body>

The newer service version expects different mes-

sages to invoke the same functionality. ECS 4.0 re-

quest messages differ in both structure and content.

Here is an example of a valid ECS 4.0 request mes-

sage that gets back the same information.

<Body>

<SearchIndex>Books</SearchIndex>

<ResponseGroup>Medium</ResponseGroup>

<ResponseGroup>Images</ResponseGroup>

</Request>

</ItemSearch>

</Body>

From the listings one can see that ECS 4.0 uses

document-literal style of formatting SOAP messages,

whereas ECS 3.0 uses document-encoding style. Due

to this fact the messages have different structure. In

ECS 3.0 the parameters are factored out from the op-

eration element. Only a reference to another element

containing the values of parameters is included in the

operation element. On the other hand ECS 4.0 mes-

sage has all parameter values embedded in the opera-

tion element. So the ﬁrst step of message conversion

is to bring ECS 3.0 message to document-literal style.

The second step is to map operation name and input

parameters. If direct mapping exists (e.g. mode cor-

responds to SearchIndex) then the value of parameter

is simply copied into the new message under another

name. If no direct mapping exists the transformation

script has to compensate the difference by inserting

appropriate parameters into the new message. The

following XSLT script does required conversion.

<key name="requestId" use="@id"

For the ease of reading namespace attributes in this and

the following XML fragments have been omitted.

ICSOFT 2008 - International Conference on Software and Data Technologies

156

match="KeywordRequest"/>

<Body>

<apply-templates

select="key(’requestId’,

substring-after(@href, ’#’))"/>

</ItemSearch>

</Body>

</Envelope>

</template>

<value-of select="keyword"/>

</Keywords>

<value-of select="mode"/>

</SearchIndex>

<ResponseGroup>Medium</ResponseGroup>

<ResponseGroup>Images</ResponseGroup>

</Request>

</template>

</stylesheet>

The response messages of ECS 3.0 and ECS 4.0

have the same structure. Therefore, only parameter

name mapping must be performed. This is done in

the same way as described above for the request mes-

sages: the value of parameter is copied into the new

message under another name.

4 RELATED WORK

In (Erlikh, 2000) Erlikh estimated that 90% of soft-

ware costs are evolution costs. The importance of the

evolution requires a systematic approach of manag-

ing an evolving software system. This is the task of

conﬁguration management discipline (Zeller, 1997).

The most frequently used approach in the area of

software evolution is versioning. Versioning is used

to distinguish different versions of components and

libraries that are simultaneously running at the same

machine (Sommerville, 2007). The way how a ver-

sion is identiﬁed and which characteristics are in-

cluded into the computation of version identiﬁer are

deﬁned by a particular versioning model (Conradi and

Westfechtel, 1998).

A number of versioning methods has been prac-

tically implemented. None of them, however, has

solved the challenge of consistent software evolution

(Stuckenholz, 2005). Moreover versioning is not the

mechanism of incompatibility resolution and does not

facilitate software substitutability. It is rather a way to

make software changes detectable in client applica-

tions. To ﬁgure out if two versions of the same com-

ponent are substitutable an approach offered in (Lobo

et al., 2005) could be used.

In contrast to versioning this article offers an ap-

proach to incompatibility resolution when the older

versions of a service are depreciated before existing

clients migrate to the newer versions of the service.

The works of Ponnekanti and Fox (Ponnekanti and

Fox, 2004), Hohpe and Woolf (Hohpe and Woolf,

2004) and Kaminski, Litoiu and Mueller (Kamin-

ski et al., 2006) address the incompatibility problem.

(Kaminski et al., 2006) suggests to pass calls of older

clients through a chain of adapters that compensates

the difference between the versions of a service in

terms of other operations available in the newer ver-

sion. This solution is more powerful than message

conversion, but is limited to the service side and might

result in a serious performance hit in case of long

chain. (Ponnekanti and Fox, 2004) suggests a sim-

ilar technique that reconciles incompatibility inside

a client-side proxy. Instead of a standard proxy a

”smart” proxy that bridges the gap between the older

client and the newer version must be used. The ap-

proach is limited to the client side and requires chang-

ing the older application. (Hohpe and Woolf, 2004)

presents message conversion as a pattern of enterprise

integration. The work is fairly abstract without any

implementation guidance.

From the business protocol standpoint the evo-

lution of a Web service is described in (Ryu et al.,

2007). The article suggests an approach to man-

age the protocol instances running according to the

old protocol version. Firstly, a protocol manager se-

lects the active instances that can migrate to the new

protocol. This is done by analyzing the protocol it-

self (static analysis) and each individual instance of

the protocol (dynamic analysis). All migrateable in-

stances can be safely switched to the newer protocol

version. Secondly, for non-migrateable instances an

adapter must be developed. In case developing the

adapter is not feasible an individual temporary proto-

col must be introduced to the instance to meet new re-

quirements without cancelling the ongoing instance.

Hence, none of the compared approaches is able to

guarantee seamless evolution of software and a Web

service in particular. Some of the approaches can help

to detect and mitigate incompatibility.

5 CONCLUSIONS

Due to platform-neutral nature based on open stan-

dards WS have gained high number of supporters.

However, along with beneﬁts WS pose some chal-

lenges. One of them is the challenge of change man-

RESOLVING INCOMPATIBILITY DURING THE EVOLUTION OF WEB SERVICES WITH MESSAGE

CONVERSION

157

agement. The lack of techniques in this area results

in incompatibility between different versions of the

same service. Resolving this incompatibility is suf-

ﬁcient in the short run. In the long run a service

provider must develop methods of ensuring the sub-

stitutability of different service versions.

This article focused on the short run problem of

resolving incompatibility between different versions

of the same service. To ﬁnd a solution the roots of

the problem were investigated. Different types of

changes that can result in backward incompatibility

during the evolution of a Web service were discussed.

If incompatible changes happen, message conversion

can be applied. This solution is based on the translator

pattern described in (Hohpe and Woolf, 2004). The

current work contributes to already known knowledge

with a new practical implementation of the translator

pattern on the .NET platform. The major challenges

and limitations of the approach were outlined. With

the help of a .NET prototype the results of the re-

search were checked against the last two versions of

E-Commerce Service from the Amazon Web services

suite. The future work of the research shall concen-

trate on developing design techniques to guarantee the

substitutability of different versions of a Web service.

REFERENCES

Bernstein, P. A., Melnik, S., and Churchill, J. E. (2006). In-

cremental schema matching. In Proceedings of the

32nd International Conference on Very Large Data

Bases, pages 1167–1170.

Conradi, R. and Westfechtel, B. (1998). Version models for

software conﬁguration management. ACM Computing

Surveys, 30(2):232–282.

Dahan, U. (2006). Autonomous services and enterprise en-

tity aggregation. The Architecture Journal, (8):10–15.

Erlikh, L. (2000). Leveraging legacy system dollars for e-

business. IT Professional, 2(3):17–23.

Esposito, D. (2006). Programming Microsoft ASP.NET 2.0

Applications: Advanced Topics. Microsoft Press.

Hall Gailey, J. (2004). Understanding Web Services Speci-

ﬁcations and the WSE. Microsoft Press.

Hohpe, G. and Woolf, B. (2004). Enterprise Integration

Patterns: Designing, Building, and Deploying Mes-

saging Solutions. Addison-Wesley.

Kaminski, P., Litoiu, M., and Mller, H. (2006). A design

technique for evolving web services. In Proceedings

of the 2006 Conference of the Center for Advanced

Studies on Collaborative Research.

Legler, F. and Naumann, F. (2007). A classiﬁcation of

schema mappings and analysis of mapping tools. In

12. GI-Fachtagung fr Datenbanksysteme in Business,

Technologie und Web, pages 449–464.

Lobo, A. E., Guerra, P., Filho, F. C., and Rubira, C. (2005).

A systematic approach for the evolution of reusable

software components. In ECOOP’2005 Workshop

on Architecture-Centric Evolution (Glasgow, UK, 25-

29th July 2005).

Lublinsky, B. (2007). Versioning in soa. The Architecture

Journal, pages 36 – 41.

Ponnekanti, S. R. and Fox, A. (2004). Interoperabil-

ity among independently evolving web services. In

Proceedings of the 5th ACM/IFIP/USENIX Interna-

tional Conference on Middleware (Toronto, Ontario,

Canada, Oct. 18-22, 2004), volume 78, pages 331 –

351.

Rahm, E. and Bernstein, P. A. (2001). A survey of ap-

proaches to automatic schema matching. The Inter-

national Journal on Very Large Data Bases, 10:334–

350.

Ryu, S. H., Saint-Paul, R., Benatallah, B., and Casati, F.

(2007). A framework for managing the evolution of

business protocols in web services. In Proceedings of

the 4th Asia-Paciﬁc Conference on Comceptual Mod-

elling, volume 67, pages 49 – 59.

Sommerville, I. (2007). Software Engineering. Addison-

Wesley, 8 edition.

Stuckenholz, A. (2005). Component evolution and version-

ing state of the art. ACM SIGSOFT Software Engi-

neering Notes, 30(1).

Zeller, A. (1997). Conﬁguration Management with Ver-

sion Sets - a Uniﬁed Software Versioning Model and

its Applications. PhD thesis, Technische Universitaet

Braunschweig.

ICSOFT 2008 - International Conference on Software and Data Technologies

158