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).
Related
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 need some direction related to this topic; maybe I am missing the obvious.
I dont see a contrast between WCF bound to HTTP and strongly typed web service. Why would this be any different?? I agree there are some development nuances especially related to XmlSerializer in ASMX vs WCF and a plethora of Microsoft jargons. Short of these; i only see parallels
DataContract=WSDL Type
ServiceContract=WSDL (aka service definition)
OperationContract=WebMethod
Operationally, I understand the binding can be numerous with WCF instead of getting locked down to HTTP, which can involve heavy construct and tear down. But for loose coupling it will all be web services.
Are there other operational differences??
Can someone show me the light and put me out of my misery?? :))
Well, if you reduce your discussion to only HTTP, then there's still a slew of advantages that WCF has over ASMX:
more and better security settings (ability to use either transport or message security)
much more flexibility - a lot more can be configured and tweaked in WCF, either in configuration files or code
ASMX web services can only exist inside IIS - IIS is a must-have requirement; you can self-host your WCF services in a console app or Windows NT Service
the clear focus on using Service and Data Contracts in WCF makes for a much cleaner interface and a much better separation of concern (better code, in the end)
support for things like reliable messaging and transaction support (even over HTTP)
In short: even though the differences might be smaller when you restrain WCF to just HTTP, I still think it's superior and if you have the choice to start something new today, by all means, use WCF instead of ASMX!
Rick Strahl puts it very nicely in his blog post:
I would argue that using WCF for any new services is probably a good idea even if you stick with pure HTTP and SOAP because by creating your service with WCF you can decide later on to publish this same service using WAS and also provide the more high performance TCP/IP transport. Or you might be asked to provide some of the advanced features of WS- protocols like transactions, attachments, session management, encryption etc. By using WCF you are building your service with a view to the future so you can easily move up to other protocols-some of which may not even exist today. Certainly new technologies will come along in the future and WCF protects you somewhat through its abstraction layer and common API.*
Marc
Another point for the consumers of the ASMX web service, which ever platforms will consume the web service will have to implement a SOAP stack. If you're goal is for wide reaching consumption, WCF is preferable and will allow you to expose the WS in more universal ways.
The other big distinction between the two technologies is that Microsoft now considers both ASMX web services and XML Serializer to be "legacy technology", and is no longer fixing bugs in them.
I'm writing a server app with a silverlight client. At some point I'd like non-silverlight clients to be able to use my services. Right now I've written some WCF services which get polled, but I'm not happy with the responsiveness. I'm thinking of switching the code over to using Silverlight/WCF duplex polling, but if I do that, will I be stuck with Silverlight as my only client? Is it better to write my own long-polling service using normal WCF http services?
I don't see your issue there. You can just define another binding for use by other clients (like WsHttpDualBinding). The same server code will perform the exact same task regardless of the underlying binding. That's the whole point of using WCF.
You can find a AJAX sample here for using a WCF duplex service http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html
By other .NET client - yes. By anything else : no. WsHttpDual is definitely NOT an interoperable protocol. It also has plenty of other drawbacks and pitfalls and I'd try to stay away from it as much as possible......
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
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