How to Get Ready for WCF
Most developers are understandably ambivalent about a major upcoming release such as WCF. On the one hand, we welcome advancements in technology and the improvements in functionality and productivity that it will hopefully bring. On the other hand, we dread having to learn a new way of doing things, and we wonder whether we will be able to migrate our existing code to the new infrastructure.
These are valid concerns, especially with WCF. But the issue is less about WCF changing things than it is about things needing to change. Developers today are faced with multiple and often competing technologies for building distributed applications, including the classic choice between XML Web services vs. .NET Remoting. Certainly, there are cases where there is no overlap and no ambivalence and where one technology is clearly the better choice than another. But these technologies share too much in common to be treated differently. They are simply variations of the same technology. In the case of XML Web services and .NET Remoting, they are both concerned with remote distributed object and service invocation over a defined transport channel.
Microsoft is starting to address developer concerns by providing guidelines for how to get ready for WCF. It is already making sure to bring this topic up at professional conferences, and it will certainly continue to do so until the release of WCF. There has simply been too much investment in existing technologies for it not to.
WCF is obviously not a replacement for the entire set of .NET Framework functionality. Instead, it is focused on supporting distributed service-oriented applications with security, transaction support, and reliable messaging. WCF primarily extends four core technologies that are available today:
ASP.NET Web services (built with .asmx pages)
Web Services Enhancements (WSE)
System.Messaging
System.EnterpriseServices
Microsoft has stated that it will make the migration to WCF from current technologies a straightforward process. Here are some guidelines on how to get ready for WCF based on professional conferences, published white papers, and conversations with members of product development teams:
Build services using .asmx pages.
Use WSE 3.0 for additional, extended functionality, including security, policy, and secure conversation.
Build qualified XML schema files for all custom data types used by the service.
Use managed framework classes for integrating your services with MSMQ message queues and with COM+ components. Use the managed System.Messaging namespace for MSMQ, and the System.EnterpriseServices namespace for COM+ components.
Avoid using the HTTP Context object in your .asmx pages.
Avoid using .NET Remoting sinks and channels.
Given that WSE 3.0 is such an important part of this book, let's look in more detail at how you can use the toolkit to prepare for WCF
WSE 3.0 and WCF
WSE 3.0 allows developers to become early adopters of the next generation of service-oriented application technology. Every hour that you spend working with WSE 3.0 is an hour that you have contributed toward WCF. Applications that are built using WSE should migrate smoothly to the WCF framework, with only minor modifications required. If you choose to implement WSE today, then you should expect to accommodate changes to WSE between now and the release of WCF. It is unclear how many revisions WSE is expected to undergo prior to the release of WCF, but it is likely that we will only see service packs released, and they are not expected to negatively impact compatibility between WSE 3.0 andWCF. If anything, they should only make the compatibility tighter.
The main feature that is lacking in WSE 3.0 (compared to WCF) is that it does not provide wide system-level or infrastructure-level support for the enterprise aspect of service-oriented applications. Specifically, it does not provide support for transactions or reliable messaging. Certainly, WSE 3.0 provides many of the required parts, but it does not provide the whole. For example, WSE 3.0 provides support for message addressing, and it also integrates with MSMQ via the System.Messaging namespace classes. So WSE 3.0 gives you the ability today to custom build a service-oriented application that implements "reliable" messaging (via MSMQ) and which can process message addressing information and provide message correlation. But this is not the same as a built-in support infrastructure that manages these tasks for you.
These limitations are not a weakness of the WSE 3.0 technology. They simply underscore two things:
Infrastructure support for message-based, service-oriented architecture is most effectively handled at the operating system level.
WSE 3.0 allows early adopters to start designing and building their code for the future WCF infrastructure. More importantly, it gets developers thinking about application design in new ways. There is a large conceptual jump between traditional RPC-based applications and message-based, service-oriented applications.
With this being said, let's review the major feature areas of WSE 3.0 (which you should by now feel very familiar with) and explain where they fit within the WCF framework:
Security and policy specifications: The WS-Security and WS-Policy specifications are supported by the WCF connector.
Messaging specifications: WCF provides Messaging services that subsume the functionality currently provided by MSMQ. In addition, it provides support for reliable messaging. WSE does not currently provide comprehensive support for the WS-Reliable Messaging specification, but it does provide some of the component parts that you can cobble together to approximate the specification. Specifically, WSE includes support for WS-Addressing, and it integrates with MSMQ via the managed System.Messaging namespace.
Routing and referral specifications: WCF includes these within its Messaging services functionality.
Alternate transport channels: WCF provides support for several transport channels, including HTTP, TCP, and IPC. WSE 3.0 currently provides support for the same three channels, so you can begin coding with them today.
In closing, we hope that this book has ultimately convinced you of three important things:
Message orientation and service orientation are the way to go.
WCF provides a welcome level of support for this technology, which will increase developer productivity and minimize confusion by unifying today's disparate technologies.
WSE 3.0 is an excellent way for developers to become early adopters for WCF.
Good luck with your future adventures in service-oriented architecture!
