The first session that I attended was an Intro to WCF by James Bender. James did a wonderful job giving the basis of WCF. I know it was a wonderful job because I didn't know why I would want to use WCF on my next project and now I do.
James started his presentation with reason to use WCF:
- Consider "The Mesh". Data and services live in the cloud. Functionality and data availability is important. How you get to it is not?
- Consider Web 2.0. We have an investment in data. Exposing the data is the new challenge. LinkedIn, Plaxo, Amazon.com, Facebook, etc.
These two reasons are industry trends. They identify the direction that services are moving. When thinking SOA, you have to consider where and how your services will be used and then add the uknown element of the future. WCF can apparently allow you to allow for flexibility in this area.
In the beginning, we had web services. Web services started out as a way to transmit data in an open standard manner. This brought along an interoperable way to interact with just about any technology. The handshake was openly defined and System A could talk to System B without a binary relationship or any knowledge of system implementation. Some problems existed though. It wasn't great for business-y types of transmissions because it was stateless, bulky, potentially insecure, etc.
Enter the advent of WS* technologies. This meant that developers became plumbers. Really a step backward. Developers should not have to plumb in the inner workings of moving data.
Enter .Net Remoting. The responsibility to write plumbing code was gone but so was the interoperability with non-.net applications.
Enter WCF. Let the light shine through the clouds.
- Supports ASMX
- Supports Attribute based programming
- Supports WS* Protocol
- Supports .Net Remoting
- Supports Message Oriented Programming
Some of the great attributes of WCF are that it is configurable. Before WCF, your steps were: restructure, compile, repeat. With WCF, you change a config file. Next, WCF allows you to setup multiple Endpoints. Some examples of endpoints are MSMQ, HTTP, Named Pipes <insert your protocol here>. This are just the protocols that you are exposing for connections to your server.
You do have to choose how to host the endpoints that you create. You can use IIS to host your services. Using IIS gives you the management control that's already baked into IIS and a platform that is reliable. Additionally, you can host it yourself within a windows service or a command/windows application.
What's available to you with WCF out of the box:
- Security
- Logging
- Tracing
- Configuration Editor
- Test Client
The ABC's of a WCF Endpoint:
- You have to identify your Address
- You have to identify your Binding
- You have to identify your Contract
There are four types of Contracts (For lack of a better term, the contract is part of the meta data for the service)
- Service Contract
- Defines the operations your services exposes as the rules that service must operate by
- Data Contract
- Defines how data types will be sent from service to client
- Used to identify data structures
- Message Contract
- Allows for definition of message schema that services use to communicate
- Fault Contract
- Specialized data contract that can communicate fault information from the server to the client
These four types of contracts are not mutually exclusive. They can all be applied to a single service.
If what you need isn't available OOB from WCF, extend it. There two points of extension: Channel and Behavior.
The channel is made up of three types of objects
- Transport
- Channel
- Channel Listener: Watches step in chain before this channel and waits until there is a message
- Channel Factory: Notifies next channel in chain to notify that a message is available
- Binding
Channels have shapes
- Datagram
- IInputChannel
- IOutputChannel
- Request/Reply
- IRequestChannel
- IReplyChannel
- Duplex
Some reasons that you may need/want to create a custom Channel:
- If you want to do some custom encoding
- If you want to implement a custom protocol
- If you want to catch communication-specific handlers
Each channel has a Behavior and a Dispatcher. In each point in the process, you can add a custom behavior. (IServiceBehavior, IOperationBehavior, and IEndpointBehavior)
Some reasons that you may need/want to create a custom behavior:
- If you want to perform any preprocessing your message
- If you want to route messages specifically
- If you want to examine and/or reformat messages
- If you want to inspect/validate operation parameters
Security: Perceived as difficult but WCF Makes this a lot easier. Out of the box, some items are implicit. ie. https has certain mechanisms for security pre-baked in.
- Transport based security
- SSL
- Only lasts between two points...not entire duration
- Message based security
- Message can be intercepted but not interpreted.
- Messages can be heavy