A framework for managing dynamic service- oriented component - - PowerPoint PPT Presentation

▶
a framework for managing dynamic service oriented
SMART_READER_LITE
LIVE PREVIEW

A framework for managing dynamic service- oriented component - - PowerPoint PPT Presentation

Dec 20, 2022 247 likes •621 views

A framework for managing dynamic service- oriented component architectures Walter Rudametkin 1,2 , Lionel Touseau 1 , Didier Donsez 1 , Francois Exertier 2 2 BULL SAS 1 LIG - ADELE Echirolles, France Grenoble University

slide-1
SLIDE 1

A framework for managing dynamic service-

  • riented component architectures

Walter Rudametkin1,2 , Lionel Touseau1, Didier Donsez1, Francois Exertier2

1 LIG - ADELE Grenoble University {firstname}.{name}@imag.fr 2 BULL SAS Echirolles, France {firstname}.{name}@bull.net

slide-2
SLIDE 2

Context

slide-3
SLIDE 3

Walter Rudamentkin, IEEE-APSCC 2010

Building complex software systems

 Large systems

  • Millions of lines of code (eg.: Eclipse ~33 mloc)

 Entangled dependencies

  • Hundreds of different modules that must co-exist

 Run-time adaptation

  • We want the software to change/update @ runtime
  • Requires managing the architecture
slide-4
SLIDE 4

Walter Rudamentkin, IEEE-APSCC 2010

Architecture management

 We propose a framework that eases the

development of architecture managers

  • Provides basic services
  • Provides abstractions of the architecture
  • Helps make pertinent decisions on changes
  • Calculates the cost of reconfigurations
  • Can be used to create specialized managers

▪ E.g., Minimize footprint, adapt to new requirements, high availability, user context, healing...

slide-5
SLIDE 5

How things work

(in our world)

slide-6
SLIDE 6

Walter Rudamentkin, IEEE-APSCC 2010

Service Oriented Computing

Service Registry Service Provider Service Client

Lookup Bind Publish

slide-7
SLIDE 7

Walter Rudamentkin, IEEE-APSCC 2010

Service Registry Service Provider Service Client

Lookup Publish Bind Notify Un-publish

Dynamic Service Oriented Computing

slide-8
SLIDE 8

Walter Rudamentkin, IEEE-APSCC 2010

Service-Oriented Components

POJO (Business code) Component Membrane Provided Service Required Service

slide-9
SLIDE 9

Walter Rudamentkin, IEEE-APSCC 2010

Client Provider Service Registry

Lookup Publish Bind Notify

Service-Oriented Components

slide-10
SLIDE 10

10

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: modules and components

Component Component Provided Services Required Services

slide-11
SLIDE 11

11

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: modules and components

Module Component Component Provided Services Required Services Provided implementation code Required implementation code

slide-12
SLIDE 12

12

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: modules and components

Module Component Component Provided Services Required Services Provided implementation code Required implementation code Required Resources Provided Resources

slide-13
SLIDE 13

13

Walter Rudamentkin, IEEE-APSCC 2010

Service-Oriented Component abstraction levels

EXECUTION FRAMEWORK MODULE 1 MODULE 2 MODULE 3 MODULE 4

Service Component instances Service Component Types Class definitions Object instances Deployment unit repository Service-Oriented Component Model Object Oriented Implementation Run time view Design time view Deployment view Deployment platform

slide-14
SLIDE 14

What do we do with all of this?

slide-15
SLIDE 15

15

Walter Rudamentkin, IEEE-APSCC 2010

Our approach

 model@run.time

  • Architecture model based on dependencies (Graph)

 Management framework

  • Exports the application model
  • Calculates the cost of a reconfiguration

▪ Based on dependency information

  • Proposes management services

▪ Repository access, Remote services, Resource management, Application monitoring, ...

slide-16
SLIDE 16

Walter Rudamentkin, IEEE-APSCC 2010

Model @ runtime: Why analyze dependencies?

 Primary constraint for reconfigurations

  • Required for installing, instantiating, executing software

 Affect component lifecycle  Complicate uninstallation

  • E.g.: We want to reduce footprint and not break the

application

 Missing dependencies can break the application

  • Halt components, cause state-loss, unavailability, …

 For Centralized Applications

  • (i.e., single memory space)
slide-17
SLIDE 17

17

Walter Rudamentkin, IEEE-APSCC 2010

Impact of a dynamic reconfiguration

 We use the dependency graph to calculate impact

  • Modules stopped (state-loss)
  • Components stopped (possible state-loss)
  • Modules installed and/or restarted
  • Components installed and/or restarted
  • Bindings and re-bindings

 Rollback and recovery not considered

slide-18
SLIDE 18

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

18

 All components running

C C C C

Example: Domino effect

slide-19
SLIDE 19

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

19

C C C C

Example: Domino effect

 One component stops

slide-20
SLIDE 20

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

20

C C C C

Example: Domino effect

 All components are affected and stopped

slide-21
SLIDE 21

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

21

C C C C

Example: Domino effect

 The component becomes available again

slide-22
SLIDE 22

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

22

C C C C

Example: Domino effect

 All components run again

slide-23
SLIDE 23

Our prototype

slide-24
SLIDE 24

24

Walter Rudamentkin, IEEE-APSCC 2010

Framework overview

Resolver Repository Manager Resource Manager RunTime Manager

Generic Architecture Services

Distant Service Manager

Architecture Manager

Problem Specific Component

Architecture Manager Framework

slide-25
SLIDE 25

25

Walter Rudamentkin, IEEE-APSCC 2010

Framework overview: big picture

slide-26
SLIDE 26

26

Walter Rudamentkin, IEEE-APSCC 2010

Implementation details

 Based on the OSGi Service Platform  Makes extensive use of other projects

  • Apache Felix
  • Apache iPOJO
  • OW2 Chameleon - ROSE
  • OW2 JonAS
  • Eclipse P2
  • SIGAR (SpringSource)
  • …
slide-27
SLIDE 27

Final remarks

slide-28
SLIDE 28

28

Walter Rudamentkin, IEEE-APSCC 2010

Conclusions

 Framework for handling and understanding dynamism

in service oriented component platforms

  • Run time impact of dynamic reconfigurations

 We provide the basic mechanisms for manipulating an

application's architecture.

 More “intelligent” features can be implemented on top  The project will be open-sourced on the OW2 JOnAS

project in the (near) future.

slide-29
SLIDE 29

29

Walter Rudamentkin, IEEE-APSCC 2010

Perspectives

 Define reactive properties (application reflexes)

  • Because some actions are not controlled by the

application or the manager (eg., devices, remote services)

 Use a Reference or Abstract architecture

  • To enforce and/or validate the architecture
  • To provide autonomic architecture adaptation and

evolution (e.g., based on QoS)

slide-30
SLIDE 30

30

Walter Rudamentkin, IEEE-APSCC 2010 23/10/08

Questions?

slide-31
SLIDE 31

31

Walter Rudamentkin, IEEE-APSCC 2010

OSGi Dependency classification (related to impact)

Static Package, Stale references, Dynamic-import, Fragments, Extension points, Handler Dynamic Services, Publish-subscribe pattern, Whiteboard pattern Either Resources, Extender pattern, Configuration

slide-32
SLIDE 32

32

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: design-pattern

Publisher Subscriber

Event Admin

Publish Subscribe pattern

Common datatype

slide-33
SLIDE 33

33

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: design-pattern

Command 2 Command 1 Command 3

Shell Service

Whiteboard pattern

Inverted dependencies

slide-34
SLIDE 34

34

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: design-pattern

Component Container

Extender pattern

Component 2

Meta- data

Component 1

Meta- data

slide-35
SLIDE 35

35

Walter Rudamentkin, IEEE-APSCC 2010

Dependencies: modules and components

Module Component Component Provided Services Required Services Provided implementation code Required implementation code Required Resources Provided Resources Required Design-Pattern Provided Design-Pattern

slide-36
SLIDE 36

Walter Rudamentkin, IEEE-APSCC 2010

8 décembre 2010

36

Conséquences (4)

 Arrêts en cascade dans le cas d’une composition

  • Effet domino

C C C C