1. S-Cube Learning Package
Service Versioning, Compatibility and
Evolution
Tilburg University (Tilburg), Université Claude Bernard
Lyon (UCBL)/Université Paris Descartes (UPD)
Vasilios Andrikopoulos (Tilburg)
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Service Evolution
Adaptation and Evolution of SBA
Service Versioning, Compatibility
and Evolution
Vasilios Andrikopoulos (Tilburg) © S-Cube – 2

3. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 3

4. 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
Vasilios Andrikopoulos (Tilburg) © S-Cube – 4

5. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 5

6. 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)
Vasilios Andrikopoulos (Tilburg) © S-Cube – 6

7. Approaches on Service Interface
Versioning
Versioning Methods New namespace for major •VIDs as attributes
versions; Version •VIDs in service name
Identifiers (VIDs) for minor •VIDs in service address
versions
Versioning info in service •Custom version metadata
registry •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]
Vasilios Andrikopoulos (Tilburg) © S-Cube – 7

8. 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>
Vasilios Andrikopoulos (Tilburg) © S-Cube – 8

9. 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
Vasilios Andrikopoulos (Tilburg) © S-Cube – 9

10. 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.
Vasilios Andrikopoulos (Tilburg) © S-Cube – 10

11. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 11

12. *-bility: connecting the various
definitions
Replaceability/ Interoperability Replaceability/
Substitutability Substitutability
Inter+Rep/Sub=
Compatibility
Adaptation
Vasilios Andrikopoulos (Tilburg) © S-Cube – 12

13. Service Compatibility Theory
 Abstract Service Description S of records s
– Records can convey structural, behavioral and/or non-functional
information
 Subtyping as a (partial) ordering relation s  s 
 Forward compatibility S  f S    s  S pro ,  s   S pro , s   s
 Backward compatibility S  b S    s   S req ,  s  S req , s  s 

 Full compatibility S<c S¢ Û S< f S¢ ÙS<b S¢
Vasilios Andrikopoulos (Tilburg) © S-Cube – 13

14. Compatible evolution approaches
<xsd:complexType name=“name”>
<xsd:sequence>
<xsd:element name=“first” type=“xsd:string”/>
<xsd:element name=“last” type=“xsd:string”/>
(XML) Extensibility <xsd:any namespace=“##any” processContents=“lax”
minOccurs=“0” maxOccurs=“unbounded”/>
</xsd:sequence>
</xsd:complexType
• Adaptation/Self-adaptation
Corrective • Composition and/or Interfaces
• Adapters
• Proxies
• (Empirical) Guidelines – Best practices
Preventive
(next slide)
• Incompatibility checks
Vasilios Andrikopoulos (Tilburg) © S-Cube – 14

15. 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 (!)
Vasilios Andrikopoulos (Tilburg) © S-Cube – 15

16. 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]
http://www.infoq.com/articles/contract-versioning-comp2
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.
Vasilios Andrikopoulos (Tilburg) © S-Cube – 16

17. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 17

18. T-shaped Changes
Change Set Compatibility T-shaped Change
Guideline
Add (optional)
Message Data
Types
Interoperability
Add (New) Operation Yes (similar reasoning as above).
Substitutability/
Replaceability
Remove Operation
Modify Operation
Modify Message
Data Types
Add Mandatory Data
[Andrikopoulos et al. Types
2011]
Remove Data Types
T-shaped Changes: changes that respect version compatibility
Vasilios Andrikopoulos (Tilburg) © S-Cube – 18

19. Compatible Evolution Framework
Change operators:
S   S  ΔS
Δ S  op ( s i , S )
op  { add , del , mod}
s  s
S<c S¢ Û S< f S¢ ÙS<b S¢
T-shaped changes
Service Representation Meta-model
Vasilios Andrikopoulos (Tilburg) © S-Cube – 19

20. Foundation: Structural Subtyping
    
Classic Type Theory:   { a1 :  1 ,  , a n :  n  m },   { a1 :  1 ,  , a n :  n } [L.Cardelli & P.Wegner, “On
understanding types, data
    (basic types) abstraction and polymorphism”,
    ACM Computing surveys,
 1   1 ,  ,  n   n
 vol.17(4), 1985.]
 Records are
– Elements
e  ( name : string , e  e   name  nam e  
( att i , i 1 : attribute ) ,
*
k  m , att i  at t i ,1  i  m 
( pr j,j 1: property)
*
) l  n , pr j  p r j ,1  j  l
– Relationships (between elements)
r ( e s , e t )  ( name : string ,
s
r ( e s , e t )  r ( e  , e t ) 
s
name t : string,
e s  e   e t  e t 
s
rel : relation ,
rel  re l   mul  mu l 
mul : multiplici ty )
Vasilios Andrikopoulos (Tilburg) © S-Cube – 20

21. Structural Subtyping example
<xsd:schema> <xsd:schema>
<xsd:complexType name="PODocument"> <xsd:complexType name="PODocument">
<xsd:sequence>
<xsd:element name="OrderInfo"
type="xsd:string"/>
 <xsd:sequence>
<xsd:element name="OrderInfo"
type="xsd:string"/>
<xsd:element name="DeliveryInfo" <xsd:element name="DeliveryInfo"
type="xsd:string"/> type="xsd:string" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:schema> <xsd:schema>

<xsd:complexType name="PODocument"> <xsd:complexType name="PODocument">
<xsd:sequence>
<xsd:element name="OrderInfo"  <xsd:sequence>
<xsd:element name="OrderInfo"
type="xsd:string"/> type="xsd:string"/>
<xsd:element name="DeliveryInfo"
type="xsd:string" minOccurs="0"/>
</xsd:sequence>
 <xsd:element name="DeliveryInfo"
type="xsd:string" minOccurs="0"/>
<xsd:element name="TimeStamp"
</xsd:complexType> type="tns:TimeStamp"/>
</xsd:sequence>
</xsd:complexType>
Vasilios Andrikopoulos (Tilburg) © S-Cube – 21

22. Behavioral & Non-functional Subtyping
 Based on Behavioral  Based on Allen’s Interval Algebra
(sub)contracts [G.Castagna, N. Gesbert [J.F.Allen, “Maintaining knowledge about
temporal intervals”, Communications of the ACM,
and L.Padovani, “A theory of contracts for Web
services”, ACM TOPLAS, vol.31(5), 2009] vol. 26(11), 1983] as extended in
[Andrikopoulos et al. 2010]
 Subcontracting relation for
checking compatibility  Mapping between relevant
positioning & generality/specificity
– More interacting capabilities
 Mapping from our notation to e asrt  e asrt  name  nam e  

behavioral contracts ...  value  valu e  with
value  valu e   value op valu e ,
e prt  e prt   ( e prt )  :  ( e prt )
 op  {  ,  , s, fi, m, o}

 op  {  ,  , f, si, mi, oi}
0  r ( e s , e t , OR , mul )

r ( e s , e t , AND , mul )  0

Vasilios Andrikopoulos (Tilburg) © S-Cube – 22

23. Behavioral Subtyping example
<!-- Wait for input -->
<pick>
<!-- If the asynchronous operation was invoked -->
<onMessage partnerLink="Client" operation="receivePO"
portType="ns:POPServicePortType" variable="PO">
<sequence>
<sequence>
...
<receive name="ReceivePO" partnerLink="Client"
<!-- Call back the asynchronous client with the
operation="receivePO"
acknowledgement -->
portType="ns:POPServicePortType"
<invoke name="SubmitPOAck" partnerLink="Client"

variable="PO" createInstance="yes"/>
operation="receivePOCallBack"
<!-- Process the purchase order message -->
portType="ns:POPServiceCallBackPortType"
...
inputVariable="POAck"/>
</sequence>
<invoke name="SubmitPOAck" partnerLink="Client"
</onMessage>
operation="receivePOCallBack"
<!-- If the synchronous operation was invoked -->
portType="ns:POPServiceCallBackPortType"
<onMessage partnerLink="Client2" operation="receivePOSync"
inputVariable="POAck"/>
portType="ns:POPServicePortType2" variable="PO">
</sequence>
<sequence>
...
<!-- Reply to the client with the acknowledgement -->
<reply name="ReplyPOAck" partnerLink="Client2"
operation="receivePOSync"
portType="ns:POPServicePortType2"
variable="POAck"/>
</sequence>
</onMessage>
</pick>
Vasilios Andrikopoulos (Tilburg) © S-Cube – 23

24. Non-functional Subtyping example
Dimension Value Dimension Value
Availability Average 92%
 Availability Average 92%
Latency Between 0.15 and
0.3 seconds  Latency Between 0.075
and 0.15 seconds
Reliability Minimum 90%
 Reliability Minimum 81%
Authentication HMAC-SHA1
 Authentication HMAC-SHA1
Data Encryption Base64Binary
 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].
Vasilios Andrikopoulos (Tilburg) © S-Cube – 24

25. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 25

26. 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)
Vasilios Andrikopoulos (Tilburg) © S-Cube – 26

27. Learning Package Overview
 Problem Description
 Service Versioning
 Version Compatibility
 Compatible Evolution
 Discussion
 Conclusions
Vasilios Andrikopoulos (Tilburg) © S-Cube – 27

28. 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
Vasilios Andrikopoulos (Tilburg) © S-Cube – 28

29. 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.
Vasilios Andrikopoulos (Tilburg) © S-Cube – 29

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