Pre structured systems
Download
1 / 16

Pre-structured Systems - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Pre-structured Systems. Pre-structured systems (e.g. SDL systems). Stable (cannot be added or changed dynamically) : System structure Block/process sets Block/process types Variable: Number of instances in block/process sets Parameter and variable values

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Pre-structured Systems' - micah


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Pre structured systems e g sdl systems
Pre-structured systems (e.g. SDL systems)

  • Stable (cannot be added or changed dynamically) :

    • System structure

    • Block/process sets

    • Block/process types

  • Variable:

    • Number of instances in block/process sets

    • Parameter and variable values

    • Static and dynamic links (PId values)

  • Is some degree of self configuring/adaptation possible?

System X

??

??

a(,):AT

??

??

b(,):BT

c(,):CT

??

d(,):DT


Self configuration and adaptation
Self configuration and adaptation:

  • Interrogating the environment and obtaining information

  • Using the information to:

    • create instances within the block/process sets

    • create references linking instances

    • initialise and change data

  • Note that the information must be dynamically provided by the environment! A configuration file prepared by a human operator does not count!

  • Self configuration therefore requires descriptive information - metadata - about the environment to be provided by the environment (reflection).

  • Self adaptation requires continuous supervision and adaptation to changes

  • Information must be provided for each variable part (component set)


How to do it
How to do it?

we need:

  • to discover/explore and monitor the environment –detect changes

  • to manage addresses and keep a Registry over external entities and their properties

  • to interpret properties and configure the system - create the internal instance structure, assign references and data values: AppConfigurer

  • suitable identities/references and routing mechanisms

System X

a(2,2):AT

Here the system adapts to changes in the environment

Registry may be outside or inside system

ae(2,2):AET

b(,):BT

ce(10,125):CET

c(10,125):CT

d(,):DT

Registry

AppConfigurer


Object plug and play
Object plug-and-play

  • Objectplug-in

  • Get address,discover Registry, and do registration

  • NotifiyAppConfigurer

  • Createapplicationobjects

  • Objectsexecutewithdynamicfind-bindifneeded

Think of some examples

System X

5

1

a(2,2):AT

ae(2,2):AET

b(,):BT

2

ce(10,125):CET

c(10,125):CT

4

d(,):DT

Registry

3

AppConfigurer


Pre structured systems in general
Pre-structured systems in general

  • Fixed (known) communication infrastructure

  • Fixed (known) set of types

  • Fixed (known) content structure

  • Dynamic linking and data values

  • Part descriptions (reflection)

  • Mechanism for part registration, discovery and configuring

Limitations?


What if there are alternative component types
What if there are alternative component types?

Several alternative component types may serve the new object

System X

5

1

a(2,2):AT

ae(2,2):AET

b(,):BT

2

ce(10,125):CET

c(10,125):CT

4

d(,):DT

Registry

3

AppConfigurer


Then we need
Then we need

  • A way to represent alternatives

  • A way to selectthe best alternative

  • or dynamicallycomposethe best alternative (usingcompositionaladaptation)

System X

5

1

a(2,2):AT

ae(2,2):AET

b(,):BT

2

ce(10,125):CET

c(10,125):CT

4

d(,):DT

Registry

3

AppConfigurer


What if the object type is new
What if the object type is new?

Instances of unknown object types

System X

*(,):*

*(,):*

ae(2,2):AET*

a(2,2):AT*

ce(10,125):CET*

c(10,125):CT*

AppConfigurer

Registry


Then we need1
... then we need

  • an extensible structure

  • a way to load and ”install” new types

  • i.e. some support for dynamic components

  • less is known at design-time, more postponed to run-time

System X

*(,):*

*(,):*

ae(2,2):AET

a(2,2):AT

ce(10,125):CET

c(10,125):CT

Registry

AppConfigurer


Towards dynamic components
Towards dynamic components

  • Using a minimal invariant infrastructure: addressing, routing, registry, ...

  • Dynamic component lifecycle: install, configure, start, ... uninstall

  • Dynamic linking with alternatives

  • Extending/changing the structure

Extending/changing structure

System X

*(,):*

*(,):*

ae(2,2):AET*

a(2,2):AT*

Changing/replacing types

ce(10,125):CET*

c(10,125):CT*

Dealing with the unaticipated

Registry

AppConfigurer

infrastructure


And now it is getting difficult
And now it is getting difficult

  • Services are not fixed

  • Structure is not fixed,

  • Even the types may change.

  • Only a minimal infrastructure remains invariant and known

  • How to reason about the unknown?

  • How to adapt to the unanticipated?

  • How to ensure interoperabilty and consistency?


Basic functionalities identified so far
Basic functionalities identified so far

  • Application dependent:

  • AppConfigurer: configure, re-configure

  • Find-bind-release (session initiation):

    • Roles

    • Agents

  • Context/situation adaptation

Generic:

  • Detection, e.g. plug-in; plug-out

  • Explore/discover: get address, find the registry and other support units

  • Registry: register, de-register, lookup

  • Learn: load new types/code

System X

*(,):*

*(,):*

Doctors

Patients

ae(2,2):AET

a(2,2):AT

c(10,125):CT

DoctorAgent[m]

PatientAgent[n]

ce(10,125):CET

Registry

AppConfigurer


Is the appconfigurer such a good idea
Is the AppConfigurer such a good idea?

  • Needs to know the applications

  • Needs to change with the applications

  • Build it into the applications in stead?

System X

*(,):*

*(,):*

ae(2,2):AET

a(2,2):AT

ce(10,125):CET

c(10,125):CT

Registry

AppConfigurer


From content constraints to context constraints
from content constraints to context constraints

  • Content constraints: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules.

  • Context constraints: govern the external use of (instances of) a type. Gate constraints in SDL and interface definitions CORBA style, can be seen as context rules. Well defined roles provide context rules.

Let object themself take care of application dependent configuring

context

block type XT

content

ae(,):AET

a(,):AT

be(,):BET

b(,):BT

ce(,):CET

c(,):CT

d(,):DT

de(,):DET

AppConfigurer

Registry


Pre structured systems vs dynamic component systems
Pre-structured systems vs. dynamic component systems

  • Pre-structured – emphasis on content constraints defining the part structure and the part types: compositional adaptation bounded by the structure

  • Dynamic component systems – emphasis on context constraints that govern how components may be composed (without prescribing a particular structure): compositional adaptation bounded by the components

Context constraints are key to dynamic component systems,

i.e. interface definitions