I am trying to figure out the best way to approach this design... Here is some background of what I'm trying to do:
I have a simple digital I/O controller that sends data to my computer via Ethernet. I have a program that can receive this data over Ethernet. I would like a separate front end application that presents this data in a GUI. I am trying to figure out the best way to interface the program that grabs the I/O data over Ethernet, and the program that displays this as the front end. This interface should run whenever the computer boots and constantly poll the I/O in the background.
I've read about Windows Communication Foundation (WCF) and this seems like a nice way to do this. As the windows service would quietly keep polling the I/O and any clients that attach to the WCF interface can present this data in a GUI.
Am I going about this all wrong? Does this seem like a good way to do things? How will my front end clients grab the data from the WCF service?
Thank you in advance.
That's precisely the way I have done it - hosting a WCF service in a Windows service. The Windows service is the process; the WCF service is where the work is done.
In my case, my WCF-based CollectionService is on standby most of the time. I use WCF to start and stop the collector because the WCF programming model makes this easy. However, to get the data from the collector to the UI, I use a TCP socket, not WCF. I know that WCF has a streaming mode, but (1) I've never used it and (2) I believe there is some amount of overhead using WCF this way. The socket is simply a comfortable fallback for me, but I think WCF could be made to work.
If you're just starting, you can refer to these two answers for getting your Windows service up and running using C#. From there, you'll just need to create the ServiceHost and close it in the OnStart() and OnStop() callbacks of your Windows service, respectively.
Easiest language for creating a
Windows service
How to make a
.NET Windows Service start right
after the installation?
If you are new to WCF, take a look at this SO question.
Good and easy books/tutorials to learn WCF latest stuff
One more thing. In the course of your work on this, you may find that you want the WCF service to provide events to your UI when certain things occur. For example, you might provide an event that periodically notifies the UI of the number of bytes that have been received. For this, I would strongly recommend this article by Juval Lowy, one of the WCF gods.
What You Need To Know About One-Way Calls, Callbacks, And Events
His Publish-Subscribe Framework is available for free at his website, IDesign.net, along with several other working WCF examples.
Hope this helps.
Related
does someone know if it possible to use one WCF Data Service as data source of another WCF Data Service? If so, how?
So the short answer is yes. Actually I have consumed one WCF service in another (HttpBinding coming to a service on computer, then that service had a NamedPipesBinding service to communicate with multiple desktop apps, but it did some data transformation in the middle). That would not be an issue at all, you would set up a proxy/client just like you would in a desktop client, and handle everything in your new service as if it was just passing information along, you could even create a shared library for the DataContracts and such.
HOWEVER I would not suggest the leapfrog method in your implementation. Depending on how many customers you are potentially opening the door too, you may be introducing a bottlekneck, if you have a singleton service, or overload your existing service in the case of many connections from the new one. Since you have a SQL server, why would you not have a WCF service on your web/app server (public) that connected to it and provided the data you need? I'm only thinking this because your situation can become exponentially complicated when you start trying to pass credentials for authentication and authorization between the two, depending on your security settings. Another thing to consider is the complexity in debugging this new service and the old one, and a client at the same time, as if it wasn't a pain just to do server and client, since you are opening it to a public facing port, there are different things to set up, and debugging everything on the same machine is not the same as a public facing application server.
Sorry if this goes against what you were hoping to hear. I'm just saying that it is possible, but not suggested (at least by me) in your particular case.
I want to develop a simple Windows Forms application in C# using WPF and MVVM that will connect to an SQL server installed on a different machine. So I've read that, even for a simple structure like that, some developers would use WCF and make their application Service Oriented. I totally understand that SOA is the way to go with WebApps and SilverLight, but I don't see why, for a simple situation like a Winform and an SQL Server, would somebody use WCF. I would really appreciate if somebody could give me a couple of good reasons why to use WCF in my WinForm application (considering that the SQL Server will be in the same network with the clients)?
Thanks,
Aris
If you don't need it, don't use it :)
But you should consider whether there are plans to change the application - for example, to convert it to a web app or Silverlight. In that case, having a service which does the database access will make the conversion easier. Personally, I think this is usually over engineering, but it may make sense for your application if you foresee one such change in the near future.
Do you have to use WCF? Nope.
In my opinion, though, there aren't too many reasons NOT to create a WCF service for this sort of work.
Using WCF services for your different layers instead of class libraries is an excellent way to go. Using WCF, you can control how your components are hosted (IIS and http all the way down to in-process with named pipes) and where they're located.
WCF doesn't add much overhead and in return you get a bunch of benefits.
The point isn't necessarily to worry about SOA, but more to think ahead about flexibility and better reuse.
I can't think of a particularly compelling reason, other than habit. When you do something the same way for 99% of your projects, it's often just as easy to do it the same way for the other 1% if it doesn't go actively against your requirements.
The only other reason I can think of would be if you're writing something that could, potentially, be really useful externally or as a web-app. Using WCF in that instance would allow any client which could connect to the host (web browser, external application, or whatever) to connect to your library without you having to modify things after the fact.
If you know for (relatively) certain that this will only be a windows application run on the desktop of your own organizations' employees, I don't see a reason to use WCF in this instance.
Bottom line is that you're on a network so WCF or any web service makes sense.
Your network calls are all going to be async (or should be!). That's easy to do with WCF. Not so much with direct connections.
Even WinForm applications are connected these days.
I personally don't believe in creating services for everything, just to be creating services. Create a service when you know that you have a consumer for that service. Don't just say, "well, we might use it from another application some day", and call that an excuse for a service.
Services should be planned. The service contracts should be those which are required by their consumers. No consumers, no contracts, so no service.
So I've created a series of objects that interact with a piece of hardware over a serial port. There is a thread running monitoring the serial port, and if the state of the hardware changes it updates properties in my objects. I'm using observable collections, and INotifyPropertyChanged.
I've built a UI in WPF and it works great, showing me real time updating when the hardware changes and allows me to send changes to the hardware as well by changing these properties using bindings.
What I'm hoping is that I can run the UI on a different machine than what the hardware is hooked up to without a lot of wiring up of events. Possibly even allow multiple UI's to connect to the same service and interact with this hardware.
So far I understand I'm going to need to create a WCF service. I'm trying to figure out if I'll be able to pass a reference to an object created at the service to the client leaving events intact. So that the UI will really just be bound to a remote object.
Am I moving the right direction with WCF?
Also I see tons of examples for WCF in C#, are there any good practical use examples in VB that might be along the lines of what I'm trying to do?
No, WCF is a message based system - you pass around serialized (text/xml) messages. There's no "object references" that you can pass around.
The client has a proxy, which gives you the ability to "call" the service method. The WCF runtime then captures the parameters to that call, packages them up in a serialized message, and sends that message across the wire.
There is no direct connection between the client and the server - the client can't "reach over" to the service to get a remote object, nor can the service go back to the client to find out who called it or anything like that.
All that you want to send to the service must be part of either the message itself, or the headers that accompany the message.
Those messages must conform to the XML schema standard, which again means: only concrete non-generic types. You can't pass around interfaces, you cannot pass references - only concrete types made up of basic types such a string, int, datetime etc.
Update: maybe you need to check out the publish/subscribe (pub/sub for short) pattern - which you can also build using WCF. This would allow you data collection machine to publish its data on a regular basis or whenver it changes, and any number of subscribers could be notified of those changes.
Check out some of those articles - googling or binging for "WCF pub sub" will definitely turn out quite a few more!
Tom Hollander: Building a Pub/Sub Message Bus with WCF and MSMQ
Pub/sub sample with WCF net.tcp protocol in Silverlight 4
Pub/sub sample using HTTP polling duplex WCF channel in Microsoft Silverlight 3
WCF Router and Publish/Subscribe Sample Implementation
I may have gone crazy... but I am hoping there is a way to do this.
I have a base class that has event handling in it. My console application is running my workflow. Part of that workflow is to raise events at specific intervals in a separate thread to broadcast the workers' current state (a heartbeat I have heard many call it).
I also have another program in the same solution that is a windows form that I want it to be able to listen to what is going on in the console application so that it can display the worker states. I have tried running both at the same time and verified the events are triggering, but the monitor is not finding any of the raised events.
I am fearing that there is no way to do this, and I will need to go to a database logging method or something else... but in the off chance someone knew how to communicate between applications with event (or event-style) logic, I would appreciate it.
Currently the applications are running from the same location. The goal is that the monitor application will eventually be attached with a broadcaster for our network so that our workstations can monitor for certain worker states without being logged into the machine and the main monitor will show us the full status of all the workers.
Please let me know if I need to expand/clarify this, have a 2-year old watching Star Wars while I type this so I may have missed something.
There are several ways: using remoting, custom windows messages and named pipes. One way is How to use named pipes for interprocess communication in Visual Basic .NET or in Visual Basic 2005
Here's a remoting example: Simple Inter-Process Communication In VB.Net
Here an example of custom windows messages: VB.NET, VB6 and C# Interprocess communication via Window Messaging
Perhaps the most 'up-to-date' way is to use WCF Callback Channels: Using Callback Contracts in WCF for Asynchronous Publish/Subscribe Event-Style Communication
I have found myself responsible for carrying on the development of a system which I did not originally design and can't ask the original designers why certain design decisions were taken, as they are no longer here. I am a junior developer on design issues so didn't really know what to ask when I started on the project which was my first SOA / WCF project.
The system has 7 WCF services, will grow to 9, each self-hosted in a seperate console app/windows service. All of them are single instance and single threaded. All services have the same OperationContract: they expose a Register() and Send() method. When client services want to connect to another service, they first call Register(), then if successful they do all the rest of their communication with Send(). We have a DataContract that has an enum MessageType and a Content propety which can contain other DataContract "payloads." What the service does with the message is determined by the enum MessageType...everything comes through the Send() method and then gets routed to a switch statement...I suspect this is unusual
Register() and Send() are actually OneWay and Async...ALL results from services are returned to client services by a WCF CallbackContract. I believe that the reson for using CallbackContracts is to facilitate the Publish-Subscribe model we are using. The problem is not all of our communication fits publish-subscribe and using CallbackContracts means we have to include source details in returned result messages so clients can work out what the returned results were originally for...again clients have a switch statements to work out what to do with messages arriving from services based on the MessageType (and other embedded details).
In terms of topology: the services form "nodes" in a graph. Each service has hardcoded a list of other services it must connect to when it starts, and wont allow client services to "Register" with it until is has made all of the connections it needs. As an example, we have a LoggingService and a DataAccessService. The DataAccessSevice is a client of the LoggingService and so the DataAccess service will attempt to Register with the LoggingService when it starts. Until it can successfully Register the DataAccess service will not allow any clients to Register with it. The result is that when the system is fired up as a whole the services start up in a cascadeing manner. I don't see this as an issue, but is this unusual?
To make matters more complex, one of the systems requirements is that services or "nodes" do not need to be directly registered with one another in order to send messages to one another, but can communicate via indirect links. For example, say we have 3 services A, B and C connected in a chain, A can send a message to C via B...using 2 hops.
I was actually tasked with this and wrote the routing system, it was fun, but the lead left before I could ask why it was really needed. As far as I can see, there is no reason why services cannot just connect direct to the other services they need. Whats more I had to write a reliability system on top of everything as the requirement was to have reliable messaging across nodes in the system, wheras with simple point-to-point links WCF reliabily does the job.
Prior to this project I had only worked on winforms desktop apps for 3 years, do didn't know any better. My suspicions are things are overcomplicated with this project: I guess to summarise, my questions are:
1) Is this idea of a graph topology with messages hopping over indirect links unusual? Why not just connect services directly to the services that they need to access (which in reality is what we do anyway...I dont think we have any messages hopping)?
2) Is exposing just 2 methods in the OperationContract and using the a MessageType enum to determine what the message is for/what to do with it unusual? Shouldnt a WCF service expose lots of methods with specific purposes instead and the client chooses what methods it wants to call?
3) Is doing all communication back to a client via CallbackContracts unusual. Surely sync or asyc request-response is simpler.
4) Is the idea of a service not allowing client services to connect to it (Register) until it has connected to all of its services (to which it is a client) a sound design? I think this is the only design aspect I agree with, I mean the DataAccessService should not accept clients until it has a connection with the logging service.
I have so many WCF questions, more will come in later threads. Thanks in advance.
Well, the whole things seems a bit odd, agreed.
All of them are single instance and
single threaded.
That's definitely going to come back and cause massive performance headaches - guaranteed. I don't understand why anyone would want to write a singleton WCF service to begin with (except for a few edge cases, where it does make sense), and if you do have a singleton WCF service, to get any decent performance, it must be multi-threaded (which is tricky programming, and is why I almost always advise against it).
All services have the same
OperationContract: they expose a
Register() and Send() method.
That's rather odd, too. So anyone calling will first .Register(), and then call .Send() with different parameters several times?? Funny design, really.... The SOA assumption is that you design your services to be the model of a set of functionality you want to expose to the outside world, e.g. your CustomerService might have methods like GetCustomerByID, GetAllCustomersByCountry, etc. methods - depending on what you need.
Having just a single Send() method with parameters which define what is being done seems a bit.... unusual and not very intuitive / clear.
Is this idea of a graph topology with
messages hopping over indirect links
unusual?
Not necessarily. It can make sense to expose just a single interface to the outside world, and then use some internal backend services to do the actual work. .NET 4 will actually introduce a RoutingService in WCF which makes these kind of scenarios easier. I don't think this is a big no-no.
Is doing all communication back to a
client via CallbackContracts unusual.
Yes, unusual, fragile, messy - if you can ever do without it - go for it. If you have mostly simple calls, like GetCustomerByID - make those a standard Request/Response call - the client requests something (by supplying a Customer ID) and gets back a Customer object as a return value. Much much simpler!
If you do have long-running service calls, that might take minutes or more to complete - then you might consider One-Way calls which just deposit a request into a queue, and that request gets handled later on. Typically, here, you can either deposit the answer into a response queue which the client then checks, or you can have two additional service methods which give you the status of a request (is it done yet?) and a second method to retrieve the result(s) of that request.
Hope that helps to get you started !
All services have the same OperationContract: they expose a Register() and Send() method.
Your design seems unusual at some parts specially exposing only two operations. I haven't worked with WCF, we use Java. But based on my understanding the whole purpose of Web Services is to expose Operations that your partners can utilise.
Having only two Operations looks like odd design to me. You generally expose your API using WSDL. In this case the WSDL would add nothing of value to the partners, unless you have lot of documentation. Generally the operation name should be self-explanatory. Right now your system cannot be used by partners without having internal knowledge.
Is doing all communication back to a client via CallbackContracts unusual. Surely sync or asyc request-response is simpler.
Agree with you. Async should only be used for long running processes. Async adds the overhead of correlation.