F6COM: A Case Study in Extending Container Services through Connectors
-
Upload
remedy-it -
Category
Technology
-
view
676 -
download
0
Transcript of F6COM: A Case Study in Extending Container Services through Connectors
F6COM: A Case Study in Extending Container Services
through Connectors
Abhishek Dubey, Andy Gokhale, Gabor Karsai, William R. Otte; Vanderbilt University/ISIS
Johnny Willemsen, Marcel Smit; Remedy IT Paul Calabrese, Adam Mitz; OCI
This work was supported by the DARPA System F6 Program under
contract NNA11AC08C.
What is F6?
Future, Fast, Flexible, Fractionated, Free Flying Spacecraft A cluster of small satellites replaces one large monolithic satellite Advantages: • Flexible related to design and acquisition • Less expensive in developing and launch • Highly adaptable and survivable in orbit
Copyright © 2013 2
Objectives F6 Program
Key objective: define open interface standards for hardware and software Objective: develop an API definition as an abstraction layer on top of a partitioned OS Objective: demonstrate that the F6 architecture is suitable to develop and deploy a cluster of wirelessly connected satellites
Copyright © 2013 3
Techniques
Partitioned OS with an F6 OS API applied Secure Transport CORBA and DDS as middleware Lightweight CCM as Component framework • DDS4CCM/AMI4CCM • Container Service Connectors
D&C as Deployment and Configuration framework
Copyright © 2013 4
F6 Challenges
Distributed systems with addressable network Highly variable network quality and availability • satellite internal • satellite ↔ satellite • satellite ↔ ground (via 0..* hops)
Dynamism Resource sharing/slicing Fault tolerance Multi-level security
Copyright © 2013 5
F6 OS
All send/receive operations are time bounded Different security levels for each type of actor • Application actors • Platform ('service') actors
Messaging • Interaction between components based on
messages only • Messages contain security labels • Messages are facilitated by a 'Secure Transport'
Copyright © 2013 6
F6 OS
Resource management functions • CPU time: temporal partitioning for actors • Memory: spatial partitioning • Network bandwidth: bandwidth budget,
differentiated routing Part of the Trusted Computing Base (TCB)
Copyright © 2013 7
F6 Middleware
Subset of CORBA • Synchronous and asynchronous call/response
semantics • TAO is used as implementation
Subset of DDS • Anonymous publish/subscribe semantics
One-to-many Many-to-many
• Data Centric Publish/Subscribe (DCPS) • Static discovery • openDDS is used as implementation
Copyright © 2013 8
F6 Component Model (F6COM)
(A)synchronous communication via ports Configuration parameters set at deployment time History of component state via 'State Variables' Fixed resource allocation (A)periodic invocations F6COM is based on
LwCCM
Copyright © 2013 9
COMPONENT
Parameters
State Resources
Callbacks
(Periodic) callbacks
Resource needs
Observable state
(A)Synchronous call/return
Receptacle Facet
Anonymous publish/subscribe
Publish Subscribe
Configuration
F6COM challenges
The component developer must rely on a single-threaded, non re-entrant runtime Leverage the CORBA RMI paradigm to a connector • LwCCM becomes middleware agnostic => UCM
Standardized way of using timers which don't compromise the single threaded, non re-entrant requirement Use of IO within a component framework
Copyright © 2013 10
Service Connectors
'Singleton' connector fragment in a container Deployable entity Provides services to all components and connectors in a container Examples: • Timer connector • Container-level fault management
Copyright © 2013 11
Component Executor (Business Logic)
Container
Service Connector
Service Connector
Service Connector
Service Connector
Component
Component Messaging Framework
Separation between the incoming triggers and the Component Executor (business) code Two Container Service Connectors: • Component Message Queue Manager • Component Message Dispatcher Manager
Various queuing and threading policies supported • F6COM: one thread (queue) per component
Fully generated by the RIDLC compiler Hidden from the component developer
Copyright © 2013 12
Component Messaging Framework
Copyright © 2013 13
Framework Operations
Component Framework
Dispatch Component Message Object
(subject to component scheduling policy)
Component Executor (Business Logic)
en-queue Component Message Object
Call Path (forward)
Call Return Path
Framework Operation
Timeout (sec)
Component Operation
Deadline (sec)
Priority [0..99]
Component
Com
pone
nt M
essa
ge
Que
ue
The Component Message Queue
Provided by the Component Message Queue Manager Connector fragment The Service Connector makes sure that every component is assigned a Component Message Queue Operation-specific objects are queued Priorities and deadlines per operation specific object • Can be controlled using the deployment plan • Can be set at component, connector, port, and
operation level
Copyright © 2013 14
The Component Message Dispatcher
Started by the Component Message Dispatcher Manager Connector fragment The Service Connector makes sure that every component is assigned a Component Message Dispatcher Various dispatching policies supported • F6COM: one dispatch thread per component
Dispatches operation-specific objects from the CMQ Executes the operation specific object in the context of the component executor Basic deadline monitoring is available • Extended to a Deadline Monitoring Service Connector
Copyright © 2013 15
The RMI connector (RMI4CCM)
Deployable entity Hidden from the component developer Fully generated by the RIDLC compiler Respects the single-threaded, non re-entrant requirement Makes LwCCM middleware agnostic CORBA is currently supported
Copyright © 2013 16
CORBA COMPONENT RMI4CCM
Timer Service Connector (Timer4CCM)
A Timer Service Connector fragment Sporadic (one-shot) and periodic timers are supported Component developer implements predefined callbacks Timer callbacks are scheduled within the CMQ after expiration
Copyright © 2013 17
IO-connector (IO4CCM)
Standardized interaction with other systems • Socket/stream based (TCP) • Socket/datagram based (UDP) • Device drivers (ioctl)
No need to implement low-level interaction code Respects the single-thread, non re-entrant requirement Blocking IO does not block component business logic • IO connector notifies components of available data
Copyright © 2013 18
Summary
Service connectors provide a powerful mechanism to extend container services in a standardized way: • Threading • Operation scheduling • Timers • IO handling • Error detection and mitigation
The RMI4CCM connector makes the Component Framework middleware agnostic F6COM is a big step towards a
Unified Component Model
Copyright © 2013 19
QUESTIONS ?
Copyright © 2013 20
References
http://en.wikipedia.org/wiki/Fractionated_spacecraft http://www.darpa.mil/Our_Work/TTO/Programs/System_F6.aspx http://www.isis.vanderbilt.edu/projects/F6 http://www.remedy.nl/en/portfolio/87-darpa-system-f6-program
Copyright © 2013 21