Is it possible to trigger periodic events from a WCF Service? - c#

I'm creating a WCF service (to be run in IIS) that a client can talk to. Periodically I want my server to send a heartbeat to a Master server.
At the moment the only way I see to do this is to create a second Windows Service that will send out the heartbeat.
Is there any way to get my original WCF service to run an event periodically so that I can get everything done with just one service?

Not really a good way in a WCF service
If the service is going to get some use you may be able to store the NextHeartBeat timestamp and every request check if it's time to send out a message to the master server.

What you want to do may be achieved with server push or full-duplex approaches. But for heartbeat you might get around with a simple http ping using a WebClient as described here. When self-hosting (non IIS) you can override ServiceBase.OnStart/OnStop and start/stop a timer to periodically trigger the ping.
However, hosting a WCF service in IIS usually means that your service is instantiated on a per-request basis so there is no service instance hanging around to send an enduring ping.
It depends on the purpose you need the heartbeat to the Master Server. Could you instead let the master server periodically do a request on the WCF service?
If you really are in the need for a long running service then hosting WCF in a Windows Service instead of IIS might be an option.

Related

WCF operation is not running after client disconnects

As far as I know BasicHttpBinding doesn't support ReliableSession feature. So, this means that when request is received by server (wcf host) then it will be executed wether the client is disconnected afterwards or not. I hope I'm right on this?
The problem is:
I have a WCF service with BasicHttpBinding. We tested this service by calling it 10 times with different threads on the client side. And these requests are all made at the same time (almost). Right after the callings of the thread we're terminating the program by killing the process. As a result 6 out of 10 requests are executed but the 4 of the requests aren't executed. We've checked network traffic with wireshark and saw that 10 of the requests are received by the wcf service host. However, we know that 4 of them didn't executed.
(Timeout values are not configured on binding: that means they're all setted to their defaults. Also the wcf service is hosted on iis).
What's the problem here? Where can I check? What can we do to achieve 10 execution out of 10 even if the client disconnects?
What can we do to achieve 10 execution out of 10 even if the client disconnects?
You can make it the default behavior. Use [OperationContract(IsOneWay=true)] to create a one-way contract where the client does not wait for a reply, but simply disconnects after sending the message.
Since you really need the service to be completed even if the client disconnects i think there is a database transaction that you need to be done.
In case the WCF is connecting to a database, this would be normal especially if you are using the same database user and password, if this is the case try to connect once for all WCF instances.
either way you have to make sure that your WCF provide concurrent access. click here for more information of concurrent WCF access.

C# Traditional Server with WCF Web Service

I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.

Signalr on Azure: service bus required for calling a single client?

I read that Signalr on Azure requires a service bus implementation (e.g. https://github.com/SignalR/SignalR/wiki/Azure-service-bus) for scalability purpose.
However, my server only makes callbacks to a single client (the caller):
// Invoke a method on the calling client
Caller.addMessage(data);
If don't need Signalr's broadcasting functionality, is an underlaying service bus still necessary?
The Service Bus dependency is not something specific to Azure. Any time you have multiple servers in play, some of your signalR clients will have created their connection to a specific server. If you want to keep multiple servers in sync something needs to handle the server to server real time communication. The pub-sub model of service bus lines up with this requirement quite well.
dfowleR lists a specific case of this in the comments. Make sure you read down that far!
If you are running on a single server (without the sla on Azure) signalR will work just fine on a Cloud Service Web Role as well as the new Azure Web Sites. I did a screencast on this simple scenario that does not take on a service bus dependency, but only runs on a single server.
In order to support the load balance scenario, is it possible to enstablish a "server to server" SignalR PersistConnection between multiple instances (ie on Azure) ?
If so, we can use a SQL Azure Table where all instances register at startup, so newest can connect to previous ones.

Send commands to another network

I am trying to write a monitoring tool to monitor some information
It will gonna work on azure normally. So i gonna host the database on azure also the webservice will be hosted at azure.
On the client's i read from the config file how many time's he need to update the information to the azure database ( with the webservice on azure ).
Now i want to send also some commands to the client itself. Like start service, .... what is the best way to do that?
How can i send it from a website that is hosted on the azure platform?
I think you should consider implementing a WCF service at the client as well. The Azure side of your software could call operations from this service when it needs to instruct the client to do something.
The WCF service at the client should be something simple,hosted in a Windows Service or in your actual client (whatever it is... win forms, console, etc).
Since you have no VPN, it sounds like you may have a problem with hosting a WCF service on the client. If the client is behind a firewall, you would have to modify the firewall configuration to allow your server to connect to this service.
Last time I had to do a service like this, I used Comet. The server maintains a queue of messages to be sent to the client. Your client connects to the web service and requests any available messages. If messages are available, the server returns them. If not, the server leaves the request open for some time. As soon as a message arrives, the server sends it down the already-open connection. The client will either periodically time out/reconnect or send a keep-alive message (perhaps once per minute) in order to keep the connection alive in the intervening firewalls.

Starting self hosted WCF services on demand

Is it possible to start self hosted WCF services on demand?
I see two options to accomplish this:
Insert a listener in the self hosted WCF's web server and spin up a service host when a request for a specific service comes in, before WCF starts looking for the existence of that endpoint; or
Integrate a web service in process, start a service host for a request if it isn't running yet and redirect the request to that service host (like I suspect IIS does).
I cannot use IIS or WAS because the web services need to run in process with the UI business logic.
Which is feasible and how can I accomplish this?
EDIT:
I cannot just start the service hosts because there are hundreds, most (about 95%) of which are (almost) never used but need to be available. This is for exposing a business logic layer of 900 entities.
You could do a locator service setup. Basically always expose a lightweight service that returns the address of the 'actual' services. Every time the address of a particular service is requested, go ahead and spin it up.
If you're worried about cleaning it up, you could keep a list of the service hosts and wire in some sort of inactivity timeout so you could periodically shut down the service hosts.
There are some design concerns here - the concept of "calling one service before you call another one" is probably considered a bad idea on some level (sounds like coupling the state of two services).
Went the following route:
Create a single service host;
Create a dynamic proxy which implements all service interfaces;
Add a service endpoint for every interface the dynamic proxy implements;
Dispatch to the correct implementation from the dynamic proxy.

Categories