Connection to embedded device with Windows and .Net

I am building a .net application(xp, vista, 7) that will communicate with an embedded device. I will be able to connect via IP, serial port and modem. Question: Should I allow some type of open connection within my application that will allow me to connect to the device through some other channels that may be set up in the operating system just to allow future extensibility without really having to change anything on the device? I 开发者_如何学JAVAwas just imagining that the operating system would be able to serve all communication channels that may be setup through the operating system to the device. Like would an admin setup some channel through SMTP or other protocol. I just didn’t want to box myself in and ignore some more open architecture.

Thanks.

I would say: No.

Reason 1: Don't design features you don't need.

Reason 2: If another system needs access, it can use TCP, or the Serial Port through a splitter. Not sure what is possible with a modem. Similar functionality would be quite hard to implement and get right yourself.

I'm a bit confused on your question but what I think your getting at is that should you isolate communication method from the higher level code in your application.

The answer to that is yes, create an abstraction layer within your application and have that layer deal with communication to the device by whatever means you need (modem, IP, serial, whatever). This is probably best created by defining an interface that supports your needed communication calls and then create classes that implement that interface which do the work needed by the chosen communication method. This way your higher level code doesn't care what communication method is used other than having to choose one.

By using this method its rather easy to add communication methods to the software. Write the class that does the communication dirty work based on the operation of your device and add some method to select that communication method in the main application.

On the operating system front you will have to have code managing the low level details of communication to the device and as these details are very often dependent on the type of connection i don't see any gain by attempting to force connection management into the OS somehow, this just complicates administration. You may find some gain by daemonizing a "communication manager" and separating the rest of your application to simply view or process the data collected.

I don't get how you would expect any architecture on the application end would somehow create a situation where the device doesn't need to be updated to report via a new protocol as SMTP compliance, for example, absolutely would require new code on the device.

I too am confused by the question; can you be more precise (and succinct)?

One comment I would make is that you might consider a PPP implementation on the serial port/modem channels, so that TCP/IP is used throughout and will allow multiple connections through all channels.