I'm hosting my WCF application with IIS. To serve some methods I need a reference to helper object which is heavily initialized. A good scenario is to initialise it once and put in a cache, then all requests just use the object from cache. How can I do caching?
The easyiest way is to use static field of mywebmethod. IIS creates several ServiceHosts to serve requests. And in every servicehost static fields will be different.
I aso tried using System.Web.HttpRuntime.Cache. Again, I have some independent caches.
To clarify, I need to cache not the result of the request, but some intermediate data needed to process request.
So what can be a solution?
Running diferent services in separate AppDomains gives you crash-protection and some other, security-related benefits. If you are sure you need shared statics, consider using self-hosted servies.
I can think of only one way to achieve this using IIS: implement a ServiceHostFactory, that will return custom ServiceHost that will start and stop multiple ServiceHosts under the hood. But it's waaay too hacky to be a piece of production code )
Update I stumbled upon this today, and this answer looks like a total mess. Different Service host do share one AppDomain if they reside inside the same IIS site, so static fields should be the same for all services.
Related
In article after article after article, any discussion of using an IOC Container (Unity, Windsor, etc.) with IIS involves the creation of a custom ServiceHostFactory and a custom ServiceHost.
The only reason I can see for that, is so that a custom service behavior, with an IInstanceProvider-related payload, can be applied to all services. So I'm trying to understand why the whole affair is not simplified by having an anonymous service configuration. Such configuration would allow a custom behavior to be applied to all services without using a custom ServiceHostFactory and custom Service Host.
That said, the only reason I can imagine a custom service host would be necessary is if the custom IInstanceProvider is recycled with each WCF instance or context instance. Certainly I would want IOC Container bindings to be established only once for each launch of my IIS ServiceHost rather than repeatedly or irregularly.
If my custom IInstanceProvider is indeed being recycled sporadically, then I could put my IOC Container into a custom service host - to insure that it will stick around as long as possible.
But again, if my custom IInstanceProvider will last as long as the in-built service host, then why not just skip the custom service host factory and custom service host?
In fact, taking this a bit further, if I were to put my IOC Container into a static member of my custom IInstanceProvider, then it wouldn't matter if the IInstanceProvider was being recycled irregularly. It comes full-circle: why do I need or want a custom ServiceHostFactory and custom ServiceHost to use an IOC Container with WCF?
Well. That's because most IoC/WCF integrations (like mine) does more than just creating your service (with it's dependencies).
Custom lifetimes / Disposal
Everything should get clean up properly when a request have ended. Your servcice and your IoC classes uses different lifetimes.
The end of a request can't be detected just with the help of an InstanceProvider.
IContractBehavior / IServiceBehavior
You can register behaviors in the container and automatically get them added to your WCF service.
Personally, i'm a fan of using a design where you don't need any ServiceHostFactory, ServiceHost, ServiceBehavior, and InstanceProvider combination and where you don't have to register the factory in your .svc file. I like my WCF service as just a really thin layer on top of a message passing architecture, and this saves you from using this WCF integration stuff. You can read more about such a design here.
Interesting question! The only reason I could think of for doing it this way is that you don't want to clutter up your app.config with items that are never going to change (i.e. the IoC container used by your WCF services). I try to restrict my use of the app.config to things that an end-user / developer might conceivably want to change without recompiling (in most cases, not much). This makes it more readable, and it is usually easier to specify configuration programmatically as there is better support for intellisense and compile-time checking within program code as opposed to configuration files.
However, this argument might not apply to the first article you linked to, because they're actually setting up their IoC container through the app.config. So it might be a double standard in this case. I've never really understood why people want to set up all their dependencies through external configuration files anyway. Storing static configuration in the app.config just seems like overkill to me in most cases.
Have a winform application and want to host a WCF service inside it. Do I need to host it in a seperate appdomain? Any recommendations?
You don't need to host it in separate domain but you must decide if you want service request to be processed by UI thread or different thread. It depends on the way you create ServiceHost instance or on ServiceBehavior applied to your service class.
When service is hosted in UI thread it can directly interact with UI but request processing is part of message loop and all service requests are processed by single thread (sequentially). When request is processed no other windows event (including UI events) can be processed = application freezes.
When service is hosted in different thread it behaves as in any other hosting environment but it can't directly interact with UI - you must use delegate invocation.
Ways to enforce service to run in own threads:
Create and open ServiceHost instance before you call Application.Run (start of Windows message loop)
Create and open ServiceHost instance in separate thread
Use [ServiceBehavior(UseSynchronizationContext = false)] on your service implementation
No, you don't have to host it in a separate AppDomain. Just host it. There's nothing terribly special about WinForms in this regard.
What's your app do? Is the service a part of the apps regular functions or a completly seperate logical entity?
If you want to be loading and unload resources (such as assemblies) related to your service without shutting your app down a seperate app domain would make this much easier, but otherwise I don't see much of a reason to complicate things.
Just my 2c. :-)
You can host in Win form but you have to keep it running throughout.
Also suggest you to host in IIS so any type of client avail your service.
So I'll be providing a few functions via a self hosted (in a WindowsService) WebServiceHost (not sure how to process HTTP GET/POST with ServiceHost), one of which may be called a large amount of the time. This function will also rely on a connection in the appdomain (hosted by the WindowsService so it can stay alive over multiple requests).
I have the following concerns and would be oh so thankful for any input/thoughts/comments:
Concurrent access - how does the WebServiceHost handle a bunch of concurrent requests. Are they queued and processes sequentially or are new instances of the contracts automagically created?
WebServiceHost -> WindowsService communication - I need some form of communication from the WebServiceHost to the hosting WindowsService for things like requesting a new session if one does not exist. Perhaps implementing a class which extends the WebServiceHost with events which the WindowsService subscribes to... (unless there is another way I can set off an event in the WindowsService when a request is made...)
Multiple WebServiceHosts or Contracts - Would it give any real performance gain to be running multiple WebServiceHost instances in different threads (one per endpoint perhaps?) - A better understanding of the first point would probably help here.
WSDL - I'm not sure why (probably just need to do more reading), but I'm not sure how to get the WebServiceHost base endpoint to respond with a WDSL document describing the available contract. Not required as all the operations will be done via GET requests which will not likely change, but it would be nice to have...
That's about it for the moment ;) I've been reading a lot on WCF and wish I'd gotten into it long ago, but definitely still learning.
Concurrent access - this is something you can set using ServiceBehaviorAttribute. there are a number of options -- you can have WCF create a new instance of your service class for each incoming request, or you can have a single instance handle all requests. Additionally you can tell WCF whether to pass you the requests serially or concurrently.
WebServiceHost -> WindowsService communication. Two approaches spring to mind: WCF supports a mode called "well known instance" where you pass an instance of your service to the ServiceHost constructor instead of passing a Type and letting WCF instantiate it for you. With this mode you can preconfigure your service instance with a reference back to your hosting code (alternatively you could use events). An alternative if you want to preserve instancing flexibility would be to have a static method in your hosting code that the WCF service could call back into.
Multiple WebServiceHosts or Contracts - really no advantage to having more than one ServiceHost instance. see also this SO thread: What are the benefits for several servicehosts? Does one ServiceHost support several simultaneous connections on one endpoint?.
WSDL - While you can enable WSDL by turning on metadata publishing (http://msdn.microsoft.com/en-us/library/ms788760.aspx), WSDL support is intended for SOAP-based services, not pure HTTP GET/POST. The WSDL that gets auto-generated for your service will likely not be very useful.
I have a WCF service in which I would like to do some initialization-type operations based on the configured EndpointAddresses for a few different contracts implemented by the service.
The service can be (and is) hosted from within a few different Service Hosts. There is a console application which creates a service host, a windows service which creates a service host, it lives in an IIS host and I would also really like to be able to use the Visual Studio service host for debugging.
Is there any way to get a reference to the ServiceHostBase which created the instance of the service without being inside a service operation? Or maybe a better (read: trickier) way of figuring out what endpoints the service is servicing?
Let me see if I have this straight: You have a single Service implementation that is exposed from multiple ServiceHosts, and you want to do some different initialization for each servicehost? Or is it for each endpoint exposed?
It sounds to me like there are a few options here, but it depends on exactly what you want to do. If the intialization is per-host, then why not just use your own ServiceHost implementation and do the initialization there instead of the service?.
I ask this particularly because it is not clear from your description what the instance mode of your service is or when you want to run the initialization code itself.
If for whatever reason you can't do that, another option worth exploring could be to do the initialization in a custom IServiceBehavior during ApplyDispatchBehavior(), where you've got access to the service host and the service description.
I'm trying to cache some application data that only needs to be instantiated when the application starts. I've tried using HttpRuntime.Cache, creating a static object that is instantiated only when the service starts, and I've tried making the service singleton and using global variables. Every time a new request hits the service I loose state... I could create the WCF service as a windows service I suppose, but I'd love to figure out what's happening here... I see that only one IIS worker process is spawning, but I'm guessing it's unloading and re-loading the service every time.
Am I missing some WCF configuration or possibly not setting it up right in IIS? It's running as a normal 2.0 website within IIS.
This my first post here, if someone can tell me how to post my app.config XML I will... I think stackoverflow is trying to parse it as HTML, it doesn't show up.
Thank you!
Tim
We use enterprise library caching with WCF services, works for us:
http://msdn.microsoft.com/en-us/library/dd203099.aspx
Edit
This answer is a bit old we have now stopped using Enterprise Library Caching, we use app fabric instead, see: http://msdn.microsoft.com/en-us/windowsserver/ee695849