On Thursday, December 8, 2006 I delivered an internal webcast on the Windows Communication Foundation (WCF) as part of the SRA .Net University series. I had 33 people register and 18 attend. Participants attended from Virginia, Maryland, New York, Geogia, North Carolina, and Washington DC. WCF is Microsoft’s unified programming model for building service oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across all platforms and interoperate with existing investments. WCF is a unified API for disparate communications technologies.
I began the presentation with a brief discussion of service oriented architecture (SOA) in general and some of its characteristics. Here are some key bullet points about SOA:
* It is a design methodology.
* It leverages existing investments - i.e. it is evolution, not revolution.
* It facilitates and encourages re-use.
* It implies interoperability because it is based on standards.
* It does
not mean web services.
Web services are a concrete implementation of an SOA, whereas SOA is a design or architectural pattern. Web services are only one way to realize a service oriented architecture.
WCF uses the concept of endpoints to send messages from a client to a server. An endpoint is the fusion of the address, contract, and binding. Every endpoint must have all three, and the service exposes the endpoint. Logically, the endpoint is analagous to an interface in the software development world.
An address provides 2 elements. The location of the service and the transport protocol. Location is the computer name, url , port, pipe, or queue. WCF supports the following transport protocols. HTTP, TCP, peer to peer, IPC over named pipes, and MSMQ.
There are many possible communication patterns - Request/Response, fire and forget, bidirectional, delivered immediately or queued etc. In short, their are a lot of aspects of communication involving dozens of parameters and configurations. A binding is a consistent set of choices regarding the transport protocol, message encoding, communication pattern, reliablity, security, transaction propogation, and interoperability. Binding allows us to extract the service code and use different "plumbing" if we want. We can use the WCF provided bindings, or write our own custom bindings.
In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does.
There are many ways we currently can write distributed applications. We can use Enterprise services and COM+. It features attribute based programming and supports transactions.Some services are configurable some are not. In COM+ applications, system administrator can turn on or off transaction support from an MMC console. This isn't a good thing. Microsoft will continue to support Enterprise Services, but there won't be any additional investments in the future.
Web Service Enhancements (WSE) are a stepping stone toward WCF. WS* protocols are also the last versions to be supported by Microsoft.
.Net remoting has many good features, notably performance, but it is difficult to implement. Currently .Net remoting passes references to the other side (client or server) and we can subscribe to events. Problems occur because it is a local programming model which is tightly coupled. Versions of dlls need to be the same. Service orientation is about separating pieces of our application that can be decoupled and be independently versioned. Using WCF , we only share the contract. Reference passing and direct access to properties is not allowed in WCF.
WCF also takes existing .Net web services and allows us to add additional attributes. It is a relatively easy upgrade path.
WCF is a broad and deep subject, but it is crucial to Microsoft's application strategy. I encourage you to learn more about it. A great resource to learn about WCF is
this URL. The slides and code for this session and the rest of the .Net-U series can be downloaded
here.
In summary WCF is a unified approach to writing distributed applications. Because we use attribute base programming, configuration files, and service contracts, it is possible to switch technologies without having to rewrite applications. Because we only expose the "contract", if we change parameters or extend an operation's functionality, we don't run the risk of breaking existing applications.