System Composition in OneSAF

1
System Composition in OneSAF

• Derrick Franceschini
• Derrick.J.Franceschini_at_saic.com

2
Outline

• Defining the Problem
• Problem Requirements
• Problem Scope
• Defining the Alternatives
• Composition Criteria
• Candidate Technologies
• Defining the Approach
• OneSAFs Approach Overview
• Characteristics
• System Implications
• Defining the Status
• Current Progress
• Ongoing Efforts

3
Does OneSAF Need Composability?

• ORD 4.14.5 Composability
• OneSAF will be open, scaleable (space, time, and
  unit), extensible, and flexible to provide for
  the development of a system that can be
  maintained and evolve as OneSAF operational needs
  change.
• OneSAF must provide the user through a graphical
  user interface the capability to
• uniquely compose entities (e.g., tank from a
  hull, turret, armament, sensor, track, etc.),
  uniquely compose behaviors utilizing primitives
  for individual combatants/platforms and units
  (teams, squads, platoons, etc.),
• uniquely compose the application
  (models/algorithms with varying fidelity,
  simulation environment with varying levels of
  resolution for terrain and weather,
• uniquely compose the system (federate,
  standalone, (non-) distributed, time management,
  etc.).
• The objective is that OneSAF may be uniquely
  composed for specific applications.

Battlespace
Either orboth
System
4
Problem Scope

• What is not considered composition?
• Parametric approaches are not composition
  (parameters and data files)
• The boundary is defined by scope of the effect
• Parameterization affects the scope of the model
• Composition affects the scope of a collection of
  models
• OneSAFs use cases demand certain levels of
  composition
• Fully DES style analytical simulations require
  one type of system
• Time stepped and hybrid systems require yet
  another
• Composition is required to address variability of
  system objectives
• ACR, RDA, TEMO needs
• Objectives tend to drive everything else

5
OneSAF Composition Approach Overview

• Three main parts
• System Composition
• Describing the constituent components,compositions
  , and their relationships that are available for
  execution within OneSAF
• Product Composition
• Describing the constituent components,compositions
  , and their relationships of an executable
  product available for execution within a OneSAF
  system
• Battlespace Composition
• Describing the constituent software objects,
  data, and their relationships that makeup an
  executing model

6
Scope - Architectural Hot Spots

• Composition addresses several key architectural
  hot spots
• Resolution/Capacity Tradeoffs
• Some users need high resolution models for
  weapons effectiveness studies
• Some users can use low resolution models for
  increased entity count
• Scheduling Techniques
• Some users need to run repeatable, non-HITL,
  non-distributed
• Some users need to run distributed, networked
• Export Control
• Some components are export controlled
• Hardware dependencies
• Some capabilities will rely on specific hardware
  availability
• Remainder of users should not be impacted by lack
  of availability
• Maintenance of User Extensions
• Users will create custom extensions
• Some will be accepted into OneSAF baseline for
  maintenance
• Others will not, but will still be able to be
  executed
• Dynamic Composition Loading

7
Scope - Component Granularity

• Component composition granularity can vary
  between different complexity levels
• For example, a simple HITL simulation might vary
  over
• Random Number Generators
• Time Manager Policy
• High Definition Ballistic Models
• Ballistic Model Proxy
• High Definition Movement Model
• Movement Model Proxy
• Vehicle Model
• 2-D viewer
• Vehicle Controller
• Distribution (HLA, DIS interface)
• This shows composition over algorithms, services,
  policies, and tools

8
Component Granularity

• We expect to have more Software Components than
  the Product Line Architecture Framework (PLAF)
  specifies
• We want to take advantage of finer granularity,
  more opportunities for reuse
• We expect our Software Components wont match
  one-to-one to PLAF components
• The PLAF specified requirements, the
  implementation maps to requirements
• We expect a many-to-many mapping
• Some PLAF components may decompose into multiple
  SW components
• For finer granularity, Simulation Services is
  componentized into additional time management
  components that can be configured into an
  application
• Some software components or services might map to
  multiple PLAF components
• A unified SSDE/MCT software component may satisfy
  both SSDE and MCT PLAF component requirements

9
What Is Expected From System Composition?

• Ability to easily construct custom software
  applications
• Even users
• Ability to configure the system with custom
  features or user interfaces
• Ability to trade components with different
  resolution/fidelity/capacity
• Ability to control what software is included in
  an instance of OneSAF
• Ability to manage hardware dependency limitations
• Ability to maintain user extensions
• Ability to support advanced capabilities, such as
  changing the system on the fly
• To help avoid the Big Ball of Mud
• http//www.laputan.org/mud/mud.html

10
Scope - OneSAF Users

• The requirement to be composable in the context
  of a Product Line has an interesting affect on
  use cases
• It expands users of the system into new realms
• Maintenance and development now become a use case
  for OneSAF
• Developers, extenders, and maintainers are now
  users of the system
• This is different from the classical view of CGF
  systems

11
PLAF Requirements View of Components
Leader and Staff Mission Rehearsal System
Composition
Mission Area Applications (OneSAF
System Compositions)
Leader and Staff Training System Composition
Leader and Staff MOUT Training System Composition
Stimulator for Virtual Simulations System
Composition
Test and Evaluation Support System Composition
Standalone Analytic Simulation System Composition
Other System Compositions

OneSAF Product Layer
OneSAF Component Layer
System RepositoryServices
GUIServices
SimulationServices
Sim. ObjectRuntimeDatabase
CompositionServices
Modeling Services
EnvironmentRuntimeServices
EnvironmentReasoningServices
Plan ViewDisplay
3D Viewer
OneSAF Component Support Layer
OneSAF Repository Component Layer
System Composition Repository
Military Scenario Repository
EnvironmentRepository
Parametric Initialization Repository
SoftwareRepository
Simulation Output Repository
KA/KERepository
Monitor Services
Time Services
Messaging Services
Interchange Services
Name Directory Services
ORB
JDBC/ ODBC
WWW
Live Range Adapter
Coordinate Services
DIS
RTI
Middleware Services
Common Services Layer
Platform Layer
Hardware
Operating System
Network
PLAF v. 16
12
OneSAF Product Line Concept

• System Composition Services, based on compatible
  Product and Component meta-data, enable OneSAF
  Components to be composed into OneSAF Products,
  which are configured and distributed to form
  particular System Configurations
• From the Product Line repository of Products and
  Components, an open ended number of tailored
  System Configurations are possible

OneSAF Product Line Repository
Product 1
Product 2
Product 3
Component A
Component C
Component E
Component B
Component D
Component F
System Composition Services
System Configuration 1
System Configuration 2
System Configuration 3
. . .
Product 1
Product 2
Product 1
Product 2
Product 3
A
B
B
D
A
C
C
C
F
C
E
E
E
E
13
Mission Area Applications and Products
Test and Evaluation Support Tool (03)
LS Training Tool (03)
LS MOUT Training Tool (02)
Others (04)

LS Mission Rehearsal Tool (07)
Stimulator for Virtual Simulations (06)
Standalone Analytic Simulation (05)
Others (08)

Military Scen. Planner (10)
System/Model Composer (11)
Simulation Generator (12)
Each unique OneSAF Application requires
Products,each potentially internally composed in
different ways,and each potentially externally
composed in different ways.
Tech Manager (13)
Simulation Core (14)
Simulation Controller (15)
C4I Adapter (16)
AAR (17)
Repository Manager (18)
Maintenance Environment (19)
14
Requirements View of Composition Examples
OneSAF
OneSAF
ModelComposer
SimGenerator
TechManager
SimCore
SimController
Analysis Review
EventPlanner
EventPlanner
vs.
Unit Composer
SSDE
SCT
Ground Dynamics
MCT
AAR
MSDE
MSDE
EDGE
Behavior Composer
DCST
FDT
RWA Dynamics
SAMT
DC
SimCore
SimCore
SimCore
SimCore
vs.
Sim Servicesw/ Real TimeScheduling
Sim Servicesw/ AFAPScheduling
GroundDynamics
GroundWeapons
GroundDynamics
GroundWeapons
vs.
RWADynamics
RWAWeapons
FWADynamics
FWAWeapons
15
How is this Implemented?

• Componentware is our implementation strategy for
  the development of a composable Product Line
• Develop reusable assets as components
• Combine these components (compose) in interesting
  and unique ways

D1
D2
A
B
C
16
Composition Alternatives

• Considered approaches from commercial industry to
  proprietary
• Defined evaluation criteria
• Based on immediate needs as derived from the
  OneSAF ORD
• Based on forecasted needs
• Performed an assessment of the approaches

17
Approach Criteria

• Cross platform support
• Multiple language support
• Support for dynamic composition
• Ability to introspect at runtime
• Component granularity support
• Ability to discover components at runtime
• Ability to swap components at runtime
• Level of decoupling supported
• Scope of acceptance

18
Composition Approach Choice

• JavaBeans based approach
• Most promise due to its adaptability
• By itself, JavaBeans has limitations
• Combination with network services mitigates
  limitations
• Direct support by the language of choice
• Offers homogeneous and more tightly aligned
  choice
• Other industries have embraced this approach and
  its derivatives
• Supports low programmer impact through
  pay-as-you-go approach
• Small requirements to become a component
• More capabilities can be added to enhance the
  quality of component-ness
• Can be adapted to other languages
• C wrapping
• Allows support for composition and distribution
  of rich objects
• The key limitation is that it requires developer
  discipline in making assumptions explicit

19
System Composability Implementation

• Components
• Java Beans, with extensions
• Composition
• System Composer Tool
• Based on Java Bean Box
• Why Java Beans?
• Its is the obvious standard choice, given
  OneSAFs primary implementation language
• Leverage commercial standard
• We can extend the approach to get the extra
  capabilities we want
• Meta-data
• Services for component management

20
What are Java Beans?

• The goal of the JavaBeans APIs is to define a
  software component model for Java, so that third
  party ISVs can create and ship Java components
  that can be composed together into applications
  by end users.
• A Java Bean is a reusable software component
  that can be manipulated visually in a builder
  tool.
• Java Bean Specification, 7/24/1997

21
Requirements on a Component

• Components can be made available to the
  composition in many ways
• As a component file
• Using component interface as wrapper over legacy
  object
• Through network (e.g. CORBA, HLA) (future)
• Must provide meta-data information
• Description
• Validation authority and status
• Resource requirements
• Dependencies
• Version

22
Requirements on a Component (cont.)

• Top-level class must be a JavaBean
• Must use JavaBean design patterns
• Must be serializable
• Events
• Events and handlers must subclass
  java.util.EventObject and java.util.EventHandler
• Must use pattern for registration method names
• Must explicitly use Component Manager to get
  references to other components

23
Requirements on a Component (cont.)

• Must have have a zero-argument constructor
• Allows construction without explicit knowledge of
  component requirements
• Component Manager supplies other required handles
  on request
• Initialization of data based on access to
  repositories
• If a component file, must be valid
• Valid JAR file
• Contain metadata.xml file
• XML in meta-data file must validate
• Relationships between entries in metadata.xml
  file and Java classes must be consistent
• Any BeanInfo classes must match classes present
  in file

24
Composition The Big Picture

• System Composer Tool
• Assembles components into compositions
• Components
• Reusable software pieces that can be assembled
• Implemented as Java Beans
• Bean rules
• Properties
• Delegation event model
• OneSAF Extension Broadcast events
• Component interface design choices
• Extended with meta-data
• Compositions
• Assemblies of components, loaded by a Run-time
  Loader, managed by a Component Manager
• System Composition Repository
• Home for built components and assembled
  compositions

25
Typical Composition Object Set

• Objects involved in representative applications
• Composer
• Component Manager
• Component Repository
• Validator
• Component Repository (Optional, if wanting to
  check dependencies)
• Runtime
• Component Manager
• Component Repository
• Event Bridge/Proxy Manager

A key design benefit is that you do not need the
entire system or the entire component
architecture to perform component/composition
operations
26
Composition Context Diagram
Instantiate, manage, monitor
Component Manager
Modify
Network Interface
Network Interface
System Composer Tool
Requests Instancing
A Composition
Dynamic Proxy
Event Bridge
Selects Composition
Component
Describe Persist
Run-Time Loader
Component
Component
Direct Reference
SCR
Describe
Component
Proxy Component
Composition Specification
Component
Event
An Application composed out of a collection of
components.
Component
Component
Component
Proxyed Component
27
Specifying Components

• Three types of formats used to specify components
• Component specification defines the parts
• Meta-data specification defines the attributes
• Composition specification defines the
  collection of components, compositions, and their
  relationships
• Component Specification
• Single file container for code and data for
  purposes of transport and containment
• Standardizes extensions to JAR file format
• Can be manipulated using standard JAR tools
• Zip, Jar
• Can be cryptographically signed to support
  validation using standard JAR tools
  (post-distribution modification obvious)

28
Specifying Components (Cont.)

• Meta-data Specification
• Describes component and composition properties
  without instancing the component
• Implemented as an XML Specification (XML Schema)
• Contains author, validation authority,
  dependencies, version, performance attributes,
  description
• It allows tools to examine and manipulate
  components in compositions without needing to
  instantiate the code
• Greatly reduces the complexity and infrastructure
  necessary for component manipulation during
  composition
• Composition Specification
• Describes the components in a composition
• Implemented as an XML Specification (XML Schema)
• Can be configuration managed separately from
  components.

29
Component JAR
SomeComponent.jar
Meta-data Specification

• (OneSAF) Software Component
• An extension of a Java Bean that includes
  descriptive meta-data and abides by the OOS
  Component guidelines
• Tool Software Component
• A Software Component that provides end-user
  visible functionality
• GUI Tool Software Component
• A Tool Software Component that has a Graphical
  User Interface
• Software Component Jar
• A built (compiled) Software Component, put into a
  Jar file with the required descriptive meta-data,
  and perhaps digitally signed

Manifest
------------- --------- ------------ -------- ----
---
Native Code (optional)
File 1
Code Class
File m
Code Class
Code Class
Code Class
File n
Component Local Data (resources, images, sounds)
Component Local Data (resources, images, sounds)
30
Is Everything in OneSAF a Component?

• Software Service
• One or more packages of software advertising an
  API that can be called by other software (e.g.,
  ECS), and which hasnt been implemented or
  bundled as an OOS SW Component
• Software Service Jar
• A built (compiled) set of Software Services, put
  into a Jar file. Some Software Service Jars may
  be provided from external sources, while most are
  built from OneSAF source code

SomeSWService.jar
Manifest
------------- --------- ------------ -------- ----
---
Native Code
(optional)
File 1
Code Class
Code Class
File m
Component Local Data (resources, images, sounds)
Component Local Data (resources, images, sounds)
File n
31
Example Compositions (Implementation)
Sim Core SW App
DCST Testing SW Application
DCST
SAT
PhysicalAgents
BehaviorAgents
PrimitiveBehaviors
MI Framework Components
Desktop
System RepositoryServices
SimulationServices
System RepositoryServices
CoreGUI Services
GUI Common Component Framework
Time Manager Synchronized
SRS CheckpointServices
Model Composer-Only SW App
Sim Core SW App
EntityComposer
UnitComposer
PhysicalAgents
BehaviorAgents
PrimitiveBehaviors
BehaviorComposer
EnvironmentComposer
MI Framework Components
Desktop
System RepositoryServices
SimulationServices
System RepositoryServices
CoreGUI Services
GUI Common Component Framework
Time Manager Independent
SRS CheckpointServices
32
System Composition and Installation
Composing a System Composition
SystemComposerTool
Preparing anInstallationPackage
SystemDistributionUtilities
33
System Composer
34
OneSAF Composition Accomplishments

• To date, 59 OneSAF Components have been
  implemented
• Granularity
• Fine Random Number Generator and Simulation
  Scheduler algorithms
• Medium Desktop
• Coarse Management and Control Tool
• All OneSAF Applications in Block Release are
  composed (except System Composer)
• Conducted internal developer training sessions
  for Composition Approach education

35
System Composition Ongoing Efforts

• Current effort for composing the Users and
  Maintenance Manuals appropriate to a System
  Composition
• Current effort for composing the Instance
  Analysis Data Model appropriate to a System
  Composition

36
Credits

• Special thanks to the developers of this work
• Gene McCulley
• Stephanie Graffuis
• Kurt Hawkes
• Chris Otto
• PM OneSAF