How do I design a .NET (C#) for a program that needs to run as a Windows service but also have a web interface?

views:

answers:

+6 Q:

How do I design a .NET (C#) for a program that needs to run as a Windows service but also have a web interface?

I am designing a piece of software that needs to operate different pieces of hardware based mainly on a schedule but it also needs to have a web interface for configuring settings, configuring the schedule, and possibly even manually controlling the hardware. I'm not sure how to design the architecture of software like this.

One thought that I have had was to create a Windows service that does the communication with the hardware as well as "publishing" web services through WCF and then having an ASP.NET application that then controls the Windows service through WCF. This approach seems to be a lot of work for what I'm trying to accomplish.

Could someone please give me some direction whether or not this is a good approach, and even give me a better way to do it if one exists?

Thanks! Joel

+1 A:

You can instantiate a WCF endpoint as a TCP service from within the Windows service, as explained on MSDN: How to: Host WCF in a Windows Service Using TCP .

From there, it is relatively straightforward to consume that endpoint in an ASP.NET application (same as consuming any other WCF endpoint).

In the absence of any compelling reasons to do otherwise, this is probably the approach I would take. Your only other option is to use some other form of IPC, such as memory-mapped files or named pipes. WCF is a lot easier to get up and running.

Aaronaught 2010-03-19 00:04:08

This is the solution I was coming to. However, I didn't now about embedding ASP.Net web server into a service. If that requires me to still use WCF for communication, then this may still be the way to go.

hjoelr 2010-03-19 00:28:36

My followup question in regard to WCF is: Would it be fast enough for being an intermediary between the web UI and the hardware? I don't think I can be waiting multiple seconds for WCF responses.

hjoelr 2010-03-19 00:34:22

@hjoelr: WCF is very fast, even when you have encryption and other extensions turned on. I'm accustomed to response times on the order of about 1/4 of a second from remote servers; normally the only delay is due to network latency, and if you have all services running on the same machine or at least the same network then latency should be almost nil.

Aaronaught 2010-03-19 00:37:14

@Aaronaught: That is very reassuring! Thanks for the info on WCF speed.

hjoelr 2010-03-19 00:43:49

The only concern here is security. IIS offers a lot of features that you may have to replicate; if not at first then perhaps when you want to extend the architecture. Better to try to host web services in IIS (which has been tested for security, found wanting, fixed and retested many times) than in a service, if possible.

pdr 2010-03-19 00:55:51

@pdr: I'm not really sure what you mean by "security" here; WCF uses the same message-level security (with optional authentication, encryption, etc.) whether you run it over a TCP binding or HTTP. It doesn't even really use much of the ASP.NET stack when you run it under ASP.NET. The only thing you don't get for free is transport security (SSL), which you don't need if you enable message security. Hosting WCF over TCP isn't like hand-rolling your own TCP service; there's already a hosting API, you just have to change a few bindings.

Aaronaught 2010-03-19 01:06:49

In fact, that was one of the primary aims of WCF - to be able to host it anywhere, in any form. You can even hook it up to MSMQ. There's really no significant security risk to using the TCP bindings.

Aaronaught 2010-03-19 01:08:26

You could just use a common XML file (or something) that the service monitors for changes. The web interface could just read/write that XML file. This only works well if the service and web site are running on the same machine (you can do it through a share as well, but that's extra configuration and you may was well just go with WCF in that case).

Dean Harding 2010-03-19 00:05:37

Good thought. However, there needs to be two-way communication. The website polls information from the service but the website must also be able to update settings and such in the service.

hjoelr 2010-03-19 00:20:54

You can embed an ASP.Net web server in the service using the ASP.Net hosting API, then use it to run an ASP.Net website directly.

Note that the ASP.Net site would run in a separate AppDomain.

SLaks 2010-03-19 00:07:36

You still have to develop the ASP.NET site separately though. This doesn't really preclude the need to come up with a means of communication between the ASP.NET app and the service, it just allows you to run the whole package without IIS.

Aaronaught 2010-03-19 00:15:14

@Aaronaught: You can simply pass a `MarshalByRefObject` that exposes the service to `ApplicationHost.CreateApplicationHost` and interact with it in ASP.Net. (The ASP.Net project should reference the service assembly)

SLaks 2010-03-19 00:19:58

This is an interesting concept. I didn't know this was even possible. I'll see if I can look into this to see if it would work for my situation.

hjoelr 2010-03-19 00:24:55

True about `MarshalByRefObject` - although once you start getting into remoting then (IMO) it's easier to go with WCF. You're right, though, this can technically be done without any of the traditional IPC methods.

Aaronaught 2010-03-19 00:29:06

ansaurus

tags:

views:

answers:

How do I design a .NET (C#) for a program that needs to run as a Windows service but also have a web interface?

related questions