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...
Related
I have a RESTFul WCF service and it needs to be deployed now. I am really confused whether to deploy in windows service or IIS 7. I need to implement SSL also so the protocol would be HTTPS. It is just a simple service consumed by client using HTTPS protocol.
Please let me know which one is better.
Your question seems to have been asked (and answered) previously.
The following link provides a good discussion:
IIS WCF service hosting vs Windows Service
If your RESTFul WCF Service needs to be accessed via http (or https) protocol, then deploy in IIS7.
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 am currently working on a silverlight client, making use of a web server, and an application server.
Most of the users sit within our firewall, so they do not have any problems accessing the WCF service running on the application server (through a Service.svc file).
However, some users will sit outside of our firewall, and only have access to the web server, and not to the application server (Where the WCF service is).
I am hoping someone could tell me if there is a way for the client to use the WCF service on the application server, through the web server, without rewriting the WCF service on the web server, and only relaying the calls through that server.
I hope this is a clear enough description of what I need.
Thanks
Sounds like what you want is a router service. Unfortunately, there's nothing built-in into WCF to do that (at least until .NET 4.0 with its RoutingService.).
You can certainly build it yourself, either by building a specific, one-off routing service (i.e. you implement the same contract and manually forward each operation to the service inside the firewall), or by building a generic, reusable routing service.
If you choose the second option, a couple of articles might help get you started.
Rather than have your Silverlight clients accessing the application server directly, route all the requests through a proxy service on the web server.
An example of this is the "Cross Domain Proxy" pattern.
I am new to WCF and Web Services in general. What are the improvements that WCF brings to the table? Can anyone give a side-by-side example of a traditional web service and the same one written using WCF and point out the differences and advantages?
Duplicate question Moving ASP.net webservices to WCF
EDIT: Think i found the answer you where looking for a side-by-side code based comparison and even better it's from MSDN: Comparing ASP.NET Web Services to WCF Based on Development
There are several related questions:
Difference between aspnet web method and wcf webservice
Benfits of using WCF
Moving aspnet web services to wcf
However you asked for a side by side comparison in which case i think Sam's Wcf vs ASMX blog article is more what you are looking for.
Quoting ad-verbatim (let me know if i should just leave it as a link):
WCF vs. ASMX
Protocols Support
WCF
HTTP
TCP
Named pipes
MSMQ
Custom
UDP
ASMX
HTTP only
Hosting
ASMX
Can be hosted only with HttpRuntime on IIS.
WCF
A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
WCF services are known as 'services' as opposed to web services because you can host services without a web server.
Self-hosting the services gives you the flexibility to use transports other than HTTP.
WCF Backwards Compatibility
The purpose of WCF is to provide a unified programming model for distributed applications.
Backwards compatibility
WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
Existing applications are able to upgrade with WCF
New WCF transacted application will work with existing transaction application built on System.Transactions
WCF & ASMX Integration
WCF can use WS-* or HTTP bindings to communicate with ASMX pages
Limitations of ASMX:
An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.
WCF is far wider in scope than ASP.Net webservices.
WCF can run in any application. APS.Net webservices only run in IIS.
WCF supports models like ReST, Remoting, SOAP, MSMQ etc. ASP.Net only supports SOAP
WCF is more configurable.
WCF supports a more declarative way of programming. You can get more done with less code.
ASP.NET Web Services are pretty much just that. Web Services. They're SOAP/WSDL based and provide their services only to the web.
WCF Services offer a much more flexible framework. For instance, depending on how the service is defined, it can be a Web Service hosted in IIS which serialized its data via XML and uses the REST model...or it can be a Remote Windows Service that is hosted in it's own process and serializes its data via binary. All of this is achieved using the different Service/Data contracts in WCF.
In short...you can make a WCF service look almost identical to a .NET 2.0 Web Service fairly easily but, with a little work, you can do a WHOLE LOT MORE.