My organization is transitioning from MS WCF services to Web API services. One big difference I've noticed is in the startup behavior. If a WCF service isn't spun up, it waits to return until it is spun up. However, if a Web API service is not spun up, it returns 500s until it is spun up.
Is there any way to configure the Web API applications or IIS so that it starts up more like a WCF service, in that it doesn't return anything until it's spun up? I've googled extensively but have been unable to find anything addressing this.
As an FYI, app init isn't an option for us right now.
I believe this is configurable via IIS.
See here:
Auto-Start Feature
Related
I was reading this article in looking for differences between creating an API using WebAPI and MVC and came across this statement:
In simple load testing on my local machine, I’ve found that Web API
endpoints hosted in console apps are nearly 50% faster than both
ASP.NET controller actions and Web API endpoints hosted within MVC
projects.
As such, I'm interested in how this would take shape in a production environment.
Obviously I'm looking for performance, so I looked into OWIN and self-hosting. However I'm not clear on if this offers the same efficiency as the console app discussed above.
Can someone please explain the proposal of hosting an API console application for consumption in a production environment - i.e. how would you connect a URL to the console app, etc.?
Thanks.
My understanding is self hosted OWIN apps can be run within any kind of app domain e.g console, windows forms, windows service, AWS EC2, Azure Worker Role etc. The application you should run it in is dependent upon the hosting environment you choose, there are lots of options.
I've implemented an OData service using ASP.NET WebAPI. I also have some existing web methods in a seperate WCF project which is hosted in an ASP.NET Web Application.
By copying some bits of web config around and copying a couple of code files I've managed to get the WCF methods hosted in the WebAPI project.
Everything seems to be working but I've got a nagging doubt I'm doing something horribly wrong that's going to break when I least expect it.
Is this a good idea?
Depends on your anticipated call volume. The only problem I can think of with this is that incoming WCF requests will be serviced from the same dispatcher thread pool as the OData service. This makes it more likely that you will suffer availability based issues on either endpoint.
What are the pros and cons of hosting a WCF service in IIS versus using a Windows service?
FYI - I have googled but it's surprisingly hard to find relevant answers.
We've just implemented a big WCF service, and did it as a self-hosted windows service. The reason we did it that way was our architects wanted the extra control you get from hosting your own and taking IIS out of the equation. Basically, when you go the self-hosted route,
you process each request
you configure your own endpoints
you configure your certs
you control the exception handling
etc.
Our WCF service is industrial scale with rev proxies, load balancing and about 50 methods attached to the endpoints. And we use multiple encryption protocols depending on the types of devices connecting.
However, if I was doing a smaller WCF web service with just a single server, a single endpoint and a few method calls, I'd probably use IIS to manage the endpoint and implement the SSL letting the UI do the configuration work that would otherwise have to be done in code. It's just easier from what I've seen.
Long story short, if you host it, you control everything in code. If you're interested in a quicker delivery, I'd start with IIS.
I want to create a restful web service that can accept json and returns json responses on a Windows server written in C#.
This particular service will actually have a long running background thread, so a WCF service hosted in IIS won't work (as far as I can tell, IIS will stop and restart the service on/after each request).
In general, I do not really even like WCF since I don't like dealing with generating proxy classes and updating service references down the road.
How can I accomplish this?
Well, with respect to WCF, is a technology already proven to help you build robust services, during your software design process you can design the service to keep state, hosting singleton instance, etc, so your impression of WCF services are somehow incomplete.
Now, regarding the restful approach, the technology used nowadays is called Web API, you can see some examples in the following website : http://www.asp.net/web-api , this will help you to avoid the tipical WSDL and generating proxies that you are talking about, and you can have bare-metal RESTful queries like "(http://myapp/orders/?id=1) that could return a json object with the orderid=1
Here you can have info for the instantiating mode in WCF services: http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
hope it helps,
I've been looking into the possibility of using ASP.NET Web API and SignalR in a self-hosted application, and I noticed that the ASP.NET Web API self-hosted implementation uses WCF, and the SignalR self-hosted implementation uses System.Net.HttpListener. This makes it a little harder to come up with a combined self-hosting solution, but it does get me wondering why the different project teams would use different approaches.
What are the advantages and disadvantages of each approach? Is there any particular reason why SignalR could not use WCF self-hosting, or Web API could not use HttpListener?
EDIT: I understand that Web API self-hosting provides a more complete stack than SignalR, my question is more about why you would choose a WCF implementation over System.Net.HttpListener when implementing your own self-hosting solution.
Web API self host provides entire HTTP stack so it's much much richer than System.Net.HttpListener.
SignalR uses that to purely open a communication window for its own purposes.
So yeah for now, you need to run them in parallel on different ports.
In the future, with OWIN, you will have everything under one roof.
EDIT: there was actually an issue similar to yours raised on SignalR github, and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277
Just so we are on the same page, The WCF Self-host that Web API Self host uses, does use HttpListener under the covers. However, I think I may have found a major downside to the WCF Self-host.
I have not confirmed this yet, but it seems that when you use Web API Self Host, the base address you provide is not translated directly into a HttpListener prefix. It seems like WCF translates the base address and wildcards the host.
This means that the WCF self-host will respond to any host on the specified port. This means that you cannot run a Web API Self hosted service side by side with IIS on the same port using a different host name.
This might be the reason that SignalR decided to scrap the WCF Self-Host and use HTTPListener directly.
While you can use the WCF stack to host the services yourself, you may want to consider the "IIS 7.0 Hostable Web Core". It has the benefit of running IIS in your user process. Using this approach, you can have several applications running on the same port, irrespective of the technologies.
If you are interested, you can look at:
Host your own Web Server in your application using IIS 7.0 Hostable Web Core
Creating Hosted Web Core Applications
This all assumes you are running Vista or later...