Sharing hardware resources with WCF service clients

So I am embarking on creating a desktop WCF service that, at its core, access hardware attached to a serial port. Obviously there is only one port, and several entities that are derived from that hardware (nodes in a Zigbee network if you care) need to be shared with all service clients equally.

A quick look at Chapeter 8 of Juval Lowy's "Programming WCF Services" seems that he recommends putting the shared resource into a static class, but static classes raise my hackles immediately as a开发者_如何学Go bad code smell.

Is there some more "elegant" way to share these resources, or is a static class truly the accepted best practice here?

It sounds that your clients will need to communicate asynchronously, since they will have to wait for the resource to free up when it is blocked. I think you need to implement a queue, with callbacks to clients upon completion of an operation.

The code that handles serial port communication imho will be stateful at some level, so (static) class methods will not work for you anyway.

ps: Static classes don't smell bad. The don't smell at all, actually, since they don't have any instances :-).

This is one of the rare cases when a singleton WCF service might make a whole lot of sense. Since there's only one single hardware resource to share amongst all callers, your WCF service might be a good match as a singleton.

Check out Juval's chapter 4 and subchapter "Singleton service". It's not a very scalable model, but since you only have a single resource, it seems like a good fit. The one question you need to ask yourself is whether or not your service can and has to be multithreaded (more work programming), or if you actually can or want to serialize the requests (singlethreaded, serving one request after another) which is easier to program, but less scalable and gives you less performance.

Marc