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
Related
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 .
I use the term network services to refer to things such as NNTP, IMAP, POP3... things which have a defined protocol layered on top of TCP/IP.
I'm having a very difficult time figuring out how I can connect to an existing network service using a WCF client. I haven't found any examples other than ones that are basically using C#-ified socket code.
Can anyone refer me to any examples of using WCF to talk to a legacy service as something other than a glorified socket?
Is WCF even appropriate for this type of requirement?
Thanks.
WCF comes with a set of standard bindings, here is a list of the bindings provided in 3.5:
http://msdn.microsoft.com/en-us/library/ms730879.aspx
If you need to use anything else, WCF is probably not the way to go. Even if you could build your own binding, the cost would outweigh the benefit.
If you have a requirement in your project that everything should use WCF, you could build a WCF facade over your sockets code.
Well, the term "WCF" actually means 2 things:
The framework: "ABC" - Address, binding, contract
Actual use of a combination of the above (for example, a WCF webservice using BasicHttpBinding)
There's not built in bindings for the protocols you mentioned, which is why the examples you'll see looks like "glorified sockets" - That's what they are. That's what a binding is: A level of abstraction built on a basic protocol (typically UDP/IP or TCP/IP).
Now, with all this being said, you need to build / borrow / steal / whatever a binding that is usable with your protocol of choice. This might look like you're just injecting sockets into the WCF framework, and honestly, that's just what it is :)... So what's so great about it?
If you managed to implement your binding to-the-specs, you got yourself a very easily substituted component, which will fit into all WCF applications. Whether you want this behaviour or not, is up to you and your requirements :)
Good luck with it.
Well, WCF at its heart is the unified communication engine offering by Microsoft, based on SOAP - it replaces ASMX web services, WSE, .NET Remoting and more.
As such, it's SOAP based and therefore can talk to anything that talks SOAP - which I doubt is the case for POP3 or other services. So I don't think you can write a WCF client for these services, really.
As for writing these services from scratch and exposing them as WCF services - that might work, since basically the WCF service implementation can do anything, and then present itself to the outside world as a SOAP service - could work, question is: what's the benefit?
Marc
I am confused... How can MS release two versions of Silverlight without having proper support for WCF bindings? Should they not support wsHTTP binding at least? So the service can have proper Message-level security? (i.e. certificates etc...)
With a basicHTTP binding, looks like the only two options to secure the service are...
HTTPS (but that does not cover authentication)
Custom-implemented WS-Security on top of basicHTTP binding
Am I missing something?
Silverlight is a UI technology and it is normal for a Silverlight page to talk back to a single server that contains all the middle tier logic. Therefore I consider it reasonable that WCF is limited to basicHTTP binding over HTTPS. As I understand it, the more complex WCF bindings were designed to be used between servers in data centres.
Normally I would expect both the backend and the front-end of a Silverlight page to be designed and coded together. I would expect 3rd party systems to be access by the middle tier logic rather then the Silverlight page directly. Afterall Silverlight did start out as a “better HTML then HTML”.
These days Silverlight applications are starting to look more like thick client applications, so the limitations on WCF binding may no longer be as reasonable as they use to be.
Ok so a Microsoft boffin has answered this here. looks like a 'talk to the hand' to me
http://silverlight.net/forums/p/20844/78325.aspx#78325
For Silverlight V2.0 final release, the answer is no. We only support BasicHttpBinding and PollingDuplexHttpBinding.
(please "mark as answer" if this post answered your question. Thank you!)
Jeff Cao
I think BasicHttpBinding is the only binding that's yet been enabled for Partial Trust (APTCA).
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