I know that it is not a good idea to have timers inside a WCF service class that is hosted inside IIS since these are meant to have short lifetimes. And from the advice here it also sounds like having a service is the best way to go for that situation.
But has anyone tried using timers inside a self-hosted service in production? We have a windows service that acts as a client and uses timers to do periodic operations at the moment.
This is fine for most cases, but I am concerned about the robustness of the design: some of the operations are critical (financial system calculation triggers). Since the WCF service and the windows service are two components, ensuring both are running is difficult.
If I moved the critical operations to a timer inside the WCF Service I remove that problem, but what else should I be concerned about then?
If I understand correctly, your question is actually about IIS-hosted WCF services, is that right?
IIS controls the application pool that your WCF service runs in. That means that IIS may decide to recycle your application pool and all the apps/services in it. Then your service only gets activated again once it is called by a client. So, scheduling in WCF services or ASP.NET applications cannot be relied on.
The picture of course changes if you can self-host your WCF service. Then there is no IIS application pooling to take into account, and you can schedule at will. Therefore, if you need the combination of WCF + scheduling, it's best to create a Windows service that will include both.
Related
We have set of WCF services running on single computer which collectively serves an WPF application which could be on same machine or on remote machine (within same network only). We need failover mechanisum so whenver any of the service crashes or hangs - we want to restart the service and initialize it by calling appropriate method.
Since we are not aware of what is the industry standard for implementing failover for WCF service - we have implemented like this way. We start main WCF service hosted in console app along with one more secondary WCF service which constantly checks health of main WCF service by calling exposed method on given endpoint. If main WCF service fails, it takes role of main WCF service and launches another secondary WCF service.
The above approach is working fine but only problem we have seen is memory since we launch services in pair and every host requires 10MB of memory.
Can anyone help me what is the industry practice for implementing failover for this kind of scenario?
I have an IIS hosted WCF service, and a client Windows application which, upon the first use of the day, takes a while to respond to the first service call. I believe this to be because IIS shuts down services which are not used for a period of time (and the delay is the restart time for the service). I was wondering whether I could alleviate this by making an asynch call when my application starts up (just to, potentially, get the service to start). I therefore, upon application start, created a "fire and forget" background thread which just opens a connection to the service. The intention being that when my application has finished its own startup, and wants to use the WCF service, the thread will (probably) have finished and the service startup delay will not be encountered by the user.
Is this reasonable ? Is opening a channel to the WCF service enough, on its own, to start the service, or do I need to write some dummy method and call that ?
Thanks
Ross
Check if you really want your app to handle this task and checkout the AppWarm-Up Module for IIS, maybe you can use this without adding code to your serivce.
Is this reasonable ?
It doesn't sound like a good approach to me. If you have control over how the service is hosted I would advise you to self-host it.
I have put together a .net winform application which consumes a wcf service exposed by another .net application running as a windows service.
Since the communication is within the same machine, I chose the NetNamedPipe as the communication channel, as it is the best choice suited for inter process communication in the same machine.
I want to know if I am using the correct property choices when defining the wcf service in the .net windows service.
The WCF service behaviour is defined as:
[ServiceBehavior(
ConcurrencyMode = ConcurrencyMode.Single,
InstanceContextMode = InstanceContextMode.Single)]
I chose the "InstanceContextMode" as Single so that I know objects in the wcf service are not recreated each time a wcf service method is called by the UI client.
However, while reading up the ConcurrencyMode property to choose on MSDN, I did get a little confused. At the basic level, I understand the ConcurrencyMode property dictates whether the wcf service supports a single, multiple or reentrant calls.
Does this mean, that if my UI client application is multithreaded and I call into the wcf service methods from those threads, I should choose "Concurrency" mode as "multiple" and if my UI client is not multi threaded, I should choose "Concurrency" mode as "single"? My UI client application is not running multiple threads. All operations are performed on the main UI thread through event handlers (through button clicks, combo box selections, etc...)
I am having situations where, after installing the application on a windows test machine, my UI client is sometimes not able to connect to the wcf service. It just keeps waiting on the call to the Connect method of the wcf client object and then eventually times out. I want to know if its related to the "ConcurrencyMode" choice I made. Or is this a "NetNamedPipe" communication channel problem?
Please advice.
Thanks in advance.
Subbu
Choose concurency mode as multiple only if your host object is thread safe i.e you have manually implemented locking on shared resource or your host object dont have any shared or class level objects at all. If host object is not thread safe use concurency mode as single as in this case wcf will automatically implement lock for you, only one request will be processed at a time on a context, parallel will be queued. So here decision should really depend on if your host object is thread safe or not.
We're planning a system running on Windows/.Net 3.5 that has a number of "services" that need to run in the background. Some will be active all of the time, but some will only be called occassionally and can be stood-up on demand.
As far as I can see, my options are:
Windows Services - always running(?)
IIS hosted something - called on demand
COM+/ .Net Enterprise Sevices - most complex option, but most powerful?
Distributed transactions is not a requirement, these are mainly computation engines, rather than transaction processors.
Does anyone have any experience of working with all of these and what further pros & cons can be claimed for each technology?
EDIT
Is suppose there are multiple ways of hosting code in IIS, web services, WCF (as pointed out below), any others? Relative pros/cons?
WCF feels like the right way to go. There are still many choices to make. WCF provides a number of communication mechanisms and hosting environments:
WCF combines the following technologies under one set of APIs-
ASMX;
WSE;
Remoting;
COM+;
MSMQ.
So for instance you can use persistent messages from MSMQ for occassionaly connected clients or standard XML encoding SOAP messages over an HTTP transport layer. You can also use new features in 3.5 like binary encoding of XML or JSON encoding over HTTP.
Hosting environments include:
Console applications
Windows services
WCF services inside IIS 7.0
and on Windows Vista or Windows Server 2008 you can use WAS (Windows Activation Services) to host WCF services.
Different hosting environments have pros and cons. I suggest you look at MSDN for more details (e.g. http://msdn.microsoft.com/en-us/library/bb332338.aspx).
Because WCF encompasses a lot of functionality it is more difficult to learn than any one of the technologies it replaces. I still think it pays for itself in the long run.
It depends on what the software will do, and how (and if) users or systems need to interact with it. Depending on those things, there may be one more, often overlooked, option: set it up as a scheduled task. This is often a very good alternative to a windows service, if the software is of the kind that will act on certain time intervals (check for a change in a database, act on the changed data and send it somewhere, for instance).
If you will have other systems talking directly to your software, I would imagine that a WCF application hosted in IIS would be a rather straighforward way. We use both those approaches in my current assignment; WCF services for looking up and storing data, and scheduled tasks for data calculations that run on a regular basis.
The scheduled task has one upside compared to the others in one specific field; it uses system resources only when running.
You mentioned starting up a process "on demand". WAS - Windows Activation Service, or sometimes called Windows Process Activation Servvice, though it is never abbreviated "WPAS" - is the thing inside Windows that provides on-demand process activation. The way it works - when a message arrives, WAS can start a worker process to handle the message. WAS was, prior to IIS7, fairly tightly integrated into IIS. It was used primarily to activate processes that did web work - like an ASP.NET worker process. With IIS7, WAS is generalized so that it can activate worker processes based on non-HTTP as well as HTTP messages. If you write your app to receive messages through WCF, you can get activation essentially "for free". That applies if it is HTTP, TCP, MSMQ; SOAP or otherwise.
The key thing with this on-demand startup though, is that it is tied to the communication. In fact the process lifecycle model for WAS is tied to communication as well. By default if there are no incoming messages after a while, the process will be shut down by WAS. That may or may not be what you want.
As for process hosting - COM+ offers a hosting environment but it is primarily intended for use as a host for processes that communicate. This may not be the perfect fit for you.
If you have compute engines, you may just want to run a Windows Service. A service like that can be started and stopped either administratively or programmatically. In the latter case, you could imagine a WAS-activated worker process programmatically starting a windows service.
You could also imagine writing a simple Windows Service that watches a location (filesystem, message queue, etc) for a message, and when that file or message arrives, the Windows Service starts up a compute engine process, which itself is NOT a Windows Service, but is just a process.
Speaking of MSMQ - That is basically the same model as MSMQ triggers. You can configure MSMQ to start a process when a message arrives on a particular queue.
There are lots of options.
We have an existing WCF service that makes use of wsDualHttpBinding to enable callbacks to the client. I am considering moving it to netTcpBinding for better performance, but I'm quite wary of moving away from the IIS-hosted service (a "comfort zone" we currently enjoy) into having our own Windows service to host it. I was hoping we could still host this on IIS 7 but Win2K8 won't be reality for us for some time.
What things should I watch out for when creating our own Windows service to host our WCF service? Things like lifetime management and request throttling are features that come free with IIS hosting so I'd also like to know how we can effectively host our service on our own without the convenience of having IIS do the hard work for us. Thanks! :)
So as you cannot host using WAS there are a couple of things to realise.
If the service crashes it doesn't restart by default (although you can change this in service properties)
IIS will recycle the application pool if it hangs or grows too big; you must do this yourself if you want the same sort of reliability.
You must create an account for the service to run under, or use one of the default services. Resit the temptation to run the service as SYSTEM or under an administrator account; if you want to use a built in account use NETWORK SERVICE.
It becomes harder to debug in situ.
Consider using a error logger such as log4net
Having said that I deployed a WCF/Windows service combination for a customer 9 months ago; it's heavily used and hasn't died once.
You can request throttle in a Windows service, it's part of the WCF configuration. Note the defaults are very low, it is likely you will have to increase these.
Hosting in a Windows Service Application (http://msdn.microsoft.com/en-us/library/ms734781.aspx) is a good start.
If you can host your service on Vista, you can also benefit from Windows Process Activation Service (WAS). WAS is a generalization of the IIS process activation, which can be used to activate processes over non-HTTP endpoints (TCP, Named Pipe, MSMQ). To learn more about WCF hosted in WAS, read http://msdn.microsoft.com/en-us/library/ms733109.aspx. To learn how to install and configure WAS, read http://msdn.microsoft.com/en-us/library/ms731053.aspx.