EQUIP Component Toolkit ECT: Implementation Notes

1
EQUIP Component Toolkit (ECT) Implementation
Notes

• Chris Greenhalgh
• EQUATOR review
• 2005-02-23

2
ECT Distribution Overview
Installation
Master host
Client host(s)
Installation Master
Multicast Discovery
Component Container(s)
Installation Dataspace
Attached and associated devices- sensors-
displays- actuators
Internet
LAN
Installation Management Tool
Component Container(s)
Browser/ viewer
3
Component/Container Interaction
Container
Component (Java Bean)
Consumes event type (provides event listener)
Has read/write and read-only properties(Serializa
ble types)
Emits event type (provides listener
registration)(not yet implemented)
Provides Native interface
Uses native interface(same-JVM only at present)
Initial state,Property Change events
Create component,set properties
Reflection
Installation Dataspace
Monitors data-itemsComponent requests,property
link requests,source properties
Publishes data-itemsreflecting current
state(Capabilities i.e. component factory,
Components, Properties)
4
Detail EQUIP Dataspaces and Dataitems

• Dataitem
• Strongly typed OO single inheritance
• Identified by unique GUID
• Pre-defined tuple type used in most recent
  applications
• Dataspace
• Client-server (could be P2P)
• Add, update, delete Dataitem operations (events)
• Can also define new event types
• Query via template objects (null wildcard)
• Copy collect, collect, in and out operations on
  local (inc. replicated) items
• Replication via Item Monitor patterns
• ongoing interest in items matching a template

5
Configuration and Execution Model

• Create/locatecomponentson appropriate
  hostse.g. device drivers,software
  services,behaviour, glue
• Set configuration property values(e.g. COM
  port)
• Create links betweenproperties to
  createdata-flow graph
• Train/script behaviour

Host A
Devices
SmartIT RF
RS-232
outTouch
SmartIT
Link
CaptureState
Camera
VFW, USB
SmartIT w/sensor
url
Serial SmartIT
url
Media viewer
minimum
maximum
VGA
current
Host C
Installation Data-space (Host A)
Components
6
Installation Persistence

• Dataspace persistence
• File-backed event log and checkpoints
• Persists component requests and link requests
• Will cause components and links to be
  re-requested
• Container persistence
• Checkpoint/configuration file
• Persists capability, component and property
  GUIDs, and property values
• Will cause apparently identical component(s) to
  be recreated in response to previously seen
  request(s)
• Component persistence (optional)
• Extra component-specific checkpoint file
• Persists internal state (not visible as
  properties)
• NB persisted information is specific to those
  particular containers and components not
  transferable

7
Transferable Configurations (new)

• XML file describing all (DS) visible information
• Capabilities, components, properties, links
• Wizard UI
• Attempts to find best-match in (possibly
  different) installation
• E.g. same component class name, same property
  name
• Allows selective instantiation
• E.g. use an already running component instead of
  creating a new one allowing configurations to
  be combined and linked
• Maps property values and links to these
  alternatives when specified
• Note can also be used as an additional
  (failsafe?!) persistence mechanism

8
Next steps

• Migrate to SourceForge under BSD licence
• Build user community(s)
• See also future directions

9
Future directions

• Community building/support
• Transferable configurations
• Allow sharing of arrangements
• Needs further improvements to wizard heuristics
• Transferable capabilities
• Needs support for automated distribution of
  capabilities (component classes) to other
  installations, and between hosts in one
  installation
• Including support for version identification/track
  ing
• Standard descriptions for capabilities and
  components
• Component directory?!

10
Future directions

• Community building/support (cont.)
• Move source to SourceForge under BSD licence
• More accessible to external developers
• Can outlive project
• Gives access to bug tracker, RFE, webCVS, forums,
  etc.
• Develop links with Processing
• Support for latest version(s)
• More example configurations, etc.
• Joint workshop?! Links from Processing web?!

11
Future directions

• Improved deployability for trials/studies
• Auto-start on boot (e.g. recovery/appliance)
• Improved remote diagnostics/trouble-shooting
• Record and Re-use
• Test-bed for emerging log-file and corpus file
  formats
• To be supported in replaytool
• Allow review/analysis of ECT use alongside video,
  text annotations