Home Control Design: Network

Requirements and A Scenario

There are a lot of different means applications can communicate over a network. And there are a lot of implementations of each of those means. Here are some of the requirements for what I wished to use:

• lightweight (especially in terms of dependencies)
• self-contained (able to be used in stand-alone applications)
• distributable (didn't want to worry/care/need "addresses")
• asynchronous (extending the event-driven design choice)
• able to utilize transportable, complex objects (Serialiable, in other words)
• simple to use

This eliminated all of the typical client/server approaches, such as Java application containers. It also eliminated other "popular" P2P-type approaches, such as Jini and Jxta, which I regarded as too heavy-weight and rather cumbersome.

So, to start properly, consider the basic scenario that forms a basis for the stimulus/response system:

1. module changes state
2. "controller" application gets state change and "broadcasts" the change
3. interested (listening) application(s) receive the message and do whatever

This is then extended into the form of "commands" (turn light on). This would normally be a typical RPC (remote procedure call) with a return of the status or success or other value. However, since module state changes should actually transmitted on a broadcast basis, the return value is mostly meaningless. This means that commands can also be asynchronous and, if the system is built accordingly, the messages may also be broadcast and not require a specific end-target.

This is an implementation of the "message bus" concept, currently in vogue as part of an SOA. However, the concept/analogy/metaphor shouldn't be taken too far as we are still talking about simplicity.

Drawbacks and Solutions

One specific issue this does not address are use-cases where a more typical RPC-based approach is most applicable: environment editing. Usually, a client will ask the server for the single-item/group-of-items and receive the suitable object. The client manipulates the object and sends it back to the server. The client can then "forget" about the editable item(s) and go on about it's business. With the event-driven methodology, this cannot be done.

In order to present editable items, the client must already have them in it's possession or request and somehow wait for the appropriate return event. However, if the environment itself is "shared" across the network, then the event paradigm can extended to allow the server and clients to keep in a synchronized state.

There a a few issues, however, of extending the event-driven approach. These are:

• when a server-side action can take an appreciable amount of time and/or fail, the client has no means of actually knowing that the command/edit failed
• when an action should be directed to a single receiver (such as in whole-house audio applications)

At the current time, these issues have not been adequately addressed.