Chain of Adapters: A Design Technique for Evolving Web Services

1
Chain of AdaptersA Design Technique for
Evolving Web Services

• Presenter
• Kamlesh Patel
• Date 04/10/2007
• Email kpatel_at_cs.odu.edu
• CS-775 Distributed Systems
• Spring 2007
• Old Dominion University

2
Chain of AdaptersA Design Technique for
Evolving Web Services

• Piotr Kaminski is a PhD student at the
  University of Victoria, where he works with Dr.
  Müllers research group on software engineering
  of autonomic systems. His research interests
  include software documentation, software
  development processes, reverse engineering,
  programming languages, and security.
• Dr. Marin Litoiu is a member of the Centre for
  Advanced Studies at the IBM Toronto Laboratory
  where he initiates and manages joint research
  projects between IBM and universities across the
  globe in the area of application development
  tools.
• Dr. Hausi Müller is a Professor in the
  Department of Computer Science and Director of
  Software Engineering Programs at the University
  of Victoria, British Columbia, Canada. Together
  with his research group and in collaboration with
  IBM, he investigates methods, models,
  architectures, and techniques for autonomic
  computing applications.

3
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.

4
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters

5
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters
• Evaluation and Tricks

6
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters
• Evaluation and Tricks
• Prototype Implementation

7
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters
• Evaluation and Tricks
• Prototype Implementation
• Performance Analysis

8
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters
• Evaluation and Tricks
• Prototype Implementation
• Performance Analysis
• References

9
Outline

• Define the problem of simultaneously deploying
  multiple versions of a web service in the face of
  independently developed unsupervised clients.
• Propose a solution in the form of a design
  technique called
• Chain of Adapters
• Evaluation and Tricks
• Prototype Implementation
• Performance Analysis
• References
• Conclusions

10
Introduction

• Version management of deployed software has
  always been a tricky business.
• (August 2001, Romin Irani, Senior Software
  Engineer, InSync Information Systems, California)

Fig. A TectERP System
11
Introduction

• Focus specifically on versioning of web services
• (Nov 2004, Russell Butek, Web Service
  Consultant, IBM)

E.g. Add address book service version 1.0
Phone
Address
addAddress
12
Introduction

• Focus specifically on versioning of web services
• (Nov 2004, Russell Butek, Web Service
  Consultant, IBM)

E.g. Add address book service version 1.0
Phone
Address
addAddress
New operation count
13
Introduction

• Focus specifically on versioning of web services
• (Nov 2004, Russell Butek, Web Service
  Consultant, IBM)

E.g. Add address book service version 1.0
Phone
Address
addAddress
New operation count
New data type businessphone
14
Introduction

• Focus specifically on versioning of web services
• (Nov 2004, Russell Butek, Web Service
  Consultant, IBM)

E.g. Add address book service version 1.0
Phone
Address
addAddress
New operation count
New data type businessphone
New, optional field in an existing data type
apptNum
15
Introduction

• Focus specifically on versioning of web services
• (Nov 2004, Russell Butek, Web Service
  Consultant, IBM)

E.g. Add address book service version 1.1
Phone
Address
addAddress
New operation count
New data type businessphone
New, optional field in an existing data type
apptNum
Type expansion phone numbers
16
Introduction

• Current Web services standards have little or no
  support for managing change. (May 2006, IBM
  Researchers)
• Versioning By Operation
• Versioning By Web Service name
• Versioning By URL
• Toggling Versions

17
Introduction

• Authors goal is to permit the evolution of a web
  services interface and implementation while
  remaining backwards-compatible with clients
  written to comply with previous versions

18
Requirements

• Backwards Compatibility
• How can we maintain it ?
• Solution

19
Requirements

• Trivial ways to satisfy is
• supporting only the most recent release of the
  web servicea tactic unlikely to please current
  customers

20
Requirements

• Trivial ways to satisfy is
• Freezing its external interface at first
  published version

21
Requirements

• Common Data Store

22
Requirements

• Common Data Store Constraint

23
Requirements

• Common Data Store Constraint
• This constraint immediately invalidates one of
  the simplest evolutionary strategies keep each
  version of a service running as-is in isolation
  as shown in figure.

24
Requirements

• No Code Duplication

25
Requirements

• No Code Duplication Constraint
• This constraint immediately invalidates Fig. 3

26
Requirements

• No Code Duplication Constraint
• This constraint immediately invalidates Fig. 3
  and Fig. 4 strategies

27
Requirements

• Untangled Versions
• Preference to encapsulation
• This helps removal of dead code as versions of
  services are withdrawn reducing complexity.
• Particularly useful in self-managing systems

28
Requirements

• Untangled Versions Constraint
• Here in lieu of saving cost, an implementation
  having interface of each version incrementally
  extending that of the preceding one, and a single
  service progressively accumulating the
  implementation of all these interfaces fails
  untangling test, requiring developer intervention
  to deprecate interface members and excise the
  corresponding implementation pieces from the
  codebase.

29
Requirements

• Unconstrained Evolution
• Evolution of the service should be unconstrained
  by past versions, as much as possible.
• The developer should be allowed to refactor,
  redesign, and otherwise rethink both the
  services interface and its implementation
  without being shackled by previous decisions.
• This gives the service the best chance of
  avoiding a slide into design debt and becoming
  legacy software.

30
Requirements

• Visible Mechanism
• Important to expose to the service developers the
  mechanism by which backwards-compatible evolution
  is achieved.
• The idea is to keep the framework simple and
  unobtrusively visible, rather than try to
  anticipate all possible scenarios with
  behind-the-scenes magic.

31
Chain of Adapters Technique

• Duplicate the interface of the web service into a
  different namespace. The resulting copy will then
  have the same members and data structures as the
  original, while having no formal relationship to
  its parent. Call this the v1 interface.
• Create an implementation of the v1 interface that
  forwards all calls to the original endpoint and
  interface, translating the namespace of any data
  structures as necessary.
• Publish and advertise the v1 interface endpoint
  as the stable first version of the web service

32
Adapter Details

• Whenever a web service is modified, a
  compensating modification is made in the adapter
  to maintain the contract of the previous (say v1)
  interface.
• Various Scenarios
• If the current interface is changed through the
  addition of a parameter to an existing operation,
  the adapter must be modified to provide a default
  value for this parameter when forwarding the
  call.
• If the definition of a data structure is changed,
  the adapter must translate from the old one to
  the new one (for in parameters) or from the new
  one to the old one (for out parameters and return
  values).
• If an operation is removed from the interface, it
  must be re-implemented in the adapter, in terms
  of the other operations available in the current
  interface.

33
Adapter Details Continued

• Whenever a web service is modified, a
  compensating modification is made in the adapter
  to maintain the contract of the previous (say v1)
  interface.
• Various Scenarios
• If the contract of an operation is changed, the
  adapter must either compensate for the difference
  or re-implement the operation according to its v1
  contract as if it had been removed.
• The adapter does not need to be modified when a
  new operation is added to the interface, nor when
  new optional members are added to a data
  structureboth will be ignored by the default
  delegation and translation processes.
• In this way, the adapter accumulates a record of
  the differences between v1 and (the upcoming) v2,
  expressed as compensating code fragments.

34
Second Version Release

• Duplicate the current interface into a separate
  namespace the copy will be v2 of the interface.

Copy
35
Second Version Release

• Duplicate the current interface into a separate
  namespace the copy will be v2 of the interface.
• Create an adapter for the v2 interface that
  delegates to the current endpoint and interface.

36
Second Version Release

• Duplicate the current interface into a separate
  namespace the copy will be v2 of the interface.
• Create an adapter for the v2 interface that
  delegates to the current endpoint and interface.
• Retarget the v1?v2 adapter to delegate to the v2
  endpoint.

37
Second Version Release

• Duplicate the current interface into a separate
  namespace the copy will be v2 of the interface.
• Create an adapter for the v2 interface that
  delegates to the current endpoint and interface.
• Retarget the v1?v2 adapter to delegate to the v2
  endpoint.
• Publish and advertise the v2 interface endpoint
  as the stable second version of the web service.

Figure 7 shows the resulting structure, with a
new pass-through v2?v3 adapter, and a slightly
fatter v1?v2 adapter.
38
n Versions Release

• Development of the web service can now continue
  towards v3, with compensating code placed into
  the v2?v3 adapter.
• The v1?v2 adapter need never be touched again,
  since all future incompatibilities will be
  compensated for by the v2?v3 and further
  downstream adapters.
• In fact, as the service grows older and the
  versions mount up, the only code that needs to be
  edited is the services current codebase and the
  most recent adapter.

39
Evaluation

• by publishing only frozen versions of the
  services interface, each at its own endpoint
  address
• In practice, it is up to the developer, backed by
  the full power of the programming language, to
  ensure that the adapters compensate appropriately
  for changes that are not backwards compatible

• Backwards Compatibility

40
Evaluation

• Here we have one common data store accessed by
  web service code base in spite of having
  different interfaces published at same time

• Common Data Store

41
Evaluation

• Here we have only one code base for the web
  service in spite of having different interfaces
  published at same time.

• No Code Duplication

42
Evaluation

• Untangled Versions

• Existence of only one code base for the web
  service allows the code specific to the
  peculiarities of each version be encapsulated
  within a separate adapter

Code Specific to peculiarities
43
Evaluation

• Unconstrained Evolution

• The interface and implementation can be changed
  in arbitrary ways, provided that there exists a
  way to implement the contract of the previous
  interface in terms of the new one.
• If the changes are fundamental, it may make more
  sense to consider the new version as an entirely
  new service rather than try to force fit it into
  the old interface.

44
Evaluation

• Visible Mechanism

• The delegation mechanism espoused by this design
  technique is both simple and fully exposed to the
  developer.

45
Evaluation

• In summary, the Chain of Adapters design
  technique achieves a clear win on four out of the
  six requirements

46
Evaluation

• In summary, the Chain of Adapters design
  technique achieves a clear win on four out of the
  six requirements and delivers a manageable
  compromise on the other two.

47
Tricks

• Bug Fixing
• What to do when a bug is discovered in the
  service implementation code ?
• If it is preferable to fix the bug in all
  versions, a single fix in the current version
  will suffice.
• If it is decided to let the bug stand in older
  versions, then the bug must be fixed in the
  current version and compensating code that
  replicates the buggy behavior must be added to
  the vn?vn1 adapter.

48
Tricks

• Bug Fixing

• If it is decided to let the bug stand in older
  versions by default but to offer a bug-fixed
  release under the older interface, it is possible
  to proceed as in option 2 but also to make a copy
  of the original adapter chain and offer it at a
  new set of endpoints (see Figure 9), effectively
  implementing options 1 and 2 simultaneously. This
  approach is useful for clients that want to take
  advantage of the bug fix without upgrading to the
  latest versions interface.

49
Tricks

• Overhead

• If withdrawing older versions from service is not
  desirable and their performance starts to suffer
  because of a surfeit of delegations, it is
  possible to employ another trick

50
Self-configuration Scenarios

• Instead of upgrading the whole application (i.e.,
  all its web services) simultaneously, we can
  upgrade the services one-by-one using the method
  described, in many localized transactions that
  introduce much smaller discontinuities and are
  easier to roll back in case of failure.

51
Prototype Implementation

• Built a prototype plug-in for the Eclipse Web
  Tools Platform (WTP) that automates the process
  of freezing and publishing a version of a
  WSDL/SOAP web service.
• Proven invaluable for testing and refining the
  designs concepts because of the bulky,
  work-intensive syntaxes of WSDL and XML Schema.
• Although the plug-in lacks support for all XML
  Schema features, it has successfully demonstrated
  that it is possible to reduce the developers
  workload while keeping the version management
  mechanisms visible.

52
Performance Analysis

• Latency

• Delays besides Adapter are
• Transport protocol
• SOAP Runtime

53
Performance Analysis

• Scalability

• 3- Tier Application
• Adapter Placement affects response time

54
References

• http//www.webservicesarchitect.com/content/articl
  es/irani04.asp
• http//www-128.ibm.com/developerworks/webservices/
  library/ws-backward.htmllisting1
• http//www-128.ibm.com/developerworks/java/library
  /ws-soa-backcomp/index.html?cadrs-resources

55
Conclusions

• In this paper, we laid out our requirements for a
  solution to the web services version management
  problem, and illustrated a number of
  unsatisfactory yet popular approaches.
• We then presented our own solution called Chain
  of Adapters, a simple design technique that can
  be applied by the developer to achieve backwards
  compatibility.
• CoA technique provides a good trade-off between
  satisfying the various requirements, with
  particular strength in the area of version
  untangling.
• The Chain of Adapters can prove useful in
  self-configuration scenarios. By decomposing a
  long update/roll-back transaction into a sequence
  of independent smaller transactions, the response
  time is affected to a smaller degree and the end
  user will not notice a discontinuity in service.

56

• Thank You