As we know WCF is a web service and SignalR is a technology for using it for bi-directional actions, So I would like to know what is the exact difference between WCF & SignalR and why can't we use SignalR in place of WCF??
SignalR is only used when the scenario is about real time bidirectional communication , the same can be achieved by using WCF with the appropriate binding
Though WCF is more suitable for request/response scenarios with more control over protocols used , security , encoding...etc
so SignalR is a better choice for real time communication and WCF is a much better choice for any other scenario
Related
I have a WCF service and I need to setup the service to broadcast notifications to all the connected clients. However the call to WCF is made from jquery. So I need a method to be able to call back the jquery methods from WCF for broadcast. So basically I need a way to be able to call the jquery methods from WCF.
Please let me know if its possible and also any sample to illustrate it.
Calling WCF directly from JQuery for your scenario is not a good solution.
You cannot use WCF duplex outside intranet environments because of issues such as firewalls.
You have browser clients and you need to broadcast. Try using any implementations of xmpp such as SignalR. Implementing SignalR from scratch is much easier than maintaining your current WCF code in this scenario.
I have one WPF client-server application. Now I have scenario like client will connect to server and server will push data to client periodically. I am bit confused about what technology and way should I choose for notification to clients.
SignalR is best for web application I think and I have desktop application. With WCF service, we can implement push notification through Duplex channel and callback. So can you please guide me what are the merits and demerits in using SignalR or WCF service ?
Thanks
Below are my observations from experiences:
SignalR pros:
Easy to startup, lower learning curve. You can easily run an example found from web
Exception handling (e.g. connection drops, timeouts) is embedded inside the API
SignalR cons:
Only supporting HTTP protocol
Duplex pros:
Supports TCP in addition to HTTP. This may be a serious performance gain if you know your client types and your system is working in a closed network. Also, working over TCP adds more connection stability than HTTP
Duplex cons:
Higher learning curve - harder to startup and have a stable solution. Want to verify it? Download a duplex and a SignalR sample from the web and see how much time you will spend to successfully run each other.
You need to handle all the exceptional cases (connection drops, timeouts, etc.)
I know I am not the only one who faced serious timeout problems when you want to use the duplex service for a long time. We need to make service calls periodically to keep client connections alive.
By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.
SignalR is not just about web. SignalR server side code does not care about the technology of its clients, you just need to have implementors at the client side.
If we isolate pusing data to the client, I would strongly recommend SignalR as it's much simpler than WCF in this aspect, I had my share of problems with WCF and I guess you had some yourself.
I found a simple console/web application sample here.
In general, Duplex WCF and using Callback like here seems very messy to me, there is a lot of configuration server side and this is why I think SignalR is simpler.
In addition, you can't use duplex (AFAIK) with javascript and objective-c.
I think you already got lots of data points about each of them. But selection of SignalR will provide you added advantage over development efforts which is in most of cases major decision block while selecting a technology.
You don't need to worry about API development / testing etc. and can have focus on your own implementation of the project.
Hope it helps!
SignalR can easily be used now with multiple clients from javascript, .NET both WinForms and WPF, and can even be used with a C++ client; Using a self hosted .NET signalr server (OWIN) is really nice way to have a standalone server that pushes / receives / broadcasts to multiple clients. The only thing that may be easier is ZeroMQ using its publish subscribe methodology.
One point that nobody has raised so far:
SignalR 1.0.1 requires .NET 4 on the server and client. Depending on
the version of your client and server that you are targeting that
might be an important factor to consider.
If you just want to update periodically for new data, you might be better to just use WCF and a polling mechanism from the client side rather than using either duplex WCF or signalr.
What are the pros and cons of using each technology?
WCF Web Api is now merged into Asp.net
Asp.net web api now supports self hosting.
I still imagine if I want to expose multiple protocol schemas for the same operation I would still lean towards WCF or can Mvc end point do this too?
Also does the new Asp.Net web api expose Wsdl? If not how would the client figure out what operation is available to them?
Arguably the best feature of Mvc is the modelbinder. How robust is the WCF equivalent?
So can someone tell me what advantage does the Asp.net web api bring to the table? WCF seems overwhelmingly the more powerful/scalable choice, imo. About the only thing the Mvc Web Api has over the WCF model is probably ease of development, but that means squat if it ends up being a serious design limitation down the road.
First, I suggest you read my post on the subject:
http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx
Regarding your WSDL question - since the WebApi does not use SOAP, it does not require a WSDL, and does not export one. You can use Hypermedia to return resources with a list of possible activity URLs (think of it as a self-describing resource)
The choice depends on what we want to do.
ASP.NET Web API is a framework for building non-SOAP based services over HTTP only - so there aren't more transport protocols available using this framework.
WCF / Windows Communication Foundation is a framework for exchanging SOAP-based messages - here we use a lot of transport protocols: HTTP, TCP, Named pipes, MSMQ, etc...
I am not sure about which one has better performance regarding the amount of data, maybe WCF since we can use low protocols. Any comments are appreciated.
The WCF Web API primarily focuses on REST implementations. If you are setting up a REST implementation, the standard WCF bits are a bit of a pain in the rear. If you are setting up RESTful services, you will find the WCF Web API a much nicer experience. If you are setting up SOAP services, then the WCF Web API is not your best friend, and you are better off using WCF for your services.
Use WCF for intranet/B2B sites n Web API for B2C/C2C/internet sites...SOAP/XML is still the standard for intra-businesses communication n it's not going to go away!!!
I am new to .net and am trying to use c# as the basis of my .net learning. I have a project where I need a service to connect to mutliple tcpip applications that are a 3rd party application written in vb6. Someone has mentioned using WCF as the base, but i'm not sure how it would make an outbound connection (instead of receiving incoming ones) to a non .net application? Please help
With C# and WCF, you can either create:
a WCF service which will offer up some functionality that other applications can call
or:
a client that connects to some other SOAP or REST service to consume functionality.
So which one is it you're looking for??
Also: WCF is a SOAP or REST based service stack - you cannot use it to connect to low-level TCP calls (socket programming). Your "other" side must understand either SOAP (the web service protocol) or REST (the URL-based lightweight protocol). If you other sides don't speak neither SOAP nor REST, you're out of luck and can't really use WCF for that.
You'll have to deal with socket programming, WCF won't help you here.
Try reading this: http://www.codeproject.com/KB/IP/socketsincsharp.aspx
I'm writing a server app with a silverlight client. At some point I'd like non-silverlight clients to be able to use my services. Right now I've written some WCF services which get polled, but I'm not happy with the responsiveness. I'm thinking of switching the code over to using Silverlight/WCF duplex polling, but if I do that, will I be stuck with Silverlight as my only client? Is it better to write my own long-polling service using normal WCF http services?
I don't see your issue there. You can just define another binding for use by other clients (like WsHttpDualBinding). The same server code will perform the exact same task regardless of the underlying binding. That's the whole point of using WCF.
You can find a AJAX sample here for using a WCF duplex service http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html
By other .NET client - yes. By anything else : no. WsHttpDual is definitely NOT an interoperable protocol. It also has plenty of other drawbacks and pitfalls and I'd try to stay away from it as much as possible......
Marc