Why we are going for WCF when web services (ASMX) exist ??
Here is a nice article that you can look at
Comparing ASP.NET Web Services to WCF Based on Development
WCF supports protocols beyond HTTP (TCP and MSMQ come to mind) and message formats beyond XML, so it could be used for tasks they are unsuitable e.g. because these tasks require better performance.
WCF could be self-hosted so no need for hosting in IIS.
WCF supports preserving service object state between calls.
Another rather interesting and thoughtful comparison:
http://www.keithelder.net/blog/archive/2008/10/17/WCF-vs-ASMX-WebServices.aspx
Download the PowerPoint and have a look at it - also, watch Keith's DotNetRocks TV appearance for a great screencast intro to WCF and its advantages over ASMX.
Marc
Web services require use of HTTP protocol on standard HTTP ports, right? WCF is more flexible. It can be based on HTTP, TCP, UDP and such. It allows you to design an application with network connectivity without caring so much about the protocol used. Then you can more easily switch the network protocol without affecting the application.
Related
I wonder what is the different between Web Services and WCF? Aren´t they the same thing?
Thanks in advance!
I heared about two types of web services.
XML Web Services
WCF Web Services
What is the real difference?
Web services can be built with any number of technologies, while Windows Communication Foundation is specific to .NET. WCF is not specific to communicating via HTTP. It can also work directly over HTTP.
Check out the linked Wikipedia page for more about it.
No, they are not the same thing. While you can certainly replicate the behavior of ASP.net web services in WCF, WCF is a far more fully featured (and complex) platform for developing SOA. It enables to you to take much more control of the messages exchanged between your client and servers, and offers you many more options in regards of protocols and bindings for your endpoints.
Take a look at this article for an overview on some of the differences.
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 learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here
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 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