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

In terms of pattern you want a proxy that controls all access to the HAL, that's a given.

In terms of control access, does it make sense for multiple UIs to have control over one set of resources? Assuming you do want too there would be logic used by the proxy that would resolve conflicts etc.

Alternatively you'd have two logical parts to the proxy, one that accepted input, and the other that reported current values so that multiple subscriber clients (UIs) could keep up to date with where the HAL is at. An event driven approach would work well here, also have a look at publish/subscribe patterns. For single control have look at locking patterns.

In all cases the proxy is where the control logic is applied, but the code structure itself would be more complex than that.

Answer 2

You may be able to use DCOM. The idea is to register your CLSIDs as out of process servers (optionally using COM+). When your clients create instances of these CLSIDs, they will all be created in a "surrogate process", and Windows will transparently marshal calls between the client processes and this surrogate process.

Note that to do this, you must have a 'proxy/stub DLL' for your interface. If you compile an IDL file containing your interface definitions, it will produce C code for such a proxy/stub DLL. You must then register this DLL for out of process communication to work properly with your custom interfaces.

Alternately, you can apply the same out-of-process activation model at the HAL level - that is, create a COM interface for the HAL, register the HAL's CLSID as an out-of-process server, and have your internal components communicate over DCOM. This has the advantage that you'll have control of the interface CLSID, and can register your own proxy/stub DLL without possibly colliding with some other vendor's proxy/stub DLL.

Answer 3

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.