s-cube lp: service versioning, compatibility and evolution

www.s-cube-network.eu

S-Cube Learning Package

Service Versioning, Compatibility and Evolution

Tilburg University (Tilburg), Université Claude Bernard

Lyon (UCBL)/Université Paris Descartes (UPD)

Vasilios Andrikopoulos (Tilburg)

Learning Package Categorization

Vasilios Andrikopoulos (Tilburg) © S-Cube – 2

S-Cube

Service Evolution

Adaptation and Evolution of SBA

Service Versioning, Compatibility

and Evolution

Learning Package Overview

Problem Description

Service Versioning

Version Compatibility

Compatible Evolution

Discussion

Conclusions


Problem description

Shift happens

– Market pressure

– Restructuring/optimization

– New regulations

What is the impact of change to services and, equally importantly, to their consumers?

– Shallow changes: small-scale incremental changes that are localized to a service or are restricted to the clients of that service.

– Deep changes: these are large-scale transformational changes cascading beyond the clients of a service, possibly to entire value chains (end-to-end service networks).

Emphasis on shallow changes (deep changes require adaptation & a change-oriented service lifecycle, see [Papazoglou et al. 2011])

Related to Software Evolution and Maintenance

– Large distributed systems

– Interface/Implementation separation



Problem Description

Service Versioning



Discussion

Conclusions


Evolutionary (hi)stories


Two dimensions of Service

Versioning

– Implementation: Software

Configuration Management

– Interface (WSDL, BPEL)

Best practices for interface

versioning

– XML-based

- Namespaces

- Attributes

- Combinations

– With/without metadata (e.g.

UDDI)

Approaches on Service Interface Versioning

Versioning Methods New namespace for major

versions; Version

Identifiers (VIDs) for minor

versions

•VIDs as attributes

•VIDs in service name

•VIDs in service address

Versioning info in service

registry

•Custom version metadata

•UDDI tModel extension

Combination of the above

Versioning Strategies Multiple active versions •With deprecation strategy

•Without deprecation

strategy

One active + one to be

deprecated versions

Change Identification Model Client

Notification

Both of the above

Transparent


More info at [Andrikopoulos2010]

Namespace + VID example

<?xml version="1.0" encoding="UTF-8"?>

<definitions targetNamespace="http://autoinc.com/PurchaseOrderProcessing/2010" ...

xmlns:tns="http://autoinc.com/PurchaseOrderProcessing/2010" name="POService">

<types>

<xsd:schema>

<xsd:complexType name="PODocument" version="2.1">

<xsd:sequence>

<xsd:element name="OrderInfo" type="xsd:string"/>

<xsd:element name="DeliveryInfo" type="xsd:string" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

</types>

<message name="POMessage">

<part name="request" type="tns:PODocument"/>

</message>

...

</definitions>


Findings

Many works in the field are heavily using VIDs and XML namespaces for versioning purposes

– VIDs as attributes not directly supported by many WS-* related technologies

A change in the namespace may easily result in consumer disruption and it has to be used wisely

Versioning history is in most cases irrelevant to the service consumers and as such not directly available

Majority of approaches balance maintenance cost of multiple active versions with need for supporting multiple range of clients.

Take-away strategy: parallel active versions for major releases, minor releases to be folded into the latest (active) version


Further reading

Service versioning survey at Vasilios Andrikopoulos, “A Theory and Model for the Evolution of Software Services,” Ph.D. dissertation, Tilburg University, 2010. http://arno.uvt.nl/show.cgi?fid=107815

K. Brown and M. Ellis, “Best practices for web services versioning,” 2004 [Online] http://www.ibm.com/developerworks/webservices/library/ws-version/

J. Evdemon, “Principles of service design: Service versioning,” 2005 [Online] http://msdn.microsoft.com/en-us/library/ms954726.aspx

K. Jeriӕjrvi and J. Dubray, “Contract versioning, compatibility and composability,” 2008 [Online] http://www.infoq.com/articles/contract-versioning-comp2

P. Leitner, A. Michlmayr, F. Rosenberg, and S. Dustdar, “End-to-End versioning support for web services,” in IEEE International Conference on Services Computing, vol. 1, Jul. 2008, pp. 59-66.

R. Weinreich, T. Ziebermayr, and D. Draheim, “A versioning model for enterprise services,” in 21st International Conference on Advanced Information Networking and Applications Workshops, AINAW '07, vol. 2, 2007, pp. 570-575.


http://arno.uvt.nl/show.cgi?fid=107815

http://www.ibm.com/developerworks/webservices/library/ws-version/



http://msdn.microsoft.com/en-us/library/ms954726.aspx



http://www.infoq.com/articles/contract-versioning-comp2







Problem Description

Service Versioning



Discussion

Conclusions


*-bility: connecting the various definitions


Replaceability/

Substitutability Interoperability

Inter+Rep/Sub=Compatibility

Replaceability/

Substitutability

Adaptation

Service Compatibility Theory


Abstract Service Description of records

– Records can convey structural, behavioral and/or non-functional

information

Subtyping as a (partial) ordering relation

Forward compatibility

Backward compatibility

Full compatibility

S s

ss

S<c ¢SÛS< f ¢SÙS<b ¢S

ssSsSsSSproprof

,,

ssSsSsSSreqreqb

,,

Compatible evolution approaches


(XML) Extensibility

<xsd:complexType name=“name”>

<xsd:sequence>

<xsd:element name=“first” type=“xsd:string”/>

<xsd:element name=“last” type=“xsd:string”/>

<xsd:any namespace=“##any” processContents=“lax”

minOccurs=“0” maxOccurs=“unbounded”/>

</xsd:sequence>

</xsd:complexType

Corrective

• Adaptation/Self-adaptation

• Composition and/or Interfaces

• Adapters

• Proxies

Preventive • (Empirical) Guidelines – Best practices

(next slide)

• Incompatibility checks

Best practices for service compatibility

A set of guidelines for preserving compatibility between

versions, basically unchanged since [BrownEllis2004]:

1.Add (optional) message data types

2.Add (new) operation (and respective message data types)

3.Modify service implementation (without an effect to the

service interfaces)

Every other change (e.g. modify operation, modify message

types, add new message data types) results to incompatible

versions (!)


Further reading

K. Brown and M. Ellis, “Best practices for web services

versioning,” 2004 [Online]

http://www.ibm.com/developerworks/webservices/library/ws-

version/

K. Jeriӕjrvi and J. Dubray, “Contract versioning, compatibility

and composability,” 2008 [Online]


K. Becker, A. Lopes, D. S. Milojicic, J. Pruyne, and S. Singhal,

“Automatically determining compatibility of evolving services,”

in IEEE Conference on Web Services 2008, pp. 161-168.

V. Andrikopoulos, S. Benbernou, and M. P. Papazoglou, “On

the evolution of services,” IEEE Transactions on Software

Engineering (in pre-print), 2011.












Problem Description

Service Versioning



Discussion

Conclusions


T-shaped Changes


Interoperability

Su

bsti

tuta

bilit

y/

Rep

laceab

ilit

y

T-shaped Changes: changes that respect version compatibility

Change Set Compatibility

Guideline

T-shaped Change

Add (optional)

Message Data

Types

Add (New) Operation Yes (similar reasoning as above).

Remove Operation

Modify Operation

Modify Message

Data Types

Add Mandatory Data

Types

Remove Data Types

[Andrikopoulos et al. 2011]

Compatible Evolution Framework


ss

T-shaped changes

mod},del,add{

),(Δ

Δ

op

SsopS

SSS

i

Service Representation Meta-model

Change operators:

S<c ¢SÛS< f ¢SÙS<b ¢S

Foundation: Structural Subtyping


Records are

– Elements

– Relationships (between elements)

)property)(

,)attribute:(

,string:(

*

1

*

1,

:pr

att

namee

j,j

ii

)tymultiplici:

,relation:

string,:

,string:(),(

mul

rel

name

nameeer

t

sts

ljrpprnl

mitatattmk

enamnameee

jj

ii

1,,

1,,

lmumullrerel

eeee

eereer

ttss

tsts

),(),(

Classic Type Theory:

nn

nnmnnaaaa

,,

types)(basic

}:,,:{},:,,:{

11

1111

[L.Cardelli & P.Wegner, “On understanding types, data

abstraction and polymorphism”, ACM Computing surveys,

vol.17(4), 1985.]

Structural Subtyping example


<xsd:schema>

<xsd:complexType name="PODocument">

<xsd:sequence>


<xsd:element name="DeliveryInfo" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

<xsd:schema>


<xsd:sequence>



</xsd:sequence>

</xsd:complexType>

<xsd:schema>


<xsd:sequence>



</xsd:sequence>

</xsd:complexType>

<xsd:schema>


<xsd:sequence>



<xsd:element name="TimeStamp" type="tns:TimeStamp"/>

</xsd:sequence>

</xsd:complexType>

Behavioral & Non-functional Subtyping


Based on Behavioral

(sub)contracts [G.Castagna, N. Gesbert

and L.Padovani, “A theory of contracts for Web

services”, ACM TOPLAS, vol.31(5), 2009]

Subcontracting relation for

checking compatibility

– More interacting capabilities

Mapping from our notation to

behavioral contracts

Based on Allen’s Interval Algebra [J.F.Allen, “Maintaining knowledge about

temporal intervals”, Communications of the ACM,

vol. 26(11), 1983] as extended in [Andrikopoulos et al. 2010]

Mapping between relevant

positioning & generality/specificity

)(:)(prtprtprtprt

eeee

0),,,(

),,,(0

oi}mi,si,f,,,{op

o}m,fi,s,,,{op

,op

with...

enamname

mulANDeer

mulOReer

evaluvalueevaluvalue

evaluvalue

ee

ts

ts

asrtasrt

Behavioral Subtyping example




<pick>



<onMessage partnerLink="Client" operation="receivePO"

portType="ns:POPServicePortType" variable="PO">

<sequence>

...



<invoke name="SubmitPOAck" partnerLink="Client"

operation="receivePOCallBack"

portType="ns:POPServiceCallBackPortType"

inputVariable="POAck"/>

</sequence>

</onMessage>



<onMessage partnerLink="Client2" operation="receivePOSync"

portType="ns:POPServicePortType2" variable="PO">

<sequence>

...



<reply name="ReplyPOAck" partnerLink="Client2"

operation="receivePOSync"

portType="ns:POPServicePortType2"

variable="POAck"/>

</sequence>

</onMessage>

</pick>

<sequence>

<receive name="ReceivePO" partnerLink="Client"

operation="receivePO"

portType="ns:POPServicePortType"

variable="PO" createInstance="yes"/>



...

<invoke name="SubmitPOAck" partnerLink="Client"

operation="receivePOCallBack"

portType="ns:POPServiceCallBackPortType"

inputVariable="POAck"/>

</sequence>

Non-functional Subtyping example


Dimension Value

Availability Average 92%

Latency Between 0.15 and

0.3 seconds

Reliability Minimum 90%

Authentication HMAC-SHA1

Data Encryption Base64Binary

Dimension Value

Availability Average 92%

Latency Between 0.075

and 0.15 seconds

Reliability Minimum 81%

Authentication HMAC-SHA1

Data Encryption Base64Binary

Qos Dimensions taken from the S-Cube Quality

Reference Model [Deliverable CD-JRA-1.3.2 “Quality

reference model for SBA, 2008].


Problem Description

Service Versioning



Discussion

Conclusions


Discussion

Existing standards, related work and best practices are

– Restrictive in the type of changes they allow

– Depended on particular technologies

– Limited beyond WSDL

Compatible evolution framework offers:

– A uniform model for the representation of structural, behavioral and QoS-related aspects of services

– A strong typing system on this representation model for reasoning on service compatibility

– A versioning approach that complements the previous theoretical aspects

In order to be realized the framework requires:

– Stronger coupling between different service description standards (WSDL, BPEL, WS-Policy)

– Stronger typing system in messaging processing; transition to a marshalling to object and check for compatibility on object level model from the current schema validation one

– Version identifiers should be understood on a lower level in service interactions (in order to allow for minor/major version disambiguation)



Problem Description

Service Versioning



Discussion

Conclusions


Conclusion

Service evolution may have implications for service consumers and as such it has to be carefully controlled

Service versioning is (easily) achieved by building on XML features (namespaces, attributes) but requires improvement

Version compatibility is either handled by best practices or by adaptation/adapted generation

We propose a formal service compatibility theory, based on an updated take of type theory, and…

…we build a compatible service evolution framework that

– Allows the formal definition of T-shaped (compatibility-preserving) changes

– Offers more evolutionary options than existing best practices

– Requires changes in the underlying technologies


References

Vasilios Andrikopoulos, Salima Benbernou, Michael P.

Papazoglou, “Managing the Evolution of Service

Specifications,” CAiSE 2008, pp. 359-374, 2008.

Vasilios Andrikopoulos, “A Theory and Model for the Evolution

of Software Services,” Ph.D. dissertation, Tilburg University,

2010.

Michael P. Papazoglou, Vasilios Andrikopoulos, Salima

Benbernou, “Managing Evolving Services,” IEEE Software

28(3), pp. 49-55, 2011.

Vasilios Andrikopoulos, Salima Benbernou, Michael P.

Papazoglou, “On The Evolution of Services,” IEEE

Transactions on Software Engineering, (in pre-print), 2011.


Acknowledgements

The research leading to these results has

received funding from the European

Community’s Seventh Framework

Programme [FP7/2007-2013] under grant

agreement 215483 (S-Cube).

s-cube lp: service versioning, compatibility and evolution

Technology