MTF.NET Architecture

Why .NET?

It is worth briefly mentioning the choice of .NET as a platform for the MTF.NET runtime. The .NET platform has the following benefits:
  • Cross platform (Windows, Linux, MacOS, Android)
  • Easy native code interoperability (e.g. easy to call optimized native math libraries)
  • Excellent tool support (Visual Studio, Monodevelop)
  • Excellent support for building GUI-based applications
  • Excellent community support, knowledge-base and official documentation

The MTF.NET model

In the MTF.NET model, an application is broken up into lots of small sequential islands called Task Classes. When a task class receives a message, the runtime schedules its message handler to run and process the message. As part of that processing, messages can be sent out to other task classes. This gives rise to a network of nodes that process and share information.

mtf-runtime-coop-nodes.png

Each node processes information sequentially and the concurrent scheduling and transport of information between nodes is taken care of by the runtime.

This model of co-operating nodes takes care of splitting processing so it can run across multiple cores and the MTF.NET runtime builds on top of this basic approach to provide higher level abstractions for synchronizing activities.

Layered architecture

MTF.NET is a layered architecture as shown in the following diagram:

mtf-architecture.png

Low-level tasking runtime

The tasking runtime performs the low-level passing of messages between task classes and manages scheduling execution within a pool of worker threads.

Producer-consumer layer

The producer-consumer abstraction uses a request-reply-close-acknowledge cycle to enable event consumers to request from event providers and receive events in a flow controlled manner. Nodes are joined together as producer-consumer pairs such that a node that consumes a particular type of data is connected to a producer that produces that type of data. The ultimate consumer requests data and this request is propagated back to the ultimate producer, which provides the information that is then propagated back through the intermediate consumer-producers to the ultimate consumer.

Specialized operator layer

The producer-consumer is actually abstract and the details of how it generates events, propagates events or consumes events is deferred to the next layer up. This next layer is the primitive operator layer and contains specializations of the producer-consumer that provide various primitive event operations. The essential operations are:
  • Queue - stores FIFO of objects and produce events granting enqueue or dequeue access
  • Actioner - executes user-specified code in response to a consumed event
  • Replicator - consumes an input event and produce copies of it on multiple output links
  • Aggregator - gathers together consumed events on multiple links and produce a compound output event on one output link
  • Router - routes consumed events on multiple links along the same output link
  • Requester - provides a code-based API for waiting for events

Common patterns layer

These primitive objects can be combined together to build concurrent applications consisting of many actions exchanging data through queues that are shared and combined using the other operators (replicate, aggregate, route). When building applications using these primitives it is apparent that there are certain combinations of objects that occur very regularly. MTF.NET provides an additional layer that includes some of these common patterns so that a single object can be use in place of several to make it easier to build and maintain MTF.NET applications.

Extensibility

That completes the list of layers that are provided by the MTF.NET runtime. However, all the MTF.NET runtime layers except the lowest are built using MTF.NET's componentization capability and therefore additional layers can easily be built on top of those provided, allowing component sets tailored to specific domains to be built with the ultimate top layer being a specific application.

Last edited Sep 23, 2012 at 11:41 AM by jaorme, version 10

Comments

No comments yet.