I am in the process of writing a new course for ObjectSharp on WCF. More details about the course can be found here: http://www.objectsharp.com/training/CourseDetail.aspx?id=1135. For even more information, contact our Training Manager, Julie James, at 416-216-4603 (or 1-877-So-Sharp) ext. 1 or via email at Training@objectsharp.com.
WCF is a very well-designed bit of technology. The separation WCF makes between the "service" itself and the plumbing required to interact with the service is very profound and allows one to have a great deal of control over a service once it is operational simply by changing configuration options. I can't say enough about how well WCF makes the separation between a service's design-time characteristics and its operational characteristics.
On the other hand, one of the other dominant design features of WCF, namely its unified programming model for all forms of "Connected Systems" development, has a way of making me nervous. Consider that there is a world of difference between:
- Middleware components that might have a fairly fine-grained interface and across which you might span the odd transaction, and
- Autonomous, enterprise-grade, course-grained services with document-oriented message schemas across which you wouldn't dream of spanning a transaction (because it wouldn't be autonomous anymore then would it?).
Yet WCF supports the development of both kinds of services, all within a single programming model! This is both very powerful and at the same time potentially dangerous. Why dangerous? Well, for many people, when given a means to define their services in their tried-and-true object-oriented paradigm the result is often not suitable for the second category of services; i.e. the course-grained, autonomous services. As such, a very important aspect of the course for me will be to highlight how to design your WCF service and data contracts to support either paradigm.
Also, for better or for worse, XML Schema is the mechanism of choice for defining the structure of the messages that flow in and out of web services. Yet WCF wants you to stay away from XML and work with its data contracts instead. However, a lot of people have spent a lot effort thinking about how to design extensible XML schemas so that your Services can evolve without impacting its current consumers (a crucial aspect of what is more generally called loose coupling). So another important theme for my course will be on how to translate some of that knowledge into WCF's data contract space and still end up with extensible, interoperable message formats.
The course is being worked on now so it is still evolving. Let me know if you think there is anything else it should include.