What is the difference between WCF and WSE2.0 webservices when it comes to implementation of basic httpbinding. Can anyone point out what may be the subtle differnces when it come sto use the same protocol but using different technology.
Not sure if this is what you're looking for but I've only run into a difference once. I generated wcf proxies against a very old asmx webservice and ran into serialization errors on certain operations. When I regenerated the code using a "legacy" web reference everything worked fine.
A very good article describing this is here.
Also the various wcf bindings are explained here
hope this helps.
Related
I have a third-party Java web service listening at three SOAP 1.1 WSDL endpoints. One of the endpoints is used to initiate the session and perform some high-level tasks, and the other endpoints are for subject-specific tasks reusing that initial authentication.
I'm building a C# WCF application to talk to the service, and I'd like to share the session cookie among the three client objects.
What's the VS2010 'best practices' way of sharing this cookie?
If this article is still the best answer, I can go with it, but I would appreciate some additional feedback, especially if .NET 4 introduced a simplification that I'm not finding on-line.
http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
I can pretty easily create the first client and retain the session (new BasicHttpBinding myBinding; myBinding.AllowCookies = true), but I couldn't find an elegant way of saving off the cookie from the Connect response and reusing for the two auxiliary clients.
Any insights are appreciated.
I should note that I'm aware of CookieContainer and using Add Web Reference instead of Add Service Reference. That method is labeled as 'legacy' in most posts I've read, and I'd prefer to stay current...or as current as possible when working with SOAP 1.1.
The mentioned article is still valid. You have to use OperationContextScope and access message properties to get protocol specific data. This complexity is based on the fact that WCF architecture is protocol independent whereas ASMX architecture was HTTP protocol dependent.
It is true that ASMX (WebReference) is legacy technology but it is still present in .NET framework so if you know that you will never need nothing more the basic SOAP messaging without any advanced WS-* standard you can still use it and make your life little bit simple. Once you need anything more you can still refactor your code and use WCF with mentioned code to work with cookies.
at my workplace we are about to start a big project. My boss (a programmer, this is a startup) wishes to use ASMX webservices for this purpose. I do not want to start off a new program using deprecated technology and would like to show him this. I dislike WCF at this moment because it has such an extreme learning curve, but I'd rather learn it than use an unsupported technology.
The problem I'm having is that I can not find any practical list of cons and downfalls when compared to WCF so that I can convince my boss to not use them. And saying "it's not as powerful" is not an adequate explanation. What exactly can it not do that we may need it to do for a webservice that is not meant to be shared externally? (as in, we don't support third-parties using our webservices unless they are using one of our clients. )
In short:
ASMX is
limited to only HTTP as its transport
limited to only being hosted in IIS (no other alternative)
limited to very simple security
limited to SOAP 1.1
WCF is
more flexible in transports: you can use HTTP, NetTCP, MSMQ, many more
can be hosted in IIS, WAS, or self-hosted in a Windows Service, in a console app, in a Winforms or WPF app
has much more security options
supports a plethora of WS-* standards
can interoperate with SOAP 1.1 and SOAP 1.2
In short: WCF is ASMX done right - much more flexible, much more powerful, much more in every respect.
Here's another quite useful comparison of WCF and ASMX: Comparing ASMX and WCF
and last but not least, WCF is also better in terms of performance, as this quite extensive MSDN article quite nicely shows (including performance numbers and graphs): A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
I've never understood why some people think that WCF is difficult to learn. Try this: create a new WCF Service Project in Visual Studio. Now look at the code. Compare that with the same code you get from creating a new ASMX project. It's not very different.
I have three words for you: WCF. WCF. WCF.
Here are another three about why you should choose WCF: Power. Versatility. Configurability.
ASMX is great if you want to get a quick and dirty web service up and running, although to be honest it only takes maybe a few minutes more to do a WCF one.
The WS-* are really hard to implement with asmx: transactions, reliable messaging, security... etc etc.
And later the bindings: you can change the communication just by configuration, the asmx is just http.
WF exposing services and AppFabric works over wcf.
I would not have doubts, today wcf is the best option for starting a project that needs services.
I have two related questions about Web services:
(1) I'm currently writing a set of applications, and it occurred to me that maybe I'm not using the right tool for the job. Here is the spec:
There are many Windows servers behind different VPNs and firewalls.
Each of the servers has a Windows service running, that reports various information about it to a centralized server, via a Web service, both of which I've written, and have access to.
So I'm both the producer and the consumer, and I'm staying on the same platform (.NET). Maybe a web service isn't the way to go? I'm using one purely because it's easy to write and deploy, and I'm the most comfortable with them. Should I really be using WCF for this?
(2) In the web service, I'm creating a State object to represent the state of the server, and sending it as a parameter. However, adding a service reference creates a proxy of the State class. It seems gacky to copy the properties of the State object to the proxy, and then send the proxy. Should I just replace the proxy class with the real class in the auto-generated code (i.e., include a reference to the State class instead)?
By "web services" I assume you mean an ASMX? I would go with WCF is possible, simply because you lose nothing but gain lots of flexibility. You could, for example, switch from XML-over-HTTP to Binary-over-TCP through a simple config change.
I would suggest to use WCF and use the Net.Tcp binding. It should be efficient enough for 300 clients. For the proxy class issue use the /reference option for the svcutil tool when you generate the proxy. This will allow you to share classes between server and client. I would not use this option if interoperability was a concern but since you stated that you develop both the clietn and the service and all in .Net it is a valid use in your case.
Your distinction between "Web Services" and WCF is a false distinction.
ASMX Web Services is the original .NET SOAP Web Service technology, introduced in .NET 1.0. It has been replaced by WCF, which can everything that ASMX can do, plus a whole lot more (including support for the WS-* standards).
Microsoft now considers ASMX Web Services, and the XML Serializer they're based on, to be "legacy technology". See "Microsoft says: ASMX Web Services are a “Legacy Technology”".
With WCF, since you have control of both sides of the operation, and can share the .dll in which the service contract is defined, you can and perhaps should be using ChannelFactory<IYourServiceContractHere> instead of auto-generating those ugly proxy classes with service references.
Here's the first hit I found on this topic: http://blogs.msdn.com/juveriak/archive/2008/02/03/using-channels-vs-proxies-in-wcf.aspx
If it is platform independent, I would certainly recommend WCF.
I've done exactly what your describing to great effect across more than 300 locations. I don't think you made the wrong call.
Another thing you could consider that would work well is using MSMQ. In this case, however, you'll either need to write event triggers (COM) or an event queue processing service.
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
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