Have Geek Brain

Providing Windows Service via WCF

I already created a Windows service that monitors the network for specific traffic. Now I need to make a UI for the service so that the traffic can be monitored in real time and also the ability to change the parameters of the service.

Unfortunately, I am stuck with how I take my working service and expose / convert it to WCF.

I don't even know where to start.

thanks

EDIT: Well, I've looked at several methods through WCF and it all looks like it will work as needed.

It really wasn't that hard once I realized that the ServiceHost constructor could take an instance, not just a type, since my class that was doing the job didn't have a parameterless constructor.

+2


a source to share


1 answer


Well, to be honest, I wouldn't go the route of "exposing" your service through WCF.

My suggestion would be:

  • leave your current service that collects and monitors traffic as it is
  • save data that you might want to share with others in a suitable storage (such as a database).
  • create a separate WCF service (hosted in a second Windows NT service or in IIS) that allows external consumers to receive your collected data.

Given your current data, you will need to analyze what data you have, and then you need to decide what and how to expose that data to other users who might be interested in that data.

  • if you choose a SOAP based WCF service, you will have to come up with a bunch of service methods (something along the lines GetDataForToday

    , GetDataForHour

    or whatever you want to do). In this case, it is your first task to define the service methods (your service contract , in WCF talk) and determine what data will be involved - both the parameters for your service methods and as the return value from those methods (your data contracts )

  • if you're more into REST then you usually don't talk about methods, but instead you think of your data as resources - eg. you can expose the hourly dataset as a resource and navigate to it with a URL similar to http://yourserver/YourService/YYYYMMDD/Hour

    or something like that - how you define that URL (uniform resource identifiers - URIs) is entirely up to you. Each such resource must have a representation - a set of fields and properties - and you usually display them as XML and / or JSON



With the flexibility of WCF, you can even do both - if you like.

SOAP is the more traditional way of doing things - the professionals are a well-documented interface (you get a description of WSDL - a web service and several XSD-XML schemas to describe your data) that can be "discovered" and interpreted by humans and computers. On the other hand, SOAP tends to be a bit "heavy" and you need a dedicated SOAP client / your own application to actually get the data.

REST is more of a hip and modern way of doing things - you go to a URL and it spits out a truckload of angle brackets (or JSON document). It's fast, easy, it's great - but it's less formalized, you don't get a machine-readable description of the service, in fact - you need a little more to learn / learn / read the docs to find out what you really get back and how to interpret it.

Ugh, this has become a long message !! Basically - I would keep your current data collection service and let it run as it is, and think about how to open / make available the data it collects using a separate WCF service.

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 WCF Aspects.

+2


a source






More articles:


All Articles