2

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

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.

Tim Long
  • 13,508
  • 19
  • 79
  • 147
  • Hmm, so what's supposed to happen when two programs want to both use IDome? This tends to quickly end up the exact same way as SerialPort deals with it: first come, first serve and AccessDenied to everybody else. – Hans Passant Aug 30 '11 at 00:56
  • Its not as bad as all that, because the HAL actually deals mainly with cached data, so there isn't actually a resource contention. The only point of contention really comes from the fact that the HAL has to open the serial port. Also, in this particular situation it would not be normal for multiple programs to access the same interface, multiple programs would each access a different interface. Some of this architecture is 10+ years old and predates .NET, so it is a bit of an awkward fit. – Tim Long Aug 30 '11 at 01:23
  • One program uses IDome to image the Moon, the other uses it to image Mars. How is that supposed to come to a good end? There is resource contention, there's only one dome. – Hans Passant Aug 30 '11 at 01:26
  • If you have a centralized process to control it, the request could specify not only the target (Mars) but the source. If the location is not longer the source, you could provide a good error. That way, someone could request to image Mars but only after that client & user explicitly move it from the Moon. – bryanmac Aug 30 '11 at 03:04

3 Answers3

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.

bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • That seems like a reasonable solution. How would you deal with the IPC aspect? Would it be necessary to pass everything accross as strings or would (say) .NET Remoting be an option? Or is remoting passé these days? I guess what I'm asking is, 'is there a way of just calling into the service'? – Tim Long Aug 30 '11 at 00:56
  • For .Net, .Net remoting is fine. Another option is WCF which allows you to define your data contracts (decorate your classes and properties with attributes) and the transport is configurable. WCF allows you to host many different types of services within your own process (windows service). For example, with config you can switch between pox (plain old xml), soap, or binary. It also allows tcp transports I believe ... – bryanmac Aug 30 '11 at 01:04
0

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.

Community
  • 1
  • 1
bdonlan
  • 224,562
  • 31
  • 268
  • 324
0

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.

Adrian K
  • 9,880
  • 3
  • 33
  • 59