Autonomizing Legacy Systems

1
Autonomizing Legacy Systems

• Gail Kaiser
• Programming Systems Lab
• Columbia University

2
The Legacy We Want
The Legacy We Get
3
But System of Systems
Not Just Systems
4
Systems of Legacy Systems

• Methodologies and technologies are being devised
  for building new autonomic systems, but these
  often do not apply so nicely to legacy components
• Autonomic capabilities are needed in systems of
  systems assembled from existing components
• We propose one approach to autonomizing legacy
  systems and assembling autonomic
  systems-of-systems

5
Who is We?

• Bob Balzer and Dave Wile, Teknowledge
• Nathan Combs, BBN
• David Garlan and Bradley Schmerl, CMU
• George Heineman, WPI
• Gail Kaiser, Columbia University
• David Wells and Paul Pazandak, OBJS
• And colleagues and students
• Others welcome to Join!

6
Outline

• Retrofitting Autonomicity
• Common Infrastructure
• Probes
• Gauges
• Coordinated Effectors
• Architectural Model-based Analysis Decision
• Progress Contributions
• Other PSL projects towards Autonomic Computing

7
Retrofitting Autonomicity

• Inserting adaptation (self-xyz) mechanisms into
  existing application code is difficult,
  error-prone and costly, and hard to reuse or
  reason about
• We seek to enable autonomic properties through a
  solution orthogonal to the legacy systems main
  business logic and communication framework
• Introduce common external infrastructure
• This infrastructure becomes an integral part of
  the system-of-systems self, co-existing and
  cooperating with the systems functional
  mechanisms

8
Decision
Controllers
Gauge Bus
Interpretation
Gauges
Architectural Models
Collection
Probe Bus
Probes
Running System
Configuration
Effectors
9
Four-tiered Infrastructure

• Data is collected from a running system
  instrumented with non-invasive probes
• Gauges map the probe data into the system
  architectural model as well as into a metric
  model
• The decision control layer analyzes
  implications of the interpreted data on overall
  system functionality and performance, and
  determines whether/when/how to
• Deploy new (or disable existing) gauges and
  probes, and/or
• Deploy software effectors to reconfigure or adapt
  individual components and/or major substructures
  of the system
• Effectors make the actual changes

10
Key Point

• Augment system-of-systems with a decentralized
  decision control mechanism that can specify and
  manage both local optimizations and full-system
  reconfigurations
• Decentralized process/workflow definition and
  enactment

11
Kinesthetics eXtreme (KX)

• Columbia PSLs implementation of Common
  Infrastructure
• Currently missing architectural modeling, so
  usable but limited
• Most of KX can be downloaded from
  http//www.psl.cs.columbia.edu/software.html
• KX is being applied for load balancing, etc. in
  Telecom Italia Labs heterogeneous instant
  messaging and ISIs open information geographical
  analysis system (GeoWorlds)

12
(No Transcript)
13
(No Transcript)
14
Probes Gauges

• Active Interfaces Development Environment (AIDE,
  WPI) inserts callback probes into Java source
  code
• Probelets are Worklets mobile agents, so only WVM
  needs to be pre-installed
• Smart Events proposed standard XML Schema (with
  OBJS) for infrastructure communication
• XUES (XML-based Universal Event Service)
• Event Packager transforms legacy probe output,
  logs replays event streams
• Event Distiller recognizes complex temporal event
  patterns, interfaces to decision and to gauge
  visualizers

15
(No Transcript)
16
Coordinated Effectors

• Workflakes structures decentralized workflow
  through plugins on top of Cougaar blackboard
  (with BBN)
• Selects, customizes, instantiates, dispatches and
  coordinates Worklets mobile agents, to make local
  adaptations and more global reconfigurations
• Currently missing workflow notation, now just Java

17
(No Transcript)
18
Adding Architectural Model-based Analysis
Decision Capabilities

• Acme is a proposed standard architecture
  description language (CMU, Teknowledge, et al)
• Extensible with various annotation schemes, e.g.,
  for architectural styles and constraints
• Dynamic Acme will explicitly model architectural
  changes and monitor style/constraint compliance
• Infer architectural descriptions from observed
  application behavior
• Map architectural model repairs into
  implementation level modifications
• Construct architecture-based repair strategies
  and translate into repair tactics managed by
  workflow engine and accomplished by effectors

19
(No Transcript)
20
(No Transcript)
21
Progress

• Multiple probe technologies interchangeable with
  common API
• ProbeMeister (OBJS) instruments Java byte code
• Instrumented Connectors (Teknowledge) instruments
  DLLs
• Currently integrating multiple gauge technologies
  with common API

22
Next Steps

• Define strawman decision control API,
  disseminate, iterate
• Architectural modeling throughout
• Architecture-based probe placement
• Generate Gauge templates from Acme
• Augment Acme with architecturally significant
  implementation-level events (ASILEs)
• Choose or develop workflow interchange language
  between Tailor (CMU) and Workflakes

23
Expected Contributions

• Approach to autonomizing legacy systems and
  systems of systems
• Common autonomic infrastructure that can easily
  be internalized
• Standard schemas and APIs for probe, gauge and
  decision layers
• Reference implementation

24
Conclusions

• Peek at what the software engineering research
  community is doing towards Autonomic Computing
• Focus on legacy systems and systems of systems as
  well as methodologies and technologies for
  building new systems from scratch

25
(No Transcript)
26
Common Themes Across PSLs Other Related Research

• Decentralized Processes (Workflows)
• Contextualization
• Alliances (Treaties and Summits)
• Survivability and Multi-Level Security

27
Air-Force
Army
Navy
Shared services
DISCUS
Higher Security Summit
Imposing Treaties
Transportation
Lower Security Summit to alert
News-Media
28
Decentralized Information Spaces for Composition
and Unification of Services (DISCUS)

• Successor to OzWeb
• Builds on WebServices
• (Relatively) Static Service Spaces
• Dynamic Summits
• Gatekeepers impose Treaties as to whether/how
  Summits can use Service Space services
• Workflow coordinates services

29
(No Transcript)
30
Survivor 007
31
Survivor 007

• Successor to Survivor NG (Next Generation) built
  by modifying the Naval Research Labs MLS
  Workflow System
• Uses Worklets mobile agents to locate and recruit
  task processors dynamically and deliver tasks
  (including pumping, synchronization, compensating
  tasks)
• Multi-mirrored workflow state and data
• Considers possibilities of network partitioning
  and disabling of rogue task processors

32
(No Transcript)
33
Memento Real World
34
Memento Virtual World
35
Memento

• Successor to CHIME (Columbia Hypermedia IMmersion
  Environment) and AI2TV (Adaptive Interactive
  Internet Team Video)
• Project physical meeting spaces into 3D
  Collaborative Virtual Environment
• Project CVE information spaces into Large
  Displays other devices in physical spaces
• Continually augmented and reorganized contextbase
  using NLP and video summarization and clustering
  technologies

36
(No Transcript)
37
(No Transcript)