Dynamic Reconfiguration of Evolving Web Services Piotr Kaminski and - PowerPoint PPT Presentation

Dynamic Reconfiguration of Evolving Web Services Piotr Kaminski and Hausi A. Müller Piotr Kaminski and Hausi A. Müller Marin Litoiu Marin Litoiu Department of Computer Science Department of Computer Science CAS Toronto CAS Toronto University of Victoria University of Victoria IBM Canada Ltd. IBM Canada Ltd. SEAMS 2006— —ICSE ICSE Workshop May 21 Workshop May 21- -22, 2006 22, 2006 SEAMS 2006

DEAS: Design and Evolution of DEAS: Design and Evolution of Autonomic Application Software Autonomic Application Software Sponsored by IBM Toronto and NSERC: $750K over 3 years � Principal Investigators � Hausi A. M üller, University of Victoria � John Mylopoulos, University of Toronto/Trento � Marin Litoiu, IBM Canada Ltd. � Over 15 PhD and MSc students involved � I Investigate methods for designing and evolving high-variability, self-managed � systems using goal-driven requirements engineering methods Develop an analysis framework for AC application architectures using ABASs � Investigate methods for evaluating complex tradeoffs � Self-configuration of web and grid services � Trust nomenclature for building AC systems incrementally � Dynamic Reconfiguration of Evolving Web Services 2

Goals and Results Goals and Results � We are looking at: � autonomic self-configuration � dynamic redeployment � � � evolution management � ... from a design-time perspective ... applied to web services � Our results thus far: � The Chain of Adapters design technique for version management � An Eclipse/WTP (Web Tools Platform) plug-in to help apply Chain of Adapters to a WSDL/SOAP web service � Support from IBM Autonomic Computing and IBM Web Services VPs Dynamic Reconfiguration of Evolving Web Services 3

The Challenge The Challenge � Support backwards-compatible web service evolution � Minimize cost of supporting older versions � Simple for service developers, transparent for client developers For human administrators as For human administrators as well as self- -managing systems managing systems well as self Dynamic Reconfiguration of Evolving Web Services 4

Exhibit A: standalone versions Exhibit A: standalone versions Int Interface v1 rface v1 My Web My Web Se Service rvice 1 1 DB DB � Safest: old versions unaffected by new ones � Maintenance, consistency and scalability headaches Dynamic Reconfiguration of Evolving Web Services 5

Exhibit A: standalone versions Exhibit A: standalone versions Interface v1 Int rface v1 Interface v2 Int rface v2 My Web My Web My Web My Web Service Se rvice 1 1 Service Se rvice 2 2 DB DB DB DB � Safest: old versions unaffected by new ones � Maintenance, consistency and scalability headaches Dynamic Reconfiguration of Evolving Web Services 6

Exhibit A: standalone versions Exhibit A: standalone versions Int Interface v3 rface v3 Interface v1 Int rface v1 Int Interface v2 rface v2 My Web My Web My Web My Web My Web My Web Service Se rvice 3 3 Se Service rvice 1 1 Service Se rvice 2 2 DB DB DB DB DB DB � Safest: old versions unaffected by new ones � Maintenance, consistency and scalability headaches Dynamic Reconfiguration of Evolving Web Services 7

Exhibit B: schema extension Exhibit B: schema extension XM XML Sc Sche hema ma Int Interface rface My Web My Web Se Service rvice DB DB � Single access point forever, single codebase � Tricky schemas, entangled code versions, constrained changes Dynamic Reconfiguration of Evolving Web Services 8

Exhibit B: schema extension Exhibit B: schema extension XM XML Sc Sche hema ma Int Interface rface My Web My Web Se Service rvice DB DB � Single access point forever, single codebase � Tricky schemas, entangled code versions, constrained changes Dynamic Reconfiguration of Evolving Web Services 9

Exhibit B: schema extension Exhibit B: schema extension XM XML Sc Sche hema ma Int Interface rface My Web My Web Se Service rvice DB DB � Single access point forever, single codebase � Tricky schemas, entangled code versions, constrained changes Dynamic Reconfiguration of Evolving Web Services 10

Exhibit C: Exhibit C: incremental interfaces incremental interfaces Interface 1 Int rface 1 My Web My Web Se Service rvice DB DB � Common and easy design, single codebase � Scattered and bloated interfaces, entangled code versions Dynamic Reconfiguration of Evolving Web Services 11

Exhibit C: incremental interfaces Exhibit C: incremental interfaces Int Interface 2 rface 2 Interface 1 Int rface 1 My Web My Web Se Service rvice DB DB � Common and easy design, single codebase � Scattered and bloated interfaces, entangled code versions Dynamic Reconfiguration of Evolving Web Services 12

Exhibit C: incremental interfaces Exhibit C: incremental interfaces Int Interface 2 rface 2 Int Interface 3 rface 3 Interface 1 Int rface 1 My Web My Web Service Se rvice DB DB � Common and easy design, single codebase � Scattered and bloated interfaces, entangled code versions Dynamic Reconfiguration of Evolving Web Services 13

Chain of Adapters Chain of Adapters Also known in Haskell as ECT: “ E ternal C ompatibility in T heory” Int Interface v1 rface v1 My Web My Web Se Service rvice DB DB � Versions separated, single code base, changes unconstrained � Changes affect old versions, chain length impacts maintenance and performance Dynamic Reconfiguration of Evolving Web Services 14

Chain of Adapters Chain of Adapters Also known in Haskell as ECT: “ E ternal C ompatibility in T heory” Int Interface v1 rface v1 Int Interface v2 rface v2 Adapter Adapter My Web My Web Se Service rvice DB DB � Versions separated, single code base, changes unconstrained � Changes affect old versions, chain length impacts maintenance and performance Dynamic Reconfiguration of Evolving Web Services 15

Chain of Adapters Chain of Adapters Also known in Haskell as ECT: “ E ternal C ompatibility in T heory” Interface v1 Int rface v1 Interface v2 Int rface v2 Int Interface v3 rface v3 Adapter Adapter Adapter Adapter My Web My Web Service Se rvice DB DB � Versions separated, single code base, changes unconstrained � Changes affect old versions, chain length impacts maintenance and performance Dynamic Reconfiguration of Evolving Web Services 16

Requirements Requirements Backwards compatibility Untangled versions 1. 4. Common code base Unconstrained evolution 2. 5. Common data store Visible mechanism 3. 6. Isolated versions Isolated versions Tangled versions Tangled versions Interface v 1 Interface v 2 Interface v 3 Interface v 1 Interface v 2 Interface v 3 Web Service Web Service Web Service Web Service v 1 v 2 v 3 v 1 +v 2 +v 3 Dynamic Reconfiguration of Evolving Web Services 17

Chain of Adapters (CofA) Chain of Adapters (CofA) Dynamic Reconfiguration of Evolving Web Services 18

Chain of Adapters (CofA) Chain of Adapters (CofA) Interface v 1 Current Interface Adapter v 1 ↔ v 2 Web Service duplicate interface into new namespace 1. create trivial delegating adapter 2. publish frozen interface at new endpoint 3. make compensating changes in adapter 4. Dynamic Reconfiguration of Evolving Web Services 19

Chain of Adapters (CofA) Chain of Adapters (CofA) Interface v 1 Interface v 2 Current Interface Adapter v 2 ↔ v 3 Adapter v 1 ↔ v 2 Web Service duplicate interface into new namespace 1. create trivial delegating adapter 2. retarget previous adapter 3. publish frozen interface at new endpoint 4. make compensating changes in adapter 5. Dynamic Reconfiguration of Evolving Web Services 20

Chain of Adapters (CofA) Chain of Adapters (CofA) Current Interface v 1 Interface v 2 Interface v n Interface Adapter Adapter Adapter Web v 1 ↔ v 2 v 2 ↔ v 3 v n ↔ v n+1 Service Pros Cons common code/data backwards compatibility not � � guaranteed encapsulated versions � some constraints on evolution � transparent mechanism � performance issues � (manageable) Dynamic Reconfiguration of Evolving Web Services 21

Reconfiguration Scenario Reconfiguration Scenario v 1 v 1 � Applying Chain of v 1 Adapters (CofA) within C B an application allows: v 1 A � splitting the reconfiguration process into smaller chunks D � shorter service (a) discontinuities v 1 v 1 v 2 � easier failure recovery v 1 v 2 C B’ (Each box in these v 1 diagrams encompasses A’ a whole application, including its entire D chain of adapters.) (b) Dynamic Reconfiguration of Evolving Web Services 22

Conclusions Conclusions � Present: � Design guidance for backwards-compatible web service evolution � Eclipse Web Tools Platform (WTP) “freeze & delegate” plug-in � Next steps: � Rewrite Chain of Adapters plug-in for WTP 1.0/1.5 � Adapt plug-in for IBM WebSphere Application Server (WAS) � Integrate plug-in into production WTP or other IBM tools � Investigate generalizing chain into tree e.g. for bug fixes, or decoupled client/server development � Dynamic Reconfiguration of Evolving Web Services 23