17
Dataflow Oriented Software Design in a FACE Architecture David Heath and Trevor Stittleburg Georgia Tech Research Institute

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

Embed Size (px)

DESCRIPTION

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?

Citation preview

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