Architecture: How to serve multiple COM interfaces that access a shared resource

Question

I have an architectural question. I have a project that is conceptually something like this:

This seems quite straightforward but there are wrinkles. Some background, by way of a partly fictitious example. This is an ASCOM driver which controls some motors, sensors and some power switches. The hardware device can rotate an observatory dome and report its position, open and close the shutter and turn the power on and off to the various observing instruments (telescope, camera, focuser, etc).

The Hardware Abstraction Layer deals with sending and receiving commands over a serial link and with any timing and sequencing issues that come with that. The presentation layer can call a method in the HAL to make the hardware do something, that might generate a whole series of commands and responses on the serial port, or none at all. Unsolicited data can also arrive at the serial port and is dealt with completely within the HAL.

The 'presentation layer' is composed of several COM interfaces. One interface (IDome) deals with controlling the dome and shutter, another (IPower) deals with the power control to the various devices. This is a standard and can't be changed.

The problem comes when two different programs want to access the device. For example, one program might want to control the dome via the IDome interface, another might want to control the power using the IPower interface. In the current implementation, this results in two instances of the whole assembly being created in different processes and one fails because of contention on the serial port, which can only allow one connection.

I need to find a way of decoupling the HAL and the presentation layer, such that the COM interfaces can be loaded by multiple processes, while the HAL only loads once and serves all the instances of the presentation layer.

Currently all of these 'layers' are contained within a single .NET assembly and I'd prefer to keep it that way if possible.

What patterns are good for this situation? Any and all suggestions greatly appreciated.

Answer 1

One option would be to make what needs to be a singleton (the HAL) actually a singleton on the box. For example, you could move the HAL logic into a windows service and the presentation layer can communicate via interprocess communications (pipe or tcp sockets). To ensure that only one instance of the service starts up, you can enforce a static service name but you can also protect against instances of the service running under multiple user sessions by having the service take a system wide mutex.