Question

I have already created a windows service that monitors the network for some specific traffic. I now need to make a user interface for the service so traffic can be watched in real time, as well as the ability to alter the service’s settings.

Unfortunately, I’m stuck on how I take my working service, and expose it through/convert it to WCF.

I don’t even know where to begin.

Thanks

EDIT: Well, I have exposed a few methods through WCF and this all appears like it will work as necessary.

It really wasn’t hard at all once I realized the ServiceHost constructor could take an instance, rather than just a type, since my class that did the work, didn’t have a parameterless constructor.

Answer 1

Well, quite honestly, I wouldn’t go the path of “exposing” your service through WCF.

My suggestion would be:

• leave your current service which collects and monitors traffic as it is
• store the data you might want to expose to other into a suitable persistant store (e.g. a database)
• create a separate WCF service (hosted in a second Windows NT Service, or in IIS) that will allow external consumers to get at your collected data

Given your current data, you would have to analyze what kind of data it is you have available, and then you need to decide what and how to expose that data to others who might be interested in that data.

• if you choose a SOAP-based WCF service, you’d have to come up with a set of service methods (something along the lines of GetDataForToday, GetDataForHour or whatever it is you want to make available). In that case, this is your first task – define the service methods (your service contract, in WCF speak), and define what kind of data is involved – as parameters to your service methods, and as return values from those methods (your data contracts)

• if you’re more into REST, then you don’t typically talk about methods, but instead you think of your data as resources – e.g. you could expose an hourly data set as a resource and navigate to it using an URL something like http://yourserver/YourService/YYYYMMDD/Hour or something like that – how you define those URL’s (the unified resource identifiers – URI’s) is totally up to you. Each such resource needs to have a representation – a set of fields and properties – and you would typically expose those as XML and/or JSON

With the flexibility of WCF, you can actually even do both – if you wish.

SOAP is the more traditional way of doing things – pros are a well-documented interface (you get a WSDL – web service description, and a handful of XSD’s – XML schemas to describe your data) which can be “discovered” and interpreted by humans and computers alike. On the downside, SOAP tends to be a bit “heavy”, and you need a special SOAP client / your own app, to actually get at the data.

REST is the more hip and modern way of doing things – you navigate to a URL and it spits back a truckload of angle brackets (or a JSON document). It’s quick, it’s easy, it’s great – but it’s less formalized, you don’t get any machine-readable service description, really – it’s a bit more up to you to know / find out / read the docs to know what you’re really getting back and how to interpret it.

Phew, this has become a long post!! Basically – I would keep your current data-gathering service and let it run as is, and think about how to expose / make available that data it collects using a separate WCF service of sorts.

Good intro sites are the MSDN WCF Developer Center for the SOAP-based WCF aspects, and the MSDN WCF REST Developer Center for the REST-based aspects of WCF.