The Next Generation of Real-Time System Architectures (part 2/5)

A data centric approach

Since the problem lies in functional dependence between modules, it is logical to see that cause of this dependence lies in knowledge coupling between the modules. The design of a module is often influenced by in depth knowledge of how the other module works, rather than what data is available in the system.

Most designs focus strongly on the communication between modules. Data is only exchanged when the either one or both parties find it useful. It is this focus on “when” that leads to abstraction loss of the “what”. It binds the knowledge of the communication with the actual information that is required. Timing, synchronization, configuration, formatting etc. have taken a predominant role, and create tight couplings between the modules.

To resolve this, most solutions embed the communication aspect in a middleware layer, of which many are available. (A simple google on middleware returns well over 6 million hits) However, most of these architectures do not solve the actual problem but more likely shift it to the middleware layer itself. This layer has still to be configured with the same in depth knowledge that previously plagued the modules implementation.

A different approach would be to put the data central. It is not important who produces or consumes the data, in order to communicate a module should specify what type of data it requires or creates, and what properties this data request / creation has.

This has some advantages over a message oriented architecture:

  • There is no need to know the architecture of each module that one interfaces with, in stead a module designer can focus on the information his module will need or produce.
  • Since there is no direct link between modules, great flexibility is expected in terms of configuration. This means that the resulting architecture should scale well, without changing the individual modules.
  • This scaling could also be performed run time, creating an abstract solution for redundancy, reconfiguration and graceful degradation.
  • When modules define there interfaces in data related properties it becomes possible for the middleware define most of the communication parameters automatically, thus greatly reducing the complexity.
Tagged with: , ,
Posted in Code, Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: