Transcript
Page 1: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Dataflow Oriented SoftwareDesign in a FACE™

ArchitectureDavid Heath and Trevor Stittleburg

Georgia Tech Research Institute

Page 2: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Motivation

• FACE architecture encourages modularity of components on data boundaries

• Transport Services Segment interface is centered on sending and receiving typed data

• Naturally fits with ‘dataflow-oriented’ software design

Page 3: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Motivation

• Much of implementing a FACE architecture is data movement

• Transport Services Segment data is described by a data model

• I/O Services Segment can share some transport mechanisms with Transport Services

• What are some ways we can apply software engineering to make the architecture implementation robust?

Page 4: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Dataflow Abstractions

• Minimal aspects of a dataflow :• Allow configuration of source/destination• Support opening/closing• Provide capability to read/write

• Abstract this idea as a class which can be implemented in many ways

Page 5: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Channel

• Channel class• Implemented by specific transport mechanisms• Can be used in Transport Services, I/O Services, or within

a component

Page 6: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Transport Services Segment

• Transport Services Segment is intended to be configurable at initialization (change transport mechanisms)

• Each TSS Connection uses a configured channel• Sending/receiving data can be separated from other logic using

a Channel• At initialization, the correct channels are created based on

configuration

Page 7: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

I/O Services Segment

• I/O Services Segment (IOSS) also lends itself to using Channels to handle different data flows

• I/O Services can be implemented as direct or distributed• Direct I/O services are accessed directly via the I/O

Services API in the same address space as the component• Distributed I/O services are accessed via inter-process

communication and allows a service to exist as a process used by multiple components

Page 8: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

I/O Services Segment

• Direct and distributed I/O interfaces can be abstracted as Channels in the implementation

• Devices can be configured as using direct or distributed I/O without rebuilding the component

Page 9: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Channels

• I/O Services Segment and Transport Services Segment can use shared channel code for some types of data transport

• Channels can also be used by components to access the FACE APIs

• Problem: Accessing the I/O Services Segment requires construction of I/O message headers and bus-specific headers

Page 10: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Refinements

• Refinement Abstraction• Alter the behavior of a channel to provide it with new functionality• Example: Delay Refinement causes a channel to wait before

performing a read/write

Page 11: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

I/O Access Channel

• Component reads/writes to an IOS Access Channel which uses refinements to prepend the appropriate headers and call the I/O API

• Simplifies using the IOSS and enables code reuse

Page 12: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

TSS Access Channel

• Similarly, the TSS API can be called via a Channel to further separate business logic from data movement concerns

• Allows combining TSS data with other dataflow like logic

Page 13: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Another Abstraction

• Treating dataflows using a generator pattern (source of iterable data) can simplify processing and separate error handling from other logic

• Error handling is encapsulated in an ErrorStrategy

• Generator uses a Channel combined with an ErrorStrategy as its data source

• ErrorStrategy determines message validity and it can be sent on to a data sink if appropriate

Page 14: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Another Abstraction

• Two ‘generators’ can be combined into a Transformer• An input generator is used to get data, the Transformer

modifies that data and returns it with next()

Page 15: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Example Use

• Getting waypoints from the TSS, checking constraints, and sending it to a destination in a Flight Plan

• Separates business logic (constraint checking), data error handling logic, dataflow to and from TSS

Page 16: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Summary

• The FACE architecture is data-centric

• Implementing the architecture and component can be greatly simplified by embracing this

• Utilizing and configuring FACE architecture is also simplified with the dataflow approach

...This does not fit everywhere though!

Page 17: Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving

Thank You

• Thank you for this event!

• AMRDEC

• The Open Group

• NAVAIR PMA 209

• FACE Consortium