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.
Related
I am trying to understand programming with sockets on a more detailed level rather than just with the API callings. I have fair understanding of C# WCF and socket programming using WinSocks in C++. Now I have 2 main questions:
Does WCF use sockets internally for the communication in all cases. In other words is WCF a wrapper around sockets and is built upon them?
Does all kind of network based communication use sockets at the end for sending/receiving data, which is something mandated by the OSI model?
A little detailed explanation will be better than just a Yes/No answer.
(With acknowledgement to the other SO users who agreed to reopen this question).
As an opening remark, remember that it's 2019 2020 and WCF is obsolete and I'm personally glad to see it gone, and I strongly recommend against using WCF for any new projects and I advise people to transition away from WCF as soon as possible.
Now, in response to your question (bold emphasis mine):
Does WCF use sockets internally for the communication in all cases. In other words is WCF a wrapper around sockets and is built upon them?
Strictly speaking, no (but in a practical sense, for inter-machine transport, yes).
WCF is a .NET platform that is concerned with "message processing". WCF tries to abstract away the underlying details of message transport (but it does so horribly, and so no-one should use it today), so it is entirely possible to build a WCF application that achieves inter-machine and inter-network communication without ever using Windows' Winsock, or whatever "Socket"-esque API is available for a given computing platform.
Now, while ostensibly WCF is all about abstraction, in practice WCF was geared around SOAP messages (and SOAP is horrible too, but that's another discussion), and SOAP primarily uses HTTP as a message transport - and HTTP primarily uses TCP/IP, and almost every single TCP/IP application on Microsoft Windows will be using the Winsock API somewhere in the process' communication stack. (It can be argued that HTTP applications on Windows will use http.sys which performs HTTP request/response processing in kernel-mode, which necessarily means bypassing Windows' user-mode Winsock API and instead http.sys uses "Winsock Kernel" which is its own thing).
In the above paragraph, note the use of the word "primarily" (as opposed to "exclusively" or "always") - because:
WCF doesn't have to use SOAP, it can use other messaging models/protocols/paradigms like net.tcp (which itself is more like a "binary SOAP") or even REST (though REST support came late in WCF's lifespan and it's a total pain to configure correctly, YMMV).
SOAP doesn't have to use HTTP, it can use other transports like SMTP. And WCF expressly supports other SOAP's other main transports like SMTP and FTP.
While HTTP is effectively tied to TCP/IP and Winsock is the only real way a user-mode application will use TCP/IP, other transports like SMTP don't have to use TCP/IP (at least, not in the way you think - see my footnote).
And of course, throughout all of this - user-mode applications are always free to use a different Networking Programming Interface besides Winsock or BSD sockets (for example, Windows' named-pipes present a streaming IPC interface just like how TCP behaves - or the vendor of a network-interface-card could have its own exclusively networking API which is somehow simply better than the Sockets API (similar to how GPU vendors in the mid-1990s were pushing their own APIs (Glide, PowerVR, Rendition, etc) until they all ended-up having to support Direct3D and OpenGL (and who uses Metal? hah).
And while WCF isn't exactly designed with testability in mind, it is still possible to host and run WCF applications inside an integration-testing environment where the actual message transport is just a thin proxy object, or a faked or mocked implementation - so Sockets are completely avoided there as well.
But in practice - in Win32, networking is accomplished using Winsock (Microsoft's implementation of the BSD Sockets API) so if you're using WCF to communicate between machines then I can say with 99% certainty that eventually your messages will pass-through Winsock.
Footnote: Regarding using WCF with SMTP without using Sockets: Many SMTP e-mail servers, including Microsoft Exchange Server, support "pickup directories" - which are filesystem directories actively monitored by the e-mail server, which detects when a new file has been added to the folder and reads each file as an SMTP envelope and processes it the same way as though it was an SMTP envelope received by the server's SMTP service endpoint - if a SOAP-in-SMTP message were to be "dropped" inside the pickup directory and it was destined for a recipient local to the pickup directory's e-mail service, then that message will not pass through Winsock at all either.
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.
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 need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.
The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.
Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.
You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.
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.