views:

238

answers:

1

I have a project comming my way: devices with their own system written in C, and a Windows application for managing purposes (sending configuration, retrieving recorded data from devices, monitoring device's state). I have flexibility in choosing what technology I'll use. The requirements are pretty fuzzy right now so it should be something flexible. The primary communication protocol is TCP. We may use COM ports as a maintenance option, when normal communication fails due to some network malfunction for example.

I'm considering the use of a WCF service as a "proxy" between the application and the devices. App sends data to service, service processes the data and sends TCP packets to devices (data in packets are understandable by devices), devices react sending TCP packets back to WCF service which in turn sends processed message to application. Does this use of WCF make any sense?

WCF can easily be accessed from webapp so besides normal windows application we could make our system more sexy with it but is it worth it? What do you think, share your ideas, please :)

A: 

As I understand it, you are considering a systems architecture with three elements. A Windows application, a set of devices, and then an additional service that would act as a proxy or go-between, brokering communication between the two.

First question: is there a reason the management application cannot connect to the devices itself? The Windows app used for management should be able to open a socket to the devices, just as easily as another app could. Why would you not? I guess another way to ask this is, What is the justification to introduce the broker, the third element, into the architecture? Is there some asynchrony you want to introduce? Is it a matter of scale - maybe the number of devices is so large that you'd like a separate app to manage communications to all of them, rather than directly connecting from an app with a UI. Is it a matter of network topology? Before considering what technology to use in the broker, first decide what is compelling you to include a broker in the architecture.

Supposing there is good justification for the third element, then you can consider the question of whether WCF is appropriate communications technology for that element. Certainly between 2 Windows-based apps, WCF will work well. If they are on the same machine you can use a named-pipes binding and get very good perf for the local communication. If these two apps are distributed on different Windows machines you can use TCP for, again, very good performance on the network communication.

You also want to consider the connection between the broker and the devices. WCF can interconnect with non-WCF systems. You would have to write some extensions on the WCF side, to interconnect with an existing system. But it is possible and I'd say a near-mainstream use-case for WCF. See this Q for more on that topic.

Cheeso
Certain parts of architecture are devices and managing app, third element - the broker as you call it - is, let's say, for flexibility reasons. The said project is going to be written from scratch, both windows app (visual c#, c++) and hardware firmware (plain C), and we'd like to avoid errors of the past (scalability, flexibility, hard maintanance, communication, usuall real world IT problems). WCF seems to address all of these issues so I'm investigating what problems it could generate and what bonuses we get if we choose it as our solution. And I mean real bonuses, not marketing pulp :)
grapkulec
Another thing is that we have to flash higher management with something like "we put this one smart thingy in here and we can access devices from windows app, from web browser, from mobile phone and we will work for free and pay company's electricity bills if you let us do it". Company uses borland for ages which is cool if you need to check what happens when you cast int into char* but be frank for a moment - there's no wayway borland could ever be better than visual studio. So it hasn't be WCF but it has to be something spectacular (for bosses) and relatively easy to work with (for us)
grapkulec