More Related Content Similar to Extending Container Services through Connectors in the F6COM Case Study Similar to Extending Container Services through Connectors in the F6COM Case Study (20) 1. 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.
2. 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 © 20132
3. 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 © 20133
4. 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 © 20134
5. 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 © 20135
6. 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 © 20136
7. 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 © 20137
8. 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 © 20138
9. 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 © 20139
COMPONENT
Parameters
State
Resources
Callbacks
(Periodic)
callbacks
Resource
needs
Observable
state
(A)Synchronous
call/return
ReceptacleFacet
Anonymous
publish/subscribe
PublishSubscribe
Configuration
10. 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 © 201310
11. 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 © 201311
Component Executor
(Business Logic)
Container
Service
Connector
Service
Connector
Service
Connector
Service
Connector
Component
12. 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 © 201312
13. Component Messaging
Framework
Copyright © 201313
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
ComponentMessage
Queue
14. 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 © 201314
15. 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 © 201315
16. 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 © 201316
CORBACOMPONENT RMI4CCM
17. 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 © 201317
18. 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 © 201318
19. 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 © 201319
