GENERIC WEB SERVICES

Extending Service Scope while Preserving Backwards Compatibility

Vadym Borovskiy, Juergen Mueller, Oleksandr Panchenko and Alexander Zeier

Hasso Plattner Institute for Software Systems Engineering, Germany

Keywords:

Generic web service, Generic interface, Web service evolution, Signature relaxation, Service extensibility,

Service compatibility.

Abstract:

In this article the challenge of extending the functionality of a Web service while guaranteeing backwards

compatibility with old client applications is addressed. The authors contribute with a new interface design

technique called ”Generic Web Services”. Using the technique service providers can extend the scope of Web

services without breaking compatibility with existing clients. The goal is achieved by applying signature relax-

ation and interface balancing techniques to a current Web service interface. Furthermore, the authors discuss

the advantages and disadvantages of generic Web services and give an example that applies the aforementioned

techniques to a Web service from SAP Enterprise Services Workplace.

1 NEED FOR FLEXIBILITY

Modern businesses operate in an ever changing envi-

ronment. Fast adaptation to the environment is there-

fore of vital importance. Since most of activities in

a company are supported by IT-systems, the prereq-

uisite of being ﬂexible holds true for the systems too.

For service-oriented systems the challenge of ﬂexibil-

ity can be interpreted in two ways: (i) ability to substi-

tute different services if they provide the same func-

tionality to allow provider independence; (ii) ability

to substitute different versions of the same service to

allow the extension of services.

The former interpretation leads to standardization

of services. Provider independence is achieved by

employing common standards during the develop-

ment of services (Krafzig et al., 2004). For this reason

SOA assumes the usage of agreed-upon open source

protocols (e.g. HTTP, SOAP, XML) (Erl, 2005). The

standardized communication and data representation

protocols signiﬁcantly lower the effort of switching

service providers. However, the effort is still con-

siderable, since different providers most likely use

different business protocols (Ryu et al., 2007). This

means that the same business entities (e.g. customer,

sales order, address) and business processes (e.g. pur-

chasing, invoicing, billing) from an application do-

main are represented differently. This in turn cre-

ates a formidable barrier to switching between ser-

vice providers. The Figure 1 illustrates the situation

of such incompatibility. A client cannot switch its

provider by simply redirecting calls to another one

because the interfaces of ChargeCreditCard Web ser-

vice offered by others are different.

To overcome this problem service providers must

adhere to not only the agreed-upon technical, but also

the business protocols. This creates the need of com-

mon business process standards. The standardization

allows trading partners to conduct electronic com-

merce in a mutually understood way - both syntac-

tically and semantically (Damodaran, 2004).

The most notable initiatives in the area of busi-

ness process standardization are shown by Roset-

taNet

, OASIS

and UN/CEFACT

. All three are

non-proﬁt consortia trying to establish common e-

business standards to facilitate the automation of

cross-organizational transactions. By involving key

industry players and stakeholders, conducting exten-

sive surveys and verifying all prospect standards in

real-life business situations the consortia specify the

business processes and associated documents for data

exchange.

The second interpretation of the ﬂexibility chal-

lenge leads to Web service evolution management.

Any successful software product inevitably goes

through a series of changes during its lifecycle

www.rosettanet.org

www.oasis-open.org

www.unece.org/cefact/

127

Borovskiy V., Müller J., Panchenko O. and Zeier A. (2009).

GENERIC WEB SERVICES - Extending Service Scope while Preserving Backwards Compatibility.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 127-132

DOI: 10.5220/0002242001270132

 SciTePress

Figure 1: Incompatible service interfaces

Figure 2: Incompatible service versions

(Brooks, 1987). Service providers must constantly

revise their portfolios in order to follow customers’

needs and add features to their services. While adding

new functionality to services, providers must ensure

that none of existing client applications faces incom-

patibilities caused by functionality updates.

In general, the challenge is to ensure the substi-

tutability 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 sub-

stituted with a new one. Because none of currently

available design methodologies guaranties preserving

backwards compatibility mismatches between Web

services and client applications will likely to happen

over the lifecycle of services (see Figure 2). Therefore

service providers must develop techniques helping to

avoid or at least minimize the problem.

In this article we concentrate on the service evolu-

tion management and aim at ﬁnding a way of extend-

ing a Web service with new functionality while pre-

serving backwards compatibility. We propose a new

concept of generic Web services (GSW). In its essence

the concept is an interface design technique that al-

lows service providers to extend the functionality of

services without breaking backwards compatibility.

The rest of the article is structured as follows. The

section 2 deﬁnes the concept of generic Web services

with the help of the notion of signature relaxation,

which is introduced in the subsection 2.1. The sub-

section 2.3 discusses the advantages and disadvan-

tages of GWS. An example of GWS is presented in

the subsection 2.2. The subsection 2.4 addresses the

challenge of deﬁning appropriate granularity level of

an interface. Related work is discussed in the section

3. The section 4 concludes the article and outlines the

future directions of the research.

1.1 What Causes Incompatibility

When two parties exchange information they mutu-

ally follow rules prescribed by their communication

protocol (Hohpe and Woolf, 2004). The more rigid

the rules the more efﬁcient the communication can be.

Each party assumes that its counterpart follows these

rules. However, many assumptions make the commu-

nication sensitive to any kind of change. Thus, in-

compatibility can be understood as a mismatch in the

assumptions communicating parties make about each

other and the common protocol.

The next question to answer is why incompatibil-

ities occur. In Web service architecture the roots of

incompatibilities can be found on the message level.

Messaging is the core of communication mechanism

in service-oriented systems (Dahan, 2006). To work

with a service client applications need only the ad-

dress of the service and the XML schema of request

and response messages. This information forms the

description of a service and is included in a WSDL

ﬁle that is published on the Web.

Successful communication assumes that the client

and the service exchange with messages of speciﬁc

content and format. This assumption in turn creates

a dependency between the client and the service. If

the assumption is broken, the communication is jeop-

ardized and incompatibilities are likely to occur. The

reason for this possible failure is that the client will

produce messages according to the older version of

the communication contract. The operation calls de-

serialized from these messages will not match the sig-

nature of the service’s operations.

In this paper we present a new concept of generic

Web services that brings service providers closer to

the solution of incompatibility problem. In its essence

the concept is an interface design technique that al-

lows service providers to extend the functionality of

Web services while ensuring backwards compatibil-

ity.

2 GENERIC WEB SERVICES

Service providers face the challenge of extending ser-

vices with new features while preserving backwards

compatibility. To avoid incompatibility a provider

should prevent changes to the interfaces of their ser-

vices. On the other hand adding new functionality

may require changing the interfaces. How to freeze

an interface and add features at the same time? To an-

swer this question we introduce the notion of generic

Web services.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

128

We deﬁne a generic Web service through the no-

tion of signature relaxation as follows: A generic Web

service is a Web service having at least one operation

with relaxed signature. Signature relaxation, in turn,

is the reduction of an operation’s signature rigidity.

In other words, the semantics of an operation with re-

laxed signature is not statically deﬁned at design time

but determined dynamically at runtime through the

values of input parameters. The next subsection ex-

plains the concept in detail.

2.1 Signature Relaxation

A Web service is a set of operations accessible via

speciﬁc end point. Each service operation is charac-

terized with a signature. A signature is a collection of

an operation’s name and two sets of types, instances

of which are accepted and returned as input and out-

put parameters respectively(Gamma et al., 1995).

By analogy with (Gamma et al., 1995) the deﬁni-

tion of a service’s interface can be derived. The set

of all signatures deﬁned by a service’s operations is

known as the interface to the service. A service’s in-

terface deﬁnes the complete set of request messages

that can be sent to the service. To identify and dis-

tinguish interfaces developers use types. A type is a

name used to denote a particular interface (Gamma

et al., 1995).

The signature of an operation is not only a syntac-

tic characteristic but also a semantic one. Semantics

of an operation can be deﬁned as the implied mean-

ing of the operation and is used to deﬁne its role

in a system. The relationship between the seman-

tic and syntactic aspects of signature comes from the

way software is developed. To simplify code compre-

hension and maintenance developers try to come up

with signatures (especially with names) that are self-

describing and easy to understand. Thus, the seman-

tics of an operation greatly inﬂuences the operation’s

signature.

The signature of an operation imposes restrictions

upon the types and values of the operation’s parame-

ters. This characteristic we will call the rigidity of an

operation’s signature. Having deﬁned the term rigid-

ity we would like to come back to the term signature

relaxation. It can be deﬁned as the loosing of signa-

ture rigidity (i.e. the loosing of restrictions that the

signature places on the types and values of parame-

ters). Thus, signature relaxation is the extension of

parameters’ connotation and the set of their possible

values.

Signature relaxation can be achieved by introduc-

ing a special sort of input parameters that will be used

to deﬁne the meaning of other parameters. In this

case the later parameters become controlled param-

eters and the former ones - controlling or identity pa-

rameters (they identify the semantics of other param-

eters).

We will call an operation with relaxed signature

a generic operation. A generic interface, in turn, is

an interface that has at least one generic operation.

A generic Web service is a service with at least one

generic operation.

The next question to answer is how one can de-

termine if a given operation is generic. A generic op-

eration can be recognized via its identity parameters.

Therefore, one should carefully examine the parame-

ters of the operation. If there is at least one parameter

that deﬁnes or extends the semantics of another, then

the operation is generic. If an operation does not have

identity parameters it is conceived to be ﬁne-grained.

2.2 Using GWS in Practice

In this section we present an example of how an in-

terface could be relaxed and transformed to a generic

one. This is demonstrated with the set of operations

that were taken from Material Management SAP ES

Workplace service interface:

1. Find Material by GTIN

2. Find Material by ID and Description

3. Find Material by Search Text

4. Find Material By Customer Information

5. Find Material by Elements

The operations perform the same kind of function-

ality. They all search the backend system for materi-

als. Each operation, however, uses different criteria.

The operation 5 has the most advanced functionality.

It supports the criteria of all other operations. The rest

of the operations perform speciﬁc search based on cri-

teria that are reﬂected in the name of a corresponding

operation.

One may conclude that the operation 5 is the most

generic and the rest operations are ﬁne-grained ones.

This, however, is not true, because the operation has

no identity parameters. As can be seen all search cri-

teria are hard coded as the operation’s input parame-

ters

Find Material by Elements (

string MaterialID,

string MaterialDescription,

string GTIN (StandardID),

string MerchandiseTypeCode,

string TypeCode,...)

Global Trade Identiﬁcation Number

Other operations follow the same principle, but have

fewer parameters.

GENERIC WEB SERVICES - Extending Service Scope while Preserving Backwards Compatibility

129

Since no operation has identity parameters, the se-

mantics of all parameters is deﬁned at design time.

Therefore, none of the operations has relaxed signa-

ture.

As will be mentioned in the subsection 2.3 such an

interface will have difﬁculties with extending func-

tionality. To support more search criteria SAP must

either add a new ﬁne-grained search operation or add

more parameters to the operation 5. In both cases

changing the signature of the interface is required.

This limitation could be overcome if the interface was

generic.

To turn this interface into a generic one we must

relax the signature of at least one operation. The best

candidate for relaxation is Find Material by Elements.

The method can be relaxed in three ways.

1. Find Material by Elements (

string attribute,

string text)

In this case the search can be performed only on a

single criterion.

2. Find Material by Elements (

string[] attribute,

string[] text)

This version of the operation searches on all at-

tributes that a client speciﬁes at runtime. All the

criteria are used with a default predicate, for ex-

ample and. A client application must guarantee

that both input arrays are of equal size, otherwise

a runtime error will be reported.

3. Find Material by Elements (

string[] attribute,

string[] text,

predicate[] predicate)

This is the most relaxed version of the suggested

ones, because every text[i] parameter is controlled

by two identity parameters attribute[i] and pred-

icate[i]. As in the previous case a client applica-

tion ensures the consistency of the input parame-

ters.

The next question is which of the three versions

to include in the interface. Of course, all of them can

be included. However, this is not necessary. We can

include only the last two versions or even only the last

one. The rest of the operations could be represented

as overloads of the selected master methods.

There is also one interesting detail to be men-

tioned. The number of input parameters of Find Ma-

terial by Elements has been reduced. Now a client ap-

plication only supplies the attributes on which search

must be performed, whereas in the non-relaxed ver-

sion all parameters must be supplied no matter if they

are used or not.

2.3 Advantages and Disadvantages of

GWS

Over time a service provider needs to add new fea-

tures to services they offer. Not always do new fea-

tures ﬁt into the existing interfaces of ﬁne-grained ser-

vices. In this situation the provider has several op-

tions.

Firstly, the provider can introduce another version

of the service being changed. In this case old clients

will continue working with the previously designed

version and will not face incompatibility. Clients will-

ing to utilize new functionality will need to work with

the new version of the service. In this scenario the ser-

vice provider will need to employ a versioning mech-

anism and maintain all versions of the service. The

disadvantage of this approach is the increase in main-

tenance costs.

Secondly, the provider can change service without

maintaining backwards compatibility. In this scenario

old clients will need to migrate to the new version

of the service. Thus, the clients will incur additional

costs.

Thirdly, the provider may introduce an adapter or

a converter that will compensate the difference be-

tween the versions of the service. This approach is

described in detail in (Kaminski et al., 2006) and

(Borovskiy et al., 2008).

If a service has generic interface adding new

features does not require changing the interface

Adding new features is supported by design via in-

troducing new values of identity parameters. An im-

portant detail is that adding a new feature does not re-

quire changing the signature of the operation. This is

exactly the value of generic interfaces. Service archi-

tects can greatly beneﬁt from the fact that a generic

operation can add functionality by simply extending

the domain

of its identity parameters. Thus, generic

interfaces allow adding new functionality while keep-

ing the signature stable and preserving backwards

compatibility.

The downside of GWS is the ambiguity of con-

trolled parameters. The more vales an identity pa-

rameter has, the greater the ambiguity of a parameter

which it controls. This can result in less understand-

able service interface.

2.4 Deﬁning Right Granularity Level

Because of the ambiguity of controlled parameters

generic Web services are more difﬁcult to use than

At least that often as in case of a ﬁne-grained service.

The set of all possible values of a parameter is called

the domain of the parameter.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

130

ﬁne-grained ones. The more generic an operation

is, the harder it is to understand its semantics at de-

sign time. Therefore service providers must balance

services’ granularity and the ease of use. This cre-

ates a dilemma: ﬂexibility versus usability. Services

must be generic enough to allow adding new features,

but not too ambiguous and confusing to service sub-

scribers.

In general, service providers can include to in-

terfaces as many operations as they want with any

granularity level each. However, this will create sev-

eral problems at the later stages of services’ lifecy-

cle. Firstly, the interface can grow. There can be

several operations that perform the same functional-

ity, but with slight difference. In such situations users

can be confused and will not know which operations

they should call. Secondly, once an operation has

been included to an interface, a service provider can-

not change (or even depreciate) it easily, since there

can be clients using it.

Thus, it is in the interests of service providers to

keep their interfaces as slim as possible. At the same

time the interfaces must be convenient to use, mean-

ing that the number of parameters must be reasonable

and the purpose of each one must be not difﬁcult to

understand.

When there are not many operations (as in the ex-

ample of the previous subsection) service architects

can decide on their own (without any formal method)

what granularity level each operation in an interface

should have. In case there is a high number of opera-

tions a formal approach is needed. Such a technique

we will call interface balancing, since it balances an

interface’s granularity level and its usability. For now

we have not found a sound formal method of deﬁn-

ing the appropriate degree of relaxation of an inter-

face. This will be one of the future directions of the

research.

3 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 from client ap-

plications. To ﬁgure out if two versions of the same

component are substitutable an approach offered in

(Lobo et al., 2005) could be used.

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 is a powerful solution, but it is limited to

the service side and might result in a serious perfor-

mance hit in case of long chain. (Ponnekanti and Fox,

2004) suggests a similar technique that reconciles in-

compatibility 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 approach is limited to the client side

and requires changing 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 the development

of an adapter is not feasible an individual temporary

protocol must be introduced to the instance to meet

new requirements without cancelling the ongoing in-

stance.

4 CONCLUSIONS

Over the lifecycle of a Web service its provider will

want to change it in order to keep the one up to date

GENERIC WEB SERVICES - Extending Service Scope while Preserving Backwards Compatibility

131

with customers’ needs. This creates a challenge of

maintaining the integrity of old client applications us-

ing the service. In case a change to a service happens

the provider must ensure backwards compatibility be-

tween the new and the old service versions.

This article contributes with the notion of generic

Web service deﬁned with the help of terms signa-

ture relaxation and identity parameter. Based on

these notions an interface design technique was sug-

gested. Using the technique service provides can de-

sign generic Web services which have more stable and

extensible APIs. In short the technique includes three

main steps: (i) Signature relaxation - a service archi-

tect ﬁnds operations that must be relaxed and relaxes

them through the introduction of appropriate iden-

tity parameters; (ii) Interface balancing - the architect

selects the minimal number of operations effectively

representing the functionality of the interface; (ii) Op-

eration overloading - the service architect can rep-

resent excluded operations as overloads of included

ones.

The biggest value of generic Web services is that

they allow for adding functionality by simply extend-

ing the domain of their identity parameters and with-

out changing the signature of operations. The down-

side of generic Web services is the ambiguity of con-

trolled parameters.

The future research will concentrate on deﬁning a

formal method of computing the granularity level of

operations. Furthermore, the theoretical results of the

research will be validated on a broader set of indus-

trial Web services.

REFERENCES

Borovskiy, V., Zeier, A., Karstens, J., and Roggenkemper,

H. U. (2008). Resolving incompatibility during the

evolution of web services with message conversion.

Brooks, F. (1987). No silver bullet - essence and accidents

of software engineering. IEEE Computer, 20(4).

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.

Damodaran, S. (2004). B2b integration over the internet

with xml - rosettanet successes and challenges. In

Proceedings of the 13th international World Wide Web

conference, pages 188 – 195.

Erl, T. (2005). Service-Oriented Architecture: Concepts,

Technology, and Design. Prentice Hall.

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

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

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. M.

(1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley.

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

Patterns: Designing, Building, and Deploying Mes-

saging Solutions. Addison-Wesley.

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

technique for evolving web services. In Proceedings

of the 2006 Conference of the Center for Advanced

Studies on Collaborative Research.

Krafzig, D., Banke, K., and Slama, D. (2004). Enterprise

SOA: Service Oriented Architecture Best Practices.

Prentice Hall.

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).

Ponnekanti, S. R. and Fox, A. (2004). Interoperability

among independently evolving web services. In Pro-

ceedings of the 5th ACM/IFIP/USENIX International

Conference on Middleware, volume 78, pages 331 –

351.

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 2009 - 4th International Conference on Software and Data Technologies

132