In WCF there are several different types of HTTP based bindings:
BasicHttpBinding
WsHttpBinding
WebHttpBinding
What are the differences among these 3?
In particular what are the differences in terms of features / performance and compatability?
You're comparing apples to oranges here:
webHttpBinding is the REST-style binding, where you basically just hit a URL and get back a truckload of XML or JSON from the web service
basicHttpBinding and wsHttpBinding are two SOAP-based bindings which is quite different from REST. SOAP has the advantage of having WSDL and XSD to describe the service, its methods, and the data being passed around in great detail (REST doesn't have anything like that - yet). On the other hand, you can't just browse to a wsHttpBinding endpoint with your browser and look at XML - you have to use a SOAP client, e.g. the WcfTestClient or your own app.
So your first decision must be: REST vs. SOAP (or you can expose both types of endpoints from your service - that's possible, too).
Then, between basicHttpBinding and wsHttpBinding, there differences are as follows:
basicHttpBinding is the very basic binding - SOAP 1.1, not much in terms of security, not much else in terms of features - but compatible to just about any SOAP client out there --> great for interoperability, weak on features and security
wsHttpBinding is the full-blown binding, which supports a ton of WS-* features and standards - it has lots more security features, you can use sessionful connections, you can use reliable messaging, you can use transactional control - just a lot more stuff, but wsHttpBinding is also a lot *heavier" and adds a lot of overhead to your messages as they travel across the network
For an in-depth comparison (including a table and code examples) between the two check out this codeproject article: Differences between BasicHttpBinding and WsHttpBinding
If your are getting missing service namespace reference when copying your files to the web server, try the following. We found that publishing the project and copying out the App_WebReference.dll file in to the bin folder will fix that. Using the bindings that are generated from adding the service into your project found in the web.config can then be copied to your servers web.config .
Related
What benefits does WCF bring to the table and why should I use this new technology over good old ASP.Net web services?
Maybe you don't need to transition to WCF if regular Web-Service will work for you,
however WCF encompasses more than just Web-Services.
With WCF you can utilize different communication channels (such as Web-Services, MSMQ, named pipes...) utilizing the same end-point service handler code.
WCF also has different built-in security mechanisms, allows you to utilize different serialization mechanisms (if something other than Soap is needed like raw JSON), hosting of services without the requirement of needing a web project etc...
As such WCF is more a general service hosting framework that can replace regular ASMX web services
Here is a good article from msdn that talks about the differences between ASMX and WCF
A few key areas
Serialization - Asmx uses XmlSerializer while WCF uses the DataContractSerializer. The Datacontract serializer is about 10% faster (source along with other information)
Differences Between ASMX and WCF Services
Greater protocol support (HTTP, TCP, ICP, MSMQ for WCF), ASMX only supports HTTP
Is there a way to retrieve wcf binding type and security mode just from a wsdl?
i.e. I want to know what bindings are supported by a wcf service by reading it's wsdl, is it possible?
Thanks
No - the WSDL only defines what operations are available on your service - plus it is totally unaware of and independent of WCF.
The only thing that might be included in WSDL (depending on where it came from) are certain bits of information about security needed, e.g. whether to connect using http vs. https, or other tidbits.
Marc
Exact duplicate:
Why does Silverlight 2 only support WCF basicHTTP binding?
Why only basicHttpBinding with silverlight and wcf? Perhaps you have a link that covers this, you don't have to do a bunch of typing :+>
A couple of answers: (1) Silverlight 4 now makes the Net.TCP binding available, which is darned handy when it's not blocked, since it's dramatically faster (see here for details). So clearly there's nothing inherent in the Silverlight architecture which prevents it from using other bindings.
(2) As for why Silverlight doesn't make use of the other WS* Http-based bindings, it's just a guess, but I wouldn't be surprised if those bindings made use of the HTTP protocol in ways that Silverlight's limited HTTP stack won't support, probably for security reasons. For instance, I know that Silverlight limits the content headers that you can place on an HTTP request, and if any of the WS-* protocols require custom headers, or headers that might represent a security risk, MS would want to prevent that.
(3) Of course, it's also possible that MS just hasn't gotten around to it yet. They've done a lot with Silverlight in the last couple years -- but presumably they have to prioritize their features.
Hm, I am pretty sure this is duplicate, but can't find it. I think the short answer is that BasicHttpBinding is the only binding that works in Partial Trust.
(EDIT: found the dup, linked in question now)
I found several links for this but no definitive answer. Smells like Silverlight was designed against ASMX web services for Web service style communication and the way to get WCF to play with older clients expecting an ASMX web service is to use the basicHttp binding.
This link gives you a fully worked example (using Beta2 of Silverlight).
http://msdn.microsoft.com/en-us/magazine/cc794260.aspx
A standard WCF service can be invoked by a Silverlight app as long as the Silverlight app has a binding of type basicHttpBinding. You must either make sure you change the default binding of the WCF service from wsHttpBinding to basicHttpBinding or create a new binding of type basicHttpBinding
This Reference says the same thing but again offers no explanation.
http://timheuer.com/blog/archive/2008/03/14/calling-web-services-with-silverlight-2.aspx
Silverlight communicates using the BasicHttpBinding for WCF
I'm looking to understand when to use a WCF services instead of just using webclient or httpwebrequest. I guess I'm also looking to understand the difference between the design patterns that would be appropriate for both.
Are you talking about when to create a WCF service yourself (over web service), or when to consume an existing web service using WCF instead of .NET 2.0 ASMX clients?
As for creating a WCF service yourself:
Gives you a lot more options in terms of hosting (in an app, Windows Service, IIS, WAS)
Gives you a lot more security options
Gives you a lot more protocol options (besides just HTTP, you can also use WS-*, TCP, Named Pipes, MSMQ and more)
Allows you to write your service once, and expose it on multiple end-points with different protocols at the same time
As for using WCF to talk to an existing HTTP (ASMX) web service - I don't see a whole lot of massive benefits, except WCF uses more configuration over code, and it can be good to standardize on one way of doing things, if you already use other WCF services, anyway.
Marc
I'm currently using WCF for most of the things that I would use WebClient or HttpWebRequest/HttpWebResponse in the past. While there definitely is overhead for learing how to make calls to web methods using WCF, the extensibility of WCF and the abstraction it provides makes it a MUCH better candidate for these types of calls.
I've already used it to make calls to Akismet and RPX pretty easily.
To get started, I'd look at the section of the MSDN documentation titled "WCF Web Programming Object Model", located at:
http://msdn.microsoft.com/en-us/library/bb412204.aspx
For my project's web services I want to support desktop clients and silverlight clients. Should I write a separate web service for each or put all the operations in one service? If I put them all in one, I have to go with basicHttpBinding. The winforms app uses wsHttpBinding now, what do I lose going with basicHttpBinding?
I very strongly recommend you read this thoroughly:
"Silverlight and WCF Feature Comparison"
http://msdn.microsoft.com/en-us/library/cc896571(VS.95).aspx
There are quite a few gotchas when developing a web service for silverlight usage, especially if you already have a wsHttpBinding solution. Good luck!
EDIT: also I found this article useful:
WCF : BasicHttpBinding compared to WSHttpBinding at SOAP packet level
http://geekswithblogs.net/claeyskurt/archive/2008/04/22/121508.aspx
Use one web service with two endpoints, that would allow you to support basicHttpBinding as well as wsHttpBinding.
The difference between the two bindings is that basic is Soap 1.1 whereas ws is Soap 1.2 and WS-Addressing Specifications, in addition wsHttpBinding offers more security options