Architectural Reconfiguration Architectural Reconfiguration using - - PowerPoint PPT Presentation

architectural reconfiguration architectural
SMART_READER_LITE
LIVE PREVIEW

Architectural Reconfiguration Architectural Reconfiguration using - - PowerPoint PPT Presentation

Architectural Reconfiguration Architectural Reconfiguration using Coordinated Atomic Actions using Coordinated Atomic Actions Rog rio rio de Lemos de Lemos Rog University of Kent, UK University of Kent, UK Motivation;


slide-1
SLIDE 1

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 1

Architectural Reconfiguration Architectural Reconfiguration using Coordinated Atomic Actions using Coordinated Atomic Actions

Rog Rogé ério rio de Lemos de Lemos University of Kent, UK University of Kent, UK

Motivation; Coordinated atomic actions (CA actions); CA actions applied to reconfiguration; Conclusions;

slide-2
SLIDE 2

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 2

Motivation Motivation

System reconfiguration is not that simple:

it’s hard!

In dependable system where assurances are necessary:

it’s even harder!!

What happens if something goes wrong?

atomic actions applied to reconfiguration – nothing new!

  • ensures consistency in the presence of failures and concurrent

access;

coordinated atomic actions (CA actions);

  • Newcastle Univ. (B. Randell group), 15 years ago;
slide-3
SLIDE 3

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 3

Motivation Motivation

Where are the ‘self’ properties?

a general mechanism that can be used in self-reconfigurable

systems;

systems react to “unexpected” situations through

“predictable” means;

slide-4
SLIDE 4

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 4

Architectural Reconfiguration Architectural Reconfiguration

In the context of fault tolerance:

fault handling during system recovery:

addition, removal, or replacement of components and

connectors;

modifications to the configuration or parameters of

components and connectors;

alterations in the component/connector network’s topology.

the outcome of reconfiguration should be a safe

(stable and useful) state in the system configuration:

sequence of atomic actions has been widely advocated:

slide-5
SLIDE 5

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 5

Coordinated Atomic Actions Coordinated Atomic Actions (CA Actions) (CA Actions)

CA actions is a unified approach that deals with both competitive and cooperative concurrency:

  • transactions

transactions - maintain the consistency of shared resources in the presence of failures and concurrency;

  • conversations

conversations - control cooperative concurrency, and implement coordinated and disciplined error recovery; CA actions have applied to:

structuring complex and concurrent activities for error

confinement;

supporting the provision of error detection and

handling.

slide-6
SLIDE 6

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 6

Coordinated Atomic Actions Coordinated Atomic Actions (CA Actions) (CA Actions)

Activity T1 Activity T2

CA Action

e exception handler H1

abnormal control flow

exit after successful handling

entry points exit points accesses recovery

exception handler H2

abnormal control flow

external objects start transaction commit transaction

exception handling context

Borrowed from A. Romanovsky

slide-7
SLIDE 7

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 7

Coordinated Atomic Actions Coordinated Atomic Actions (CA Actions) (CA Actions)

Existing applications of CA actions:

it has focused on error handling – application

dependent;

fault handling are considered in the context of the

application;

there is no explicit separation of concerns between

application and reconfiguration services;

slide-8
SLIDE 8

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 8

Separation of Concerns Separation of Concerns

At the level of the architectural element:

internal structuring for the

purpose of error confinement;

more attention to each part,

and their interaction;

promotes reuse on

configuration services since they are similar across architectural elements.

slide-9
SLIDE 9

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 9

Reliable Stock Quotes Reliable Stock Quotes

Peer-to-peer architectural style; Architectural elements:

  • stereotyped UML2.0 components;
  • Provided and required interfaces;
slide-10
SLIDE 10

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 10

Replacing Components Replacing Components

slide-11
SLIDE 11

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 11

Replacing Components Replacing Components

X

slide-12
SLIDE 12

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 12

Replacing Connectors Replacing Connectors

slide-13
SLIDE 13

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 13

Replacing Connectors Replacing Connectors

slide-14
SLIDE 14

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 14

Separation of Concerns Separation of Concerns

Computation Computation, coordination coordination and configuration configuration (CCC) system architecture [Fiadeiro, Wermelinger, Andrade, etc.]

Computation Resources Coordination Resources Configuration Layer A B

slide-15
SLIDE 15

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 15

Conclusions Conclusions

Applying CA actions as a mechanism for supporting

dynamic architectural configuration;

Separation of concerns between:

error detection and recovery, which is application dependent; fault handling, which can be incorporated into the

middleware;

For self-adaptive systems, structural flexibility is

  • btained by:
  • small increments in the system configuration that can be

undone in case of failure;

slide-16
SLIDE 16

Rogério de Lemos ICSE 2006 SEAMS – May 2006 – 16

Conclusions Conclusions

Fault tolerance at the architectural level

error detection and handling:

  • application dependent;
  • idealised Fault Tolerant Architectural Elements (iFTE);

fault handling:

  • not application dependent;
  • reconfiguration support by CA action;