The Future of WCF, Part 2
Having read part 1 will be helpful.
As I mentioned last time, there were two markets in particular that I thought were interesting for web service developers to expand into when using WCF.
The first market was REST and the HTTP application style of web development. Since the initial version of WCF I think that we've made a bit of progress in that direction although we still have quite a ways to go.
Before WCF shipped we managed to slip in a feature late in the development cycle to wash some of the SOAP off of messages: the None MessageVersion. This feature replaced a clumsier system that tried to map HTTP headers around and has turned out to be more generally useful since in non-HTTP systems. I've seen a lot of opportunities since then to make use of MessageVersion.None in a variety of contexts.
During Orcas we also made a large investment relative to the size of the release in making WCF friendlier to the web. Examples include special service hosts to reduce configuration, new bindings and message encoders, attributes for working with HTTP methods, URI templates, and so on. I think that this was a great set of improvements in WCF for web application development but we still have no direct accommodations for the REST architectural style. I hope that the REST starter kit proves out to be an initial down payment in that area. It will take some time and work before those features are ready to be incorporated into the main product. Until then, we should be able to experiment and iterate quite quickly because of the lightweight release format.
The other market that I took interest in was enterprise and application integration. Although many people viewed WCF as being enterprise-focused because of the prominence of the WS-* protocols, those type of protocols represent only one kind of enterprise scenario.
Many of the WS-* protocols make an implicit assumption of trust between the two parties to smoothly and cheaply coordinate work. That is not to say that they take no precautions in protocol or coordination to guard access and resources. However, the design of the protocols necessitates a minimum level of coupling to avoid problematic resource and timeliness issues.
For example, a distributed transaction between two parties requires resource allocations for the transaction state, an optimistic assumption by the transaction initiator that things will be resolved quickly, and a pessimistic assumption by the transaction receiver that the work must be performed soon rather than at the receiver's convenience. When operating in concert with a system that you do not control, some of these assumptions and arrangements may be ill-advised. As a result of these types of issues, many operations that are coordinated between two businesses, or within a sufficiently large business, are conducted in an asynchronous and decoupled fashion.
You'll be seeing a lot of features coming to improve the state of asynchronous and decoupled programming in WCF in future releases. Starting next time I'll talk about some of the ones we've announced in .NET 4.0.
