Composable Distributed Realtime Systems

1
Composable Distributed Real-time Systems

• Krishnakumar B
• kitty_at_cs.wustl.edu
• Department Of Computer Science
• Washington University, St.Louis, MO
• Advisor Dr. Christopher D. Gill
• Funded by DARPA PCES under Contract to
• Boeing (F33615-00-C-3048)
• Washington University in St.Louis
  (F33615-00-C-1697)

2
Outline of Talk

• Components, Component Models
• Middleware Composition Challenges
• Solutions
• Future work
• Questions?

3
Project Synopsis

• Context
• Developing distributed real-time systems using
  components
• Problems
• Configuration information tied to implementation
• Context sensitive QoS specification
• No validation of QoS properties
• Ad hoc deployment
• Solution Approach
• Specify configuration as meta-data
• Decouple QoS specification from context
  dependencies
• Validate configuration
• Standardize deployment

Packaging Deployment
4
Overview of Components

• Component
• Encapsulated part of a software system
• Implements a specific service or set of services
• Components vs. Objects
• Multiple views per component
• Transparent navigation between views
• Extensibility without inheritance
• Higher-level Execution Environment

5
Properties of Component Models

• Component types, properties, inter-connections,
  interfaces
• Component run-time infrastructure
• Component Identity
• Underlying Object Model

6
CORBA Component Model

• Component Model specification from OMG
• Builds on strengths of CORBA
• Key elements
• Component
• Facets
• Receptacles
• Event Sources
• Event Sinks
• ComponentHome
• Container
• Component Server
• ORB Services

7
Component Integrated ACE ORB (CIAO)

• CCM implementation based on TAO
• QoS-aware Containers
• Introspection interfaces
• QoS assurance mechanisms
• Separate developer roles
• Application developer
• Component developer
• QoS provisioners
• ORB configurators
• Specify QoS as metadata

8
Motivating Application

• CORBA Event Channel
• Typical interactions
• I/O arrives
• Proxies demarshal data
• Facades process data
• Problems
• Numerous configuration options
• Configuration coupled with implementation
• No configuration validation
• Potential run-time failure

9
Problems Solutions
10
Configuration of Components

• Context
• Configuration of distributed real-time systems
• Problem
• Overwhelming options
• Configuration tangled with functionality
• Strong Coupling
• Ad hoc specification
• Interoperability problems
• Premature finalization
• Integration problems

11
Solution Configuration as Meta-data

• Meta-data
• Describes systemic properties
• Describe configuration as meta-data
• Separate configuration from functionality
• Use meta-language to describe meta-data
• XML provides a basis
• Ample scope for
• Customization
• Extension
• Increased interoperability

EventChannel
XML !
12
Solution Applied in CIAO
Default Handler

• CIAO uses ACEXML library
• Based on Simple API for XML (SAX) v2.0
• Callback-based API
• Low memory footprint
• Document Type Definition (DTD)
• Validating Parser
• Features
• DTD Validator
• XML Namespaces
• Locator
• Filters
• Extensible
• Pluggable Content Handlers

Client
2 create
1 extend
Content Handler
3 instantiate
4 register
ACEXML Parser
6 callback
5 read
lt?xml version"1.0"?gt ltdocgt ltparagtHello,
world!lt/paragt lt/docgt
XML File
13
Lessons Learned

• Specifying configuration as meta-data decouples
• Configuration information from functionality
• Act of configuration from functionality
• XML is very useful for describing meta-data
• Customizable
• Location transparent
• Allows out-of-band fetching of configuration
  information
• Interoperable

14
Problems Solutions
15
Context Aware QoS Specification

• Context
• Designing Components
• Multiple QoS assurance levels
• Different underlying middleware
• Problem
• Developers exposed to
• Different QoS features
• Different implementations
• Dependencies implicit

16
Solution Package Dependencies

• Identify dependencies
• External
• Internal
• Make dependencies explicit
• Describe dependencies extensibly
• Scope for standardization
• Third-party integration
• Check dependencies during component installation

Component A
ltltdependsgtgt
ltltdependsgtgt
ORB A
Component B
ltltdependsgtgt
ORB B
ltltdependsgtgt
ltltdependsgtgt
ltltdependsgtgt
libEvent.so
ltltdependsgtgt
libNotify.so
ltltdependsgtgt
ltltdependsgtgt
libSecurity.so
libPersistence.so
17
Solution Applied in CIAO (1/2)

• CIAO captures dependencies using XML Software
  Package descriptors
• Specification at multiple levels of granularity
• Individual implementation of same component
• Component level
• Package Level

ltsoftpkg name"EventChannelPkg" version"0.1"gt
ltpkgtypegtCORBA Componentlt/pkgtypegt
lttitlegtEventChannellt/titlegt ltdescriptiongtA
simple Event Channel test lt/descriptiongt
ltdependency type"DSO" gtltlocalfile
name"libTAO.so"/gt lt/dependencygt
ltimplementation id"EventChannel" gt ltos
name"Linux" version"4,0,0,0" /gt ltprocessor
name"x86" /gt ltcompiler name"gcc" /gt
ltprogramminglanguage name"C" /gt
ltpropertyfilegt ltfileinarchive name"eventchannel.c
pf"/gtlt/propertyfilegt ltcode type"DSO" gt
ltfileinarchive name"libService.so"/gt
ltentrypointgtcreateEventChannellt/entrypointgt
lt/codegt lt/implementationgt lt/softpkggt
18
Solution Applied in CIAO (2/2)

• META-INF
• Well-known descriptor file
• ACEXML parses META-INF
• CIAO
• Uses Pluggable Handlers features of ACEXML
• Implements SoftPkgHandler
• Dependencies checked during installation

CIAO
DefaultHandler
2 create
1 extend
SoftPkgHandler
3 instantiate
4 register
ACEXML Parser
ACEXML Validator
5 read
6 callback
META-INF
ltsoftpkggt ltimplementation id"EventChannel"gt
ltcode type"DSO" gt ltfileinarchive
name"libService.so"/gt lt/codegt lt/implementationgt lt
/softpkggt
19
Lessons Learned

• Dependency checking reduces run-time surprises
• Missing files within the package
• Local environment files needed
• Standard format needed for interoperability
• Different ORBs may use different methods to
  specify
• Dispatching models ?Thread pools, Reactive
• Concurrency mechanisms ?Mutex, Semaphores
• Different levels of filtering events

20
Problems Solutions
21
Component Misconfiguration

• Context
• Integration of application from COTS components
• Problem
• Large number of components
• Check individually
• Check overall system
• Manual integration
• Error-prone
• Doesnt scale

22
Solution Configuration Validation

• Validate component configuations
• XML allows specification of Document Type
  Definitions (DTD)
• Check configuration to ensure conformance to DTD
• QoS configuration validation should be done for
• Individual components
• Groups of components
• Application wide in an end-to-end fashion

mt
gt 1
EventChannel
reactive
gt1000
23
Solution Applied in CIAO

• Component Property Files (cpf)
• Supports specifying simple types, structs,
  sequences, valuetypes
• Set of valid configurations
• Validation done at deployment
• Minimize run-time failure
• Minimize run-time exceptions
• Allow static QoS provisioning

ECDispatching
PropertyFile
ECDispatchingThreads
ECProxyConsumerLock
Configuration Validation
ECConsumerControl
ECConsumerControlPeriod

• lt?xml version"1.0" encoding"UTF-8" ?gt
• lt!DOCTYPE properties SYSTEM "properties.dtd"gt
• ltpropertiesgt
• ltstruct name"ECProperties" typeEC_Property"gt
• ltdescriptiongt Configuration for a Simple
  Event Channellt/descriptiongt
• ltsimple name"ECDispatching" type"string"gt
  ltvaluegtmtlt/valuegt lt/simplegt
• ltsimple name"ECDispatchingThreads"
  typelong"gt ltvaluegt2lt/valuegt lt/simplegt
• ltsimple name"ECProxyConsumerLock"
  type"string"gt ltvaluegtbasiclt/valuegtlt/simplegt
• ltsimple name"ECConsumerControl"
  type"string"gt ltvaluegtreactivelt/valuegtlt/simplegt
• ltsimple name"ECConsumerControlPeriod"
  type"long"gt ltvaluegt50000lt/valuegt lt/simplegt
• lt/structgt
• lt/propertiesgt

24
Lessons Learned

• How to parse Hedge Automata
• Hedge is a sequence of trees
• An XML document is a Hedge
• Configuration validation helps reduce pilot
  error
• Currently ORB configuration is intricately tied
  to the Service Configurator
• Any configurable entity in the ORB is a
  ACE_Service_Object
• Only way to locate entities is from the
  Service_Repository
• Properties parsed from XML have to converted back
  to text to be re-parsed by Service Configurator

25
Problems Solutions
26
Deployment

• Context
• Deploying an application built using COTS
  components
• Problem
• Complex applications
• Large no. of components
• Micro-management of components
• Difficulty in reasoning complete end-to-end
  behaviour
• Manual deployment inherently error-prone
• Ad hoc scripts no better

27
Solution Component Packages

• Packaging
• Logical grouping
• Software Package
• Single Component
• Component Assembly
• Multiple components
• Groups components with
• Implementation
• Meta-data
• Dependencies
• Packages are deployed as compressed (.ZIP) files

28
Package Descriptors (1/2)

• Package descriptors
• CORBA Component Descriptor (.ccd)
• Describes a single component
• Interfaces, ports, QoS policies
• QoS properties described via (.cpf) files
• CORBA Software Descriptor (.csd)
• Describes implementations of a single component
• Useful in deploying a single component

ltcorbacomponentgt ltcomponentrepid
repid"IDLBookStore1.0" /gt ltcomponentkindgt
ltentitygt ltservant lifetime"component" /gt
lt/entitygt lt/componentkindgt ltsecurity
rightsfamily"corba" rightscombinator"secallright
s"gt lt/securitygt ltthreading policy"multithread"
/gt ltcomponentfeatures name"BookStore"
repid"IDLBookStore1.0"gt ltinheritscomponent
repid"IDLAcme/Store1.0" /gt ltportsgt
ltprovides providesname"book_search"
repid"IDLBookSearch1.0" facettag"1"gt
ltuses usesname"fedex_rates" repid"IDLShippingRa
tes1.0" /gt ltemits emitsname"low_stock"
eventtype"StockRecord"gtlteventpolicy
policy"normal" /gtlt/emitsgt ltpublishes
publishesname"offer_alert" eventtype"SpecialOffe
r"gt lteventpolicy policy"normal" /gt
lt/publishesgt lt/portsgt lt/componentfeaturesgt lt
/corbacomponentgt
29
Package Descriptors (2/2)

• CORBA Assembly descriptor (.cad)
• Describes a collection of components their
  properties
• Describes partitioning of the group of components
• Describes dependencies among components

ltcomponentassembly id"ZZZ123"gt
ltdescriptiongtExample assembly"lt/descriptiongt
ltcomponentfilesgt ltcomponentfile id"A"gt
ltfileinarchive name"ca.ccsd"/gt lt/componentfilegt
ltcomponentfile id"B"gt ltfileinarchive
name"cb.ccsd"/gt lt/componentfilegt
lt/componentfilesgt ltpartitioninggt
lthomeplacement id"AaaHome"gt
ltusagenamegtExample home for A componentslt/usagenam
egt ltcomponentfileref idref"A"/gt
ltcomponentimplref idref"an A impl"/gt
lthomepropertiesgt ltfileinarchive
name"AHomeProperties.cpf"/gt lt/homepropertiesgt
ltcomponentpropertiesgt ltfileinarchive
name"defaultAProperties.cpf"/gt
lt/componentpropertiesgt lt/homeplacementgt
lt/partitioninggt lt/componentassemblygt
30
Deployment Hierarchy

• Packages are read by Deployment agent
• Descriptor of package is read from META-INF
• Unpacking of packages in safe directory
• Avoid trojan implementations
• Action determined by contents of META-INF
• Set of Helper classes
• ComponentInstallation
• AssemblyFactory
• Assembly
• ServerActivator
• Used in bootstrapping deployment

ltltinstantiatesgtgt
AssemblyFactory
Assembly
ServerActivator
ltltinstantiatesgtgt
ComponentServer
ltltinstantiatesgtgt
Deployment Application
Container
ltltinstantiatesgtgt
CCMHome
ltltinstantiatesgtgt
ComponentInstallation
CCMObject
31
Lessons Learned

• Packaging makes component management easier
• Provides logical view of application subsytems
• Aggregates groups of components
• Provides COTS components in the literal sense
• Standardizing deployment
• Solves problem once
• Allows sharing of components
• Reduce footprint
• Lazy component loading using Virtual Component
  design pattern

32
Future Work

• Complete integration of Packaging Deployment
  framework with CIAO
• Decouple ORB configuration from Service
  Configurator
• Configuration of ORB from structs and sequences
• Allow imposing policies in a hierarchical fashion
  
• Measure overhead
• Increase user-friendliness of the Deployment
  framework

33
Timeline
34
Concluding Remarks

• Summary Of Benefits
• Specify configuration as meta-data
• Decouple QoS specification from context
  dependencies
• Validate configurations
• Standardize deployment
• Programming effort
• ACEXML
• Common infrastructure - 8K lines
• Parser Enhancements - 3K lines
• Validator - 6K lines and growing
• Available under ACE_ROOT/ACEXML
• Packaging Deployment
• 4K lines
• Available under ACE_ROOT/ACEXML/compass
• Availability
• cvs co r Validator ACE_wrappers/ACEXML
• cvs co r CIAO ACE_wrappers
• First release early 2003

35
Acknowledgements

• Dr. Chris Gill
• Dr. Ron Cytron
• Dr. David Levine
• Dr. Doug Schmidt
• All past and present members of the DOC group