S-CUBE LP: Service Versioning, Compatibility and Evolution

534
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
534
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

S-CUBE LP: Service Versioning, Compatibility and Evolution

  1. 1. S-Cube Learning Package Service Versioning, Compatibility and EvolutionTilburg University (Tilburg), Université Claude Bernard Lyon (UCBL)/Université Paris Descartes (UPD) Vasilios Andrikopoulos (Tilburg) www.s-cube-network.eu
  2. 2. Learning Package Categorization S-Cube Service Evolution Adaptation and Evolution of SBA Service Versioning, Compatibility and EvolutionVasilios Andrikopoulos (Tilburg) © S-Cube – 2
  3. 3. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 3
  4. 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 separationVasilios Andrikopoulos (Tilburg) © S-Cube – 4
  5. 5. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 5
  6. 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. 7. Approaches on Service InterfaceVersioningVersioning 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 aboveVersioning Strategies Multiple active versions •With deprecation strategy •Without deprecation strategy One active + one to be deprecated versionsChange Identification Model Client Notification Both of the above Transparent More info at [Andrikopoulos2010]Vasilios Andrikopoulos (Tilburg) © S-Cube – 7
  8. 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. 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) versionVasilios Andrikopoulos (Tilburg) © S-Cube – 9
  10. 10. Further readingService 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=107815K. 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.aspxK. Jeriӕjrvi and J. Dubray, “Contract versioning, compatibility and composability,” 2008 [Online] http://www.infoq.com/articles/contract- versioning-comp2P. 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. 11. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 11
  12. 12. *-bility: connecting the variousdefinitions Replaceability/ Interoperability Replaceability/ Substitutability Substitutability Inter+Rep/Sub= Compatibility AdaptationVasilios Andrikopoulos (Tilburg) © S-Cube – 12
  13. 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. 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 checksVasilios Andrikopoulos (Tilburg) © S-Cube – 14
  15. 15. Best practices for service compatibility A set of guidelines for preserving compatibility between versions, basically unchanged since [BrownEllis2004]:1.Add (optional) message data types2.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. 16. Further readingK. 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-comp2K. 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. 17. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 17
  18. 18. T-shaped Changes Change Set Compatibility T-shaped Change Guideline Add (optional) Message Data TypesInteroperability 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. 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 changesService Representation Meta-modelVasilios Andrikopoulos (Tilburg) © S-Cube – 19
  20. 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. 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. 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. 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. 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. 25. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 25
  26. 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. 27. Learning Package Overview Problem Description Service Versioning Version Compatibility Compatible Evolution Discussion ConclusionsVasilios Andrikopoulos (Tilburg) © S-Cube – 27
  28. 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 technologiesVasilios Andrikopoulos (Tilburg) © S-Cube – 28
  29. 29. ReferencesVasilios 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. 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).
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×