Dynamic software adaptation for service oriented product lines

Dynamic Software Adaptation for Service-Oriented Product Lines

Maarten ChristiaenNiels Claeys

Gomaa H.Hashimoto K.

2

Outline

1. Motivation2. SASSY framework3. Dynamic Software Adaptation for SPL4. Case study5. Conclusion6. Reflection

Motivation

SOA: increasingly popular→ adapt environment + operational requirement State of practice:

Build at design time Based feature model

New: Regenerate based on

QOS Architecture and

adaptation patterns for SOA

Change: behavior, services, architecture

Three-layer Architecture: SASSY

Self Architecting Software SYstem Monitoring: trigger adaption Goal: transition between architectures based on trigger Adaptation: execute the plan of goal management

5

Dynamic Software Adaptation for SPL

Feature modeling in DSPL SOA architecture Adaptation pattern Changes to SASSY

DSPL: Feature modeling

Target system reconfiguration: defining run-time configurations Reconfigurable components: feature-component mapping

SOA: Architecture pattern SOA: loose coupling + self contained Coordinator: interconnection of service→ contain adaptation state Service: stateless

Reconfigure architecture

Executed by Change management: based on new structure Identify components affected Transition components to quiescent state→ adaptation pattern Replace components

SASSY: adaptation

Goal: selects new features

Adaptation patterns in component control

CM: issue changesMonitor: initiate change

Case study (1)

Feature-component mapping

Feature model

Case study (2)

Conclusions Combined approach of:

SPL SOA dynamic software adaptation

Adapt dynamically different member of SPL Towards adapting whole system → assume system can be divided in independent architectural patternsSelf architecting = switching between architectures created during SPL design

13

Relation to Capita selecta

Inspired by SPL → Extended for dynamic configuration Smallest building block = service Not sufficient for SaaS

No support for multi-tenancy Customizability for tenants not supported

Reflection

+ Dynamic adaptation based on QoS+ Hierarchical replacement+ Reuse: SOA architecture patterns

- Multi-tenancy- No co-existing configurations- Smallest block service- Only use featuresexisting at design time→ no self architecting- No quantifiable results

Questions?