All,
I have developed a WCF Web Service and hosted it in IIS7.5. The service behavior is instanceContextMode=InstanceContextMode.PerSession and hence IIS creates an service instance during the first requests and creates as many instances as the number of requests.
But there is a requirement to cache some of the application data upfront before the service is invoked ie., similar to static initialization.
I don't want to disturb the service behavior attributes but want to achieve the static initialization.
I did try to use CustomServiceFactory and take up the load of creating service factory instances myself. But looks like the IIS will create the service factory as well during first request or I am not sure on this part.
So, I would like to know how to create the service instance / service factory instance when the application is deployed in IIS or during IIS restart?
Any help is much appreciated!
We are using the auto-start feature of AppFabric to initialize the services on application startup/app pool recycle. It invokes each service inside the application once during application start.
Related
We have WCF service running on IIS and would like to implement caching data for separate callers so that not each request for data would need to go to database. Is there a way to enforce IIS to create separte WCF service instance for different callers?
We use LAZY creation of the cache and from logging it seems that only one instance of service is created.
I have WCF hosted in IIS. There is a service method which gets the latest Db table record and do some work.
I want my web service to periodically cheks the database table and if there is new record deposited in the table then do the work.
I know how to handle this If my WCF hosted as windows service. But have no idea to do with IIS hosted WPF.
Please advice me.
if u need your wcf service to be invoked at some defined intervals, you can use Quartz Scheduler, where we can specify a particular task to be executed at defined intervals
pls check this link
http://quartz-scheduler.org/documentation/quartz-2.x/tutorials/
It will basically be a Windows Service, with your WCF service reference added to it.
you can just use the Quartz API.
I'm new to WCF and need some assistance with architecture for the following solution:
I want to create a WCF Service that hosts a FileSystemWatcher. This service must watch a series of folders on the machine and when a file is placed in a folder or is renamed I need this WCF service to 'Publish' an event.
Another WCF service must then 'Subscribe' to this event and do some processing.
The basic idea is that there is one service to monitor a predetermined set of directories, whilst an appropriate service gets notified that there are files available for processing.
So my questions are :-
1. Regarding the FileSystemWatcher WCF Service, I want to host it in AppFabric but am not sure exactly how this is going to work. I.E. When this service is deployed to the server I want the appropriate FileSystemWatcher object to be called and stay 'on' and monitor folders indefinately. Can WCF do this in this manner or is this a better candidate for a Windows Service
2. Can one WCF service publish events and another WCF service subscribe to these events and how? All WCF services hosted inside AppFabric?
WCF is a communication framework that can be used to expose or consume SOAP/REST services. A Windows Service is one way of hosting such applications. WAS/IIS and self-hosting are other methods. A Windows Service provides greater control of service startup/shutdown, which seems relevant to your scenario.Windows Server AppFabric improves some of the control over applications lifecycle hosted in WAS/IIS, but it is still a fundamentally different hosting choice to a Windows Service.
As far as I know WCF has no inbuilt event publishing capability (I assume you're referring to the publish/subscribe pattern). However, you can implement such a pattern using WCF duplex channels. There is no restriction on an application concurrently acting as 'server' and 'client'.
It is my understanding that a WCF service configured for net.msmq will not run as an HttpApplication when hosted in IIS/WAS, which means you don't get the events in Global (Application_Start being the important one). Am I correct in this regard?
Does using Windows Server AppFabric to auto-start the service hit the service over HTTP, causing the Application_Start event to fire? If so, is this reliable?
I guess my real question is, where is the "proper" place for initialization code for a non-HTTP WCF service?
Particularly (since the right place may be different for different stuff):
IoC registrations
log4net initialization
Verifying the MSMQ queue exists locally (as Juval Lowy suggests in his WCF book)
Follow-on question: Do the events in a custom IServiceBehavior fire on every request or only once at startup? What about ServiceHost.OnOpening() - every request or only once at startup? (My testing shows it's only once, but does anyone know where the WCF "lifecycle" is documented, because I can't seem to find it anywhere.)
I can't verify that WCF services hosted in IIS/WAS can't be configured to support Application_Start but it is not required to do what you want. I'd recommend you create a custom ServiceHost in conjunction with a custom ServiceHostFactory (for WAS). This approach is documented in an MSDN article and this blog post. Using this approach, you can host your service in IIS/WAS, a Windows Service or a console app because the initialization process will be the same.
I have a WPF client application that is connected to WCF Service. How can I set up my project so that in DEBUG configuration it points to the WCF Service in the solution and in RELEASE configuration it points to the WCF Service on the internet? Can I do some sort of App.Config transformations? It takes so much time to erase the service references and recreate them to point to the deployed WCF Service.
Just my thought, you can develop a facade class that can choose which service to call. And in that facade class, you can use #DEBUG macro to distinguish the code.