Reactive Fabric Technology for iOS, OSX (and Linux)

1. The Reactive Fabric Software Technology Redress.

Reactive Fabric addresses the issues of:

• Software complexity.
• The visualisation of software design.
• Group design collaboration and iterative design evolution.
• The unification of design and implementation, so that design and implementation mirror each other.

We all have experienced the explosive growth of expectation on software and in turn, the underlying growth of code complexity. Modern software is expected to be more than just a collection of synchronous calculations, a collection of simple event handlers. The modern expectation, is more towards a multi-connected, asynchronous, adaptive, organic system.

Reactive Fabric addresses complexity by simplifying and streamlining the whole software design process by depicting design in a visual medium. As a visual, it can be collaborated, iteratively evolved and reviewed. Whole system issues are addressed at the design level before having to go through an implementation cycle.

On the implementation level, design elements are directly mapped to processing elements (implemented in the Reactive Fabric SDK). Thus there is a one-to-one mapping between design and processing elements.

Another important aspect of Reactive Fabric is LOD (Levels of Detail) in Design. Macro behaviour is designed separately from lower (say Micro) behaviour. Macro behaviour addresses whole system management behaviour whereas Micro behaviour embodies low level control and action.

2. Reactive Fabric Design Elements.

Reactive Fabric elements are referred to as RfElements and these processing elements operate on data message quanta called RfNotifications. RfElements are organised into a number of patterns that reflect how they handle notifications:

• The Source pattern (RfSource)
• The Operator pattern (RfOperator)
• The Collector pattern (RfCollector)
• The Service pattern (RfService)
• The Socket pattern (RfSocket)
• The Subsystem pattern (RfSubsystem)

Sources for example, create RfNotifications, operators operate on notifications and collectors collect notifications (and presumably act on them). RfElements are interconnected by transport paths to provide for a directed flow of RfNotifications. Typically, RfNotifications embody an event together with the data associated with that event. It is an encapsulation of event-data. Examples include: the reception of a network packet together with the packet data, an error with the error details, a change in system state with details of the state change, a generated timed event with a timestamp, a change in the system environment such as low battery with the current battery level, etc.

It terms of the whole system, the connected graph of RfElements forms a fabric that represents the system behaviour. This architecture of Processing Element-Transport Path-Notification reflects a natural design principle found in nature, with analogues in chemical messaging of organic systems, electrical pulses in nervous systems and neural axon electrochemical messaging.

3. Example of a Design.

Below is a design for system to present Drone telemetry on a display. This design is a mixture of high LOD (with system management) and low LOD (with protocol decoding and view models). Rectangles represent RfElements (annotated with their pattern), lines represent RfNotification transport paths and white text boxes depict the list of defined RfNotifications for that transport path. Green arrows represent RfNotification requests and Red arrows represent replies.

Summarising the design: The Drone Supervisor (Service) hands a network data channel to the Drone Protocol Decoder (Socket), which then reads from the channel and emits observed telemetry events to the Telemetry Tracker (Operator). The Tracker monitors changes in Telemetry features such as position, velocity, flight status, etc and when a feature changes, emits the change to the View Model (Operator). The View Model is responsible for graphic representation and emits a series of drawing commands bundled in a drawing session to the View Controller (Collector) which in turn draws using OS Presentation Services.

Error handling is performed by the Drone Supervisor. It reacts to network errors (as notified by the Network Service), network data (channel) errors and drone protocol problems (as notified by the Drone Protocol Decoder).

4. The Reactive Fabric SDK.

The Reactive Fabric SDK (written in Swift 5) forms the implementation framework for the projection of the design elements (in the visual design space) into the code space. Each design element is expressed as a Swift class. The element class then can be sub-classed to provide custom behaviour. So a custom RfSource element class inherits from the RfSource class and overrides notification handling to generate the relevant RfNotifications.

Other features included:

• The SDK is instrumented to allow for tracing of RfNotifications produced/consumed by RfElements. Standard tracing to OSLog/print is provided with the trace() operator and custom tracing is also supported.
• The SDK provides substantial source code examples of sources, operators and collectors that comprise the general Reactive Extension library (e.g interval, throttle, timer, distinctUntilChanged, zip, etc).

5. Synchronous and Asynchronous Evaluation.

Reactive Fabric uses a high level Evaluation Queue model rather than a low level locking and threading model. This greatly simplifies code while maintaining performance. The Evaluation Queue is used to evaluate a defined Reactive Fabric expression and the associated evaluation thread can be chosen from:

• Inline: The evaluation queue uses the calling thread to perform evaluation (and so blocks the caller). This is pure synchronous evaluation.
• Sync: The evaluation queue uses a new thread for evaluation but blocks the caller.
• Async: The evaluation queue uses a new thread to perform evaluation and does not block the caller. This is pure asynchronous evaluation.

All synchronisation and threading is handled by the Evaluation Queue. Custom code within an RfElement only needs to consider synchronisation when the RfElement is producing/consuming to/from multiple expressions and then it is a matter of notifying in the appropriate Evaluation Queue.

6. Testing and Simulation of Reactive Fabric Expressions.

By its intrinsic nature, RfElements provide separation and decoupling which can be utilised in simulation and testing. Individual RfElements can be unit tested by generating input notifications and verifying output notifications. Expressions and whole subsystems can be tested for behaviour again by generating and verifying notifications. Test rigs can be created to generate test data and verification elements can be authored to verify. Realtime RfNotifications can also be captured and then used to drive simulations and tests.

Here is an example behavioural test rig for the Drone Telemetry System, testing the expression for Drone Protocol Decoding to View Controller generation.

The Test Rig Supervisor (Source) supplies test run data (i.e. network data packet with the expected drawing commands for that packet data) to the Test Run Supervisor (Service). It in turn starts a test run session with the View Control Recorder/Verifier and then creates a virtual data channel with the packet data and hands that over to the system Drone Protocol Decoder. When it is notified of the end of the drawing session (by the Telemetry View Controller Recorder/Verifier), it issues an end of session to the View Control Recorder/Verifier and requests it to verify what was recorded with the expected results it supplied in the notification. It then gets back a reply for the verification. All this can be expressed in a marble sequence diagram:

The test packet data can either be synthesised (generated) or replayed from actual session captures.

Test rigs can also be used to measure performance limits, such as screen (View Controller) refresh rates. If telemetry notification is found to overwhelm video bandwidth, then a throttling RfElement can be inserted to restrict telemetry notifications to acceptable levels. Throttling can also be intelligent, choosing the type of telemetry events to pass and which to prune.

7. Benefits of Reactive Fabric.

Design and development in Reactive Fabric requires a different mindset than classical synchronistic sequential programming. The system is conceived as a propagation of notifications through a fabric, similar to the propagation of waves through water channels. It operates in realtime and only handles what is required when required. Reactive Fabric is not necessarily applicable to simple systems but for medium to complex systems it provides:

• A unified architecture across vertical platforms (from server, to app, to SOC).
• Allows design to iteratively evolve (with benefits through collaboration).
• Solves design problems in the design space rather than in the code space.
• Design and implementation are tightly coupled.
• Designs can be shared across teams. They provide a language and technical reference for discussion and interchange.

8. Where to go from here

More background information, please read the:

• The Reactive Fabric White Paper Part 1 of 3, Part 2 of 3, Part 3 of 3
• The Reactive Fabric Desktop and Mobile App Application Brief
• The Reactive Fabric for IOT Product Application Brief

For direct source code samples, there is the: The Reactive Fabric iOS Sample Kit.

Please contact Terry Stillone  (terry@originware.com) for direct answers.

Home

About

Contact