1 / 16

Pre-structured Systems

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

micah
Download Presentation

Pre-structured Systems

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pre-structured Systems

  2. 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

  3. 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)

  4. 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

  5. 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

  6. 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?

  7. 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

  8. 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

  9. 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

  10. ... 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

  11. 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

  12. 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?

  13. 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

  14. 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

  15. 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

  16. 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

More Related