I have .Net framework application with WCF services. I am using different sets of protocols such as NetTCP and NetNamedPipes. I am migrating these services to .Net Core with gRPC. As gRPC only supports HTTP/2, is there any way for client application to be remain untouched while this migration or is there any way gRPC support NetTCP protocol?
References:
https://codemag.com/Article/1911102/gRPC-as-a-Replacement-for-WCF
https://www.seeleycoder.com/blog/migrating-wcf-to-grpc-netcore/
GRPC is based on http2, and while nettcpbinding is efficient, the gRPC is the best approach for building distributed applications, http2 has achieved equivalent speed and performance, and in some cases, even better. Also, GRPC only supports http2 as far as I know. Please refer to the below links.
https://learn.microsoft.com/en-us/dotnet/architecture/grpc-for-wcf-developers/network-protocols
https://learn.microsoft.com/en-us/dotnet/architecture/grpc-for-wcf-developers/wcf-bindings
Feel free to let me know if there is anything I can help with.
Related
I know we are comparing 2 different technologies, but I would like to know pros and cons of both. WCF is present for almost a decade now. Didn't anything similar exist in java world until now?
At a very high level they would both appear to address the same tooling space.
However, the differences I can pick up on:
GRPC does not use SOAP to mediate between client and service over http. WCF supports SOAP.
GRPC is only concerned with RPC style communication. WCF supports and promotes REST and POX style services in addition to RPC.
GRPC provides support for multiple programming languages. WCF supports C# (and the other .net languages).
GRPC uses protobuf for on-wire serialization, WCF uses either XML/JSON or windows binary.
GRPC is open source
In short:
GRPC seems a much more focused services framework, it does one job really well and on multiple platforms.
WCF much more general purpose, but limited to .net for the time being (WCF is being ported to .net core but at time of writing only client side functionality is on .net core)
Apart from the answers mentioned, i wish to add that gRPC does not support windows/kerberos authentication, which is the defacto authentication mode in the corporate world.
For this reason, its very hard to migrate from WCF to gRPC.
As tom already mentioned:
WCF uses either XML/JSON or windows binary
while gRPC use binary, which makes messages much thinner and faster to deserialize on the client/server end-point. simply by dropping the human readability feature.
Also, please note that WCF needs extra configurations (and hassles) to comply with HTTP2 to gain its profits, e.g: shorter header and body (which means even faster transmission), more secure and reliable connection, and multiplexing (a.k.a multiple request/response in parallel), server-push and so-on ..., while gRPC has already embraced it.
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 would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
Why we are going for WCF when web services (ASMX) exist ??
Here is a nice article that you can look at
Comparing ASP.NET Web Services to WCF Based on Development
WCF supports protocols beyond HTTP (TCP and MSMQ come to mind) and message formats beyond XML, so it could be used for tasks they are unsuitable e.g. because these tasks require better performance.
WCF could be self-hosted so no need for hosting in IIS.
WCF supports preserving service object state between calls.
Another rather interesting and thoughtful comparison:
http://www.keithelder.net/blog/archive/2008/10/17/WCF-vs-ASMX-WebServices.aspx
Download the PowerPoint and have a look at it - also, watch Keith's DotNetRocks TV appearance for a great screencast intro to WCF and its advantages over ASMX.
Marc
Web services require use of HTTP protocol on standard HTTP ports, right? WCF is more flexible. It can be based on HTTP, TCP, UDP and such. It allows you to design an application with network connectivity without caring so much about the protocol used. Then you can more easily switch the network protocol without affecting the application.