Services are becoming more and more important. Put services close to the people who will use them. Web 2.0, too, as companies most valuable asset is their data and getting that into the hands of people who can use it. So what do you do as a .NET developer to get your hands on services?
Version 1 depended on SOAP to make RPC calls across the network. Not ideal as contents got bloated.
The next option was .NET remoting. If you had both ends of the wire it was fast and optimized. To expose as web service to the outside world was a pain.
WCF is the strengths of both of the above.
Why do we need another framework? ASMX and .NET Remoting work, kinda, right?
Well, sorta. Devs were changing code for configuration issues. Being able to configure services allow the server guys to manage the issues.
WCF, then, allows you to declare services, interfaces, and contracts to manage configuration and give the services some protection against mis-configured services.
WCF is also extensible. If you don't like some piece of the services stack you can change it and write what you need to do.
What are the hosting options for services? You can use IIS6/7 or write your own Windows service or Windows app.
WCF provides a lot of functionality out of the box, including logging, tracing, security, and a config editor and test client. The config file can be difficult to deal with, so this editor is available.
WCF is all about endpoints, which are basically addresses of where your services live. You also need a binding which can be confusing as there is a lot to choose from. wsHttp, netTcp for very fast .NET to .NET, msmq for async, netNamedPipes for .NET to .NET on the same machine, webHttp for RESTful services.
Then you need a contract that tells what you will provide as a service. WCF allows as many endpoints as you want or need. The contracts tell the world this is what my service is and how it's going to work. The service contract lets the world know what the service does. Data contract defines data types to be sent. The message contract defines the message schema used to communicate. The fault contract. In ASMX world you had to wait for a timeout before receiving an exception. WCF returns rich information, and exceptions thrown over the wire cause a fault.
So SOAP is SOAP, but the messages continue to grow as more information is added to the message. Even worse is having to debug these messages on the weekend when no one is around ;) SOAP will not go away, but there is an alternative. The alternative is REST.
REpresentational State Transfer identifies resources on the web. It's part of .NET 3.5 where WCF supports SOAP more easily. The "Where" looks like this:
- http://stuff.org/articles/WCF - stuff on WCF
- http://weatherdude.com/local/sevenday/43081 - specific forecast for a zipcode
- http://finance.portal.com/fin/search?q=MSFT - stock information for Microsoft
What's a URI? It's a URL and a verb - at least in the ivory tower circles. To the rest of us, a URL and URI could be interchangable.
The "What" is GET to get something, POST to create something new, PUT to update what's there, and DELETE to get rid of what's there.
REST gets away from SOAP and replaces it with POX, Plain Ol' XML or JSON, Javascript Object Notation. Fiddler is a great tool for making REST transparent during development. If you're doing any Silverlight you'll be working with JSON at some point.
Advanced topics around WCF Customization involve bindings and channels that interact with the outside world. Behaviors can be customized to respond with parameters, say, that meet SLAs. Many certificate security options provided out of the box. Security is either transport-based SSL or message-based where the message is encrypted.
James recommended some books
- Programming WCF Service, Juval Lowy
- Essential Windows Communication Foundation for .NET Framework