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.
Related
I work in a company that is only using WCF and i am trying to introduce service stack. Now i understand we are better off using the service stackclients that wcf clients but for some of our stuff and to keep people happy that will not always be possible. Can anyone provide a basic example of a ServiceStack service that can be added as a client into a VS2012 project using the add service reference inside visual studio as you normally do for a WCF service? Basically is there a way to make ServiceStack seem like a WCF service to people that don't know about ServiceStack?
If i can show this i think i can convince my company to make the switch but if not it will be difficult as everything else is WCF based. We are already using the ServiceStack clients to hook into other online websites so it seems a good time to try to convince them to move to the service stack services and clients as long as they feel they can fall back to the WCF client if needed.
Provided you adhere to the SOAP guidelines and limitations in ServiceStack you should be able to add a Service Reference by pointing the client to the ServiceStack wsdl at /soap12, e.g:
http://servicestackbaseurl/soap12
You can also find a link to the soap 1.1/1.2 wsdl (and XSDs) on ServiceStack's /metadata page.
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...
We have a windows service that is self-hosting a WCF Data Service, using the DataServiceHost class. Everything is working just fine, but we would like to hook up some HTTPModules to the service, if possible. One of the HTTP Modules would be for custom basic authentication, the other for auditing (including responses, which is why an HTTP Module works so well for this).
Keep in mind that we are running as a regular windows service, so we have no web.config, the service is not hosted by IIS, and it is not an ASP.Net application.
So, my questions are:
Is it possible to have an HTTP Module listen on a self-hosted WCF data service?
If this is not possible, what options would I have that are similiar to the power of an HTTP Module?
WCF doesn't operate on the same request pipeline as standard ASP.NET applications, although you can take advantage of a number of ASP.NET features (like session) if you configure your service for ASP.NET compatibility.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
However, it looks like you just need something that will let you jump into the pipeline the way that HTTPModules do for an ASP.NET Application. That being the case, there are plenty of options. You can check out this page for a lot of samples.
You mentioned authentication, and there are plenty of options built into WCF that can save you from rolling your own solution. Check it out here.
I am working on a Silverlight application that uses WCF. I need to have my WCF project separate from the ASP.Net application that will host my Silverlight project. I am looking for some guidance on how I should organize my solution and list gotchas other people have experienced during debugging and deployment.
Specifically my questions are
What type of project should I use for the WCF service?(A WCF project, an ASP.NET project with self-hosted WCF services, something else)
What do I need to so to get it so that when I press F5 I can debug both my Silverlight project and my WCF service? Will I need a cross-domain policy just to debug the thing?
Some background info on why I want to do this:
I have legacy web application that I am gradually converting over to a Silverlight application. Because it is a large web application some of its features will be converted to Silverlight before others.
The legacy web application has lots of code in it that is no longer used. Much of the code that is no longer used references 3rd part assemblies. This is why I want to get rid of the old web application. So obviously I don't want to host WCF services that will be kept for future versions in it. That is my reason for wanting to make the WCF project separate.
We're doing the exact same thing.
We're using a WCF project just in case we have to change how it's hosted in the future. (I.E. no longer using IIS)
2.a. You can have a solution with your silverlight projects, and your wcf project. The silverlight project will have a service reference to the wcf service in your solution. That allows you to debug using F5. However, when you go to deploy, you will have to change your app.config service URIs to refer to your production location.
2.b. You will only need a cross-domain policy file if your fully qualified domain names are different for the wcf service and the silverlight app. Ours happen to be different. Here is an excellent article on when to use the policy file: Clicky
Good luck!
Just remember that when you get ready to deploy, if your service is going to be hosted on a different machine than your app, you need to deploy the service first. Then re-configure your service reference, and finally re-compile your Silverlight before deploying. Otherwise, your Silverlight app will look for the service on your local machine instead of where you deploy it.