I am now working on a client-server communication project. I implemented the server using UDP client method by simply passing text strings between client and server. But I would like to change it to WCF method. I did some research online about WCF but still cannot figure out what are the difference between WCF and UDP. Need some explanation about it.
You are attempting to compare two different concepts. Per the Microsoft web site,
Windows Communication Foundation (WCF) is a framework for building
service-oriented applications.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf
WCF supports a variety of formats - not just SOAP. WCF also supports a variety of transports - one of which is UDP.
The answer to your question is WCF is a client-server communication framework that supports, among many other things, SOAP using UDP.
Related
I have an old non-WCF Windows Service that creates a TCPClient to connect to a non-WCF TCP Server. I can't change the server app at all. It attempts to create a 2 threads, one for reading and processing messages from the Server, and one for reading from an MSMQ queue, processing, and then for sending to the TCP Server. Unfortunately, there are problems, and sometimes if there is a network disconnection I will get two instances of either the read or write threads. The threads share the same TCPClient connection.
Was hoping to switch my service to WCF, hosted by a Windows Service. I know I could use MSMQIntegration binding for a send method, but I am not sure how I could bind to a shared TCP connection. netTCPBinding seems to also be limited to WCF to WCF connections. Does anyone have suggestions on how to proceed?
This is theoretically possible with WCF's extensibility, but you would have to write a custom endpoint, a custom message formatter, and the fifty other classes. I'd recommend implementing the TCP service separately.
WCF Extensibility is best considered when you are dealing with a SOAP-like service which uses XML-like messages over a standard endpoint (transport). When you are "pretty close" to that, you can usually patch over the differences. When you are using none of that, WCF becomes a hindrance rather than a timesaver. For example, I would use WCF extensibility if:
I had a SOAP service which needed to run over SMTP or some other odd transport (custom endpoint)
I had a custom xml format that runs over a standard endpoint (I*MessageInspector)
I had a custom format which can be readily converted to XML running over a standard endpoint (custom message encoder)
I would not use WCF for:
Any format which does not convert readily to XML
Any format which does not readily identify the Action / target method
REST services (despite internal support - look at MVC Web API)
Anything requiring transport of large binary blobs (unless MTOM covers it)
Services where more than one of the built-in components have to be replaced
WCF library is the library that allows developers to communicate between WCF and non-WCF services in protocol agnostic way. Service developers using WCF don't need to known the details of protocol used between these services because these intricacies are hidden in WCF bindings. So the service developers have just to configure their client or server endpoints/bindings/behaviors correctly and these endpoints/bindings/behaviors do all the labor.
But WCF in not an universal platform to communicate with 'anything'. For instance NetTcpBinding uses TCP sockets to communicate. TCP protocol allows to create a pipeline between both parties but when this pipeline is established, TCP doesn't specify or mandate what content should be send through this pipeline. It can be some standardized protocol like HTTP, or proprietary custom protocol invented by SW developer that has never been published. There are hundreds maybe thousands of custom protocols that can flow through TCP including protocols like Modbus via TCP or IEC104. These 2 protocols for instance were specially designed to be tiny to communicate with the embedded devices and can't be used as the protocols for exchanging universal messages between Web services.
NetTcpBinding sends through TCP pipeline its own completely independent protocol designed by MS to provide efficient communication with WCF services build upon NetTcpBinding. It can't be used to communicate with your custom service using some unknown protocol with different (unknown) data serialization, timing, security, data exchange patterns, etc..
So the only viable option here is to use 'raw sockets' - classes like Socket or TcpClient to communicate with your proprietary service. But at first you must know what protocol your TCP Server is using. Maybe it's some standardized protocol like SOAP or HTTP or completely independent proprietary protocol that has never been published or documented.
And even though WCF has many extensibility options that allows developers to extend WCF library, these extensibility options are meant to be used when you want to allow WCF to communicate via other transport protocol (UDP, serial line, shared network path) or to add some new features to WCF bindings like new security option some extended transaction support or logging. But extending WCF to communicate with some non-WCF proprietary service (using some home-made protocol) would be inefficient (maybe impossible) and over-complicated.
So if your non-WCF service isn't using protocol that very close (virtually the same) as the protocol NetTcpBinding is using then WCF is not an option here. Use Socket or TcpClient classes.
How to transfer an object p2p via internet using WCF C#?
I have an .NET desktop application which is running on 2 different computers which are located in different countries . But now I want to transfer a object from one application to another using WCF .
is there any way to transfer an object from one application to another application via internet using WCF C#
I mean, for that where should I host the WCF service and is this done by WCF callback service?
Here is a pretty detailed article on using Peer-to-Peer programming with wcf and .NET Framework 3.5.
With a little work you could probably tie a SignalR client into your Winforms app. I have never tried to wire up a signal R client in a library. SignalR was designed for p2p and it may offer more functionality depending on your requirements.
currently my WCF Service is using net.pipes to talk on local machine.
Now I want to consume the web service in java on the same machine.
Here I have some questions:
Which binding I have to use to talk on local machine with Java client?
I don't want to go over network and the client must be able to consume the web service.
Do you may have any articles or tipps how to start here? May some hints what I have to take care about?
BasicHttpBinding exposes a SOAP 1.1 wsdl which is probably the most interoperable between JAVA and .NET. If your calls are local then you won't go out to the network.
EDIT
WsHttpBinding supports SOAP 1.2 which is a larger, more complex specification and therefore more open to interpretation by different vendors. So while it may work fine, it will generally be less interoperable.
Specifically there may be differences in the way security is handled on either side (see here for a good explanation).
I was comparing Web service with Remoting from performance and interoperatibility point of views
and have some doubts regarding it.
1) As Remoting support both TCP and HTTP channel, so is it when use TCP channel
It uses binary formatting and when HTTP, SOAP formatting
2) Can we use binary formating with HTTP protocol and XML/Soap formatting using TCP Protocol in Remoting
3) As Remoting supports XML/SOAP formatting which is universally accepted for any technology
and platform so it should provide interoperatibility between Server/client applications of
any technology/platform and if provide then what is use of web service.
As per my knowledge main advantage of Webservice over remoting is interoperatibility.
4) If I use Remoting with SOAP and HTTP, is it get bypassed by internet firewalls same way
as for web service or, still get restricted by firewalls.
5) Is any performance variation still exist if use remoting with SOAP formatting over
HTTP and webservice with SOAP formatting over Http.
6) Whether webservice support binary formatting and TCP Protocol as per my understanding
webservice only supports http prtocol but as per some programmers opinion in stack overflow
webservice is independent of transport protocol, so Is it like asp.net webservice only works on
http and web service developed in other technologies supports both TCP and HTTP.
Regards,
Arun Patil
If you use Remoting in HTTP mode, you WILL get past the firewalls.
While these two might seem they are doing the same thing, they are two different beasts. As an example, you can use interface types in Remoting, e.g. a service returning an interface, while this is not possible using ASMX Webservices (older stack) or WCF (only partially supported by KnownTypes), but on the other hand WCF supports multiple endpoints/bindings and better security and extensibility model than Remoting.
My advice would be if you are on a project already using Remoting, stick with it, otherwise it would not be a very wise choice to go with a technology that is, if not obsolete, won't get any new features so I'd suggest WCF for a green field project.
We currently just utilize soap webservices for all our communication but have been thinking about moving to WCF instead. What are the benefits of using it over an asmx service?
If we do go with a WCF service, can other languages still communicate with it? SOAP is standardized and all languages can interact with it.
Are there any really good examples of how to get started with WCF that show the benefits of it over soap?
EDIT
I just found this question which is quite helpful.
The Getting Started Tutorial is great.
There's a bit of a learning curve with WCF, but once you learn it it's no harder to implement than an asmx web services. One advantage is you can easily switch protocols and serialization from binary remoting all the way to web protocols. It's also easy to host either in IIS or out.
Other languages can communicate with the web protocols. Binary, not so much...
I just dug into the Getting Started Tutorial. It does a good job of showing the relative ease-of-use. From there, take a look at Hosting and more detailed Features.
WCF is not a replacement for SOAP, and indeed, SOAP can be used as the serialization format between endpoints for communication. SOAP the standard also doesn't really define what goes in the message body, so in the case of WCF-to-WCF communication, a SOAP envelope is used, but the content is binary, so there's your primary advantage, at least in terms of performance. Another advantage is that the programming model of WCF is, or at least is intended to be, much more straightforward; especially since it sounds like you're really just using Web Services to communicate internally. In this case, most of the work would be up front, configuring endpoints (though consuming asmx WSDLs is obviously very easy in .NET).
I'm no expert in WCF, but what I do know has been from .NET user group presentations by Juval Lowy (who wrote the O'Reilly WCF book), his site has a decent amount of information in the way of screencasts and samples in the Resources section, in addition to the Microsoft sites (have you checked Channel9?).
Based on this MSDN article that is linked in the question, WCF supports more than just SOAP. It has support for:
BasicHttpBinding
Interoperability with Web services and clients supporting the WS-BasicProfile 1.1 and Basic Security Profile 1.0.
WSHttpBinding
Interoperability with Web services and clients that support the WS-* protocols over HTTP.
WSDualHttpBinding
Duplex HTTP communication, by which the receiver of an initial message does not reply directly to the initial sender, but may transmit any number of responses over a period of time by using HTTP in conformity with WS-* protocols.
WSFederationBinding
HTTP communication, in which access to the resources of a service can be controlled based on credentials issued by an explicitly-identified credential provider.
NetTcpBinding
Secure, reliable, high-performance communication between WCF software entities across a network.
NetNamedPipeBinding
Secure, reliable, high-performance communication between WCF software entities on the same machine.
NetMsmqBinding
Communication between WCF software entities by using MSMQ.
MsmqIntegrationBinding
Communication between a WCF software entity and another software entity by using MSMQ.
NetPeerTcpBinding
Communication between WCF software entities by using Windows Peer-to-Peer Networking.