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

▶
dynamic reconfiguration of evolving web services
SMART_READER_LITE
LIVE PREVIEW

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

Feb 19, 2024 387 likes •634 views

Dynamic Reconfiguration of Evolving Web Services Piotr Kaminski and Hausi A. Mller Piotr Kaminski and Hausi A. Mller Marin Litoiu Marin Litoiu Department of Computer Science Department of Computer Science CAS Toronto CAS Toronto

slide-1
SLIDE 1

Dynamic Reconfiguration

  • f Evolving Web Services

Piotr Kaminski and Hausi A. Müller Piotr Kaminski and Hausi A. Müller Department of Computer Science Department of Computer Science University of Victoria University of Victoria

SEAMS 2006 SEAMS 2006— —ICSE ICSE Workshop May 21 Workshop May 21-

  • 22, 2006

22, 2006

Marin Litoiu Marin Litoiu CAS CAS Toronto Toronto IBM Canada Ltd. IBM Canada Ltd.

slide-2
SLIDE 2

Dynamic Reconfiguration of Evolving Web Services 2

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
slide-3
SLIDE 3

Dynamic Reconfiguration of Evolving Web Services 3

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
slide-4
SLIDE 4

Dynamic Reconfiguration of Evolving Web Services 4

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 well as self-

  • managing systems

managing systems

slide-5
SLIDE 5

Dynamic Reconfiguration of Evolving Web Services 5

My Web My Web Se Service rvice 1 1 Int Interface v1 rface v1 DB DB

Exhibit A: standalone versions Exhibit A: standalone versions

Safest: old versions unaffected by new ones Maintenance, consistency and scalability headaches

slide-6
SLIDE 6

Dynamic Reconfiguration of Evolving Web Services 6

My Web My Web Se Service rvice 2 2 Int Interface v2 rface v2 DB DB My Web My Web Se Service rvice 1 1 Int Interface v1 rface v1 DB DB

Exhibit A: standalone versions Exhibit A: standalone versions

Safest: old versions unaffected by new ones Maintenance, consistency and scalability headaches

slide-7
SLIDE 7

Dynamic Reconfiguration of Evolving Web Services 7

My Web My Web Se Service rvice 2 2 Int Interface v2 rface v2 DB DB My Web My Web Se Service rvice 1 1 Int Interface v1 rface v1 DB DB

Exhibit A: standalone versions Exhibit A: standalone versions

My Web My Web Se Service rvice 3 3 Int Interface v3 rface v3 DB DB

Safest: old versions unaffected by new ones Maintenance, consistency and scalability headaches

slide-8
SLIDE 8

Dynamic Reconfiguration of Evolving Web Services 8

My Web My Web Se Service rvice Int Interface rface DB DB

Exhibit B: schema extension Exhibit B: schema extension

Single access point forever, single codebase Tricky schemas, entangled code versions, constrained changes

XM XML Sc Sche hema ma

slide-9
SLIDE 9

Dynamic Reconfiguration of Evolving Web Services 9

My Web My Web Se Service rvice Int Interface rface DB DB

Exhibit B: schema extension Exhibit B: schema extension

Single access point forever, single codebase Tricky schemas, entangled code versions, constrained changes

XM XML Sc Sche hema ma

slide-10
SLIDE 10

Dynamic Reconfiguration of Evolving Web Services 10

My Web My Web Se Service rvice Int Interface rface DB DB

Exhibit B: schema extension Exhibit B: schema extension

Single access point forever, single codebase Tricky schemas, entangled code versions, constrained changes

XM XML Sc Sche hema ma

slide-11
SLIDE 11

Dynamic Reconfiguration of Evolving Web Services 11

My Web My Web Se Service rvice Int Interface 1 rface 1 DB DB

Exhibit C: Exhibit C: incremental interfaces incremental interfaces

Common and easy design, single codebase Scattered and bloated interfaces, entangled code versions

slide-12
SLIDE 12

Dynamic Reconfiguration of Evolving Web Services 12

Int Interface 2 rface 2 My Web My Web Se Service rvice Int Interface 1 rface 1 DB DB

Exhibit C: Exhibit C: incremental interfaces incremental interfaces

Common and easy design, single codebase Scattered and bloated interfaces, entangled code versions

slide-13
SLIDE 13

Dynamic Reconfiguration of Evolving Web Services 13

Int Interface 3 rface 3 Int Interface 2 rface 2 My Web My Web Se Service rvice Int Interface 1 rface 1 DB DB

Exhibit C: Exhibit C: incremental interfaces incremental interfaces

Common and easy design, single codebase Scattered and bloated interfaces, entangled code versions

slide-14
SLIDE 14

Dynamic Reconfiguration of Evolving Web Services 14

Int Interface v1 rface v1 My Web My Web Se Service rvice DB DB

Chain of Adapters Chain of Adapters

Versions separated, single code base, changes unconstrained Changes affect old versions,

chain length impacts maintenance and performance

Also known in Haskell as ECT: “Eternal Compatibility in Theory”

slide-15
SLIDE 15

Dynamic Reconfiguration of Evolving Web Services 15

Int Interface v2 rface v2 Int Interface v1 rface v1 My Web My Web Se Service rvice DB DB

Chain of Adapters Chain of Adapters

Versions separated, single code base, changes unconstrained Changes affect old versions,

chain length impacts maintenance and performance

Adapter Adapter Also known in Haskell as ECT: “Eternal Compatibility in Theory”

slide-16
SLIDE 16

Dynamic Reconfiguration of Evolving Web Services 16

Int Interface v2 rface v2 Int Interface v3 rface v3 Int Interface v1 rface v1 My Web My Web Se Service rvice DB DB

Chain of Adapters Chain of Adapters

Versions separated, single code base, changes unconstrained Changes affect old versions,

chain length impacts maintenance and performance

Adapter Adapter Adapter Adapter Also known in Haskell as ECT: “Eternal Compatibility in Theory”

slide-17
SLIDE 17

Dynamic Reconfiguration of Evolving Web Services 17

Requirements Requirements

1.

Backwards compatibility

2.

Common code base

3.

Common data store

Interface v2 Web Service v1+v2+v3 Interface v1 Interface v3 Web Service v2 Interface v2 Web Service v1 Interface v1 Web Service v3 Interface v3

4.

Untangled versions

5.

Unconstrained evolution

6.

Visible mechanism Isolated versions Isolated versions Tangled versions Tangled versions

slide-18
SLIDE 18

Dynamic Reconfiguration of Evolving Web Services 18

Chain of Adapters (CofA) Chain of Adapters (CofA)

slide-19
SLIDE 19

Dynamic Reconfiguration of Evolving Web Services 19

1.

duplicate interface into new namespace

2.

create trivial delegating adapter

3.

publish frozen interface at new endpoint

4.

make compensating changes in adapter

Interface v1 Adapter v1↔v2 Web Service Current Interface

Chain of Adapters (CofA) Chain of Adapters (CofA)

slide-20
SLIDE 20

Dynamic Reconfiguration of Evolving Web Services 20

1.

duplicate interface into new namespace

2.

create trivial delegating adapter

3.

retarget previous adapter

4.

publish frozen interface at new endpoint

5.

make compensating changes in adapter

Interface v1 Adapter v1↔v2 Web Service Current Interface Interface v2 Adapter v2↔v3

Chain of Adapters (CofA) Chain of Adapters (CofA)

slide-21
SLIDE 21

Dynamic Reconfiguration of Evolving Web Services 21

Interface v1 Adapter v1↔v2 Web Service Current Interface Interface v2 Adapter v2↔v3 Interface vn Adapter vn↔vn+1

Chain of Adapters (CofA) Chain of Adapters (CofA)

Pros

  • common code/data
  • encapsulated versions
  • transparent mechanism

Cons

  • backwards compatibility not

guaranteed

  • some constraints on evolution
  • performance issues

(manageable)

slide-22
SLIDE 22

Dynamic Reconfiguration of Evolving Web Services 22

Reconfiguration Scenario Reconfiguration Scenario

Applying Chain of

Adapters (CofA) within an application allows:

  • splitting the

reconfiguration process into smaller chunks

  • shorter service

discontinuities

  • easier failure recovery

v1 A v1 B v1 C v1 D v1 A’ v1 B’ v1 C v1 D (a) (b) v2 v2

(Each box in these diagrams encompasses a whole application, including its entire chain of adapters.)

slide-23
SLIDE 23

Dynamic Reconfiguration of Evolving Web Services 23

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