Overview of WCF in C#.NET

Printer PDF-417 2d barcode in C#.NET Overview of WCF

Beyond WSE 3.0: Looking Ahead to Windows Communication Foundation (WCF)

oday, WSE 3.0 is the easiest way to implement selected WS- specifications in your .NET Web services and service-oriented applications. WSE 3.0 provides developer support for building service-oriented applications and infrastructure support for running them. Web services and service-oriented applications require a lot of support to build and run. Developers require classes that make it easier to work with messages without having to interact with the raw SOAP In addition, they require infrastructure support to make it easier to run service. oriented applications. WSE 3.0 provides all of these levels of support: A rich class framework for implementing important WS- specifications such as WS-Security and WS-Addressing. Infrastructure support in the form of the WSE pipeline, which automatically intercepts and processes incoming and outgoing SOAP messages. Infrastructure support for common service requirements, such as policy verification (using WS-Policy). For example, WSE 3.0 automatically processes XML-based policy framework files, which saves you from needing to write additional processing code in both the service and the client. WSE is very good at implementing discrete WS- specifications such as WS-Security and WS-Policy, which can be boiled down to a set of specific operations. But where WSE falls short is in being able to provide the infrastructure support for broad-based WS- specifications, such as WS-Reliable Messaging, which provide service guarantees for message delivery. This is where Windows Communication Foundation (WCF), formerly code-named Indigo, and Microsoft Windows Vista (the next version of the Microsoft Windows operating system, formerly code-named Longhorn) come into play. WCF refers to a new unified programming and infrastructure support model for service-oriented applications. It provides built-in support for message-oriented and service-oriented architectures, built of course on the managed .NET Framework. WCF will greatly enhance developer productivity in these application areas.

CHAPTER 9 BEYOND WSE 3.0: LOOKING AHEAD TO WINDOWS COMMUNICATION FOUNDATION (WCF)

There are many reasons why you should start learning about WCF today. The most important reason in our opinion is that you need to know how relevant your existing service-oriented applications will be with a new support infrastructure such as WCF. The questions you should be asking yourself are How will I build service-oriented applications in the future using WCF How do I preserve the existing investment that I have made in my XML Web services and .NET Remoting development What current technologies are going to be phased out in WCF Should I be using WSE 3.0 today The purpose of this chapter is to give you a preview of WCF from the perspective of where we are today with WSE 3.0. As you will see, every hour spent learning and working with WSE is a worthwhile investment that is directly applicable to Web service development with WCF. This should be of no surprise because WCF is still based on the standards and specifications that we are comfortable with today. WCF does not reinvent the WS- specifications or use exotic transport channels that we have never seen before. Instead, it provides a better support infrastructure for building service-oriented applications that implement today s important standards and specifications, including the WS- specifications. And best of all, WCF is strongly oriented toward services and messages.

change before the production release. You can read more about WCF at http://msdn.microsoft.com/ webservices/indigo/default.aspx. In addition, you can read about how to implement WCF in beta with a Go-Live license at http://msdn.microsoft.com/winfx/downloads/products/golive/.

WCF is an exciting technology because it unifies all of the concepts that have been presented throughout this book. Developers today must contend with a variety of different technology choices for building distributed applications, including XML Web services (.asmx) Web Services Enhancements (WSE) .NET Remoting MSMQ (provided by the .NET Framework System.Messaging namespace) Enterprise Services (the .NET Framework namespace for COM+) These various technologies overlap and complement each other in different ways. In many cases an application requirement can be fulfilled with two or more of these technologies. Perhaps the clearest example of a potential overlap is with XML Web services and .NET Remoting. Both technologies operate on the same principle, namely that they facilitate

CHAPTER 9 BEYOND WSE 3.0: LOOKING AHEAD TO WINDOWS COMMUNICATION FOUNDATION (WCF)

remote service invocation over a defined transport channel. Furthermore, .NET Remoting operates over both the TCP and the HTTP protocols, which means that the key difference with XML Web services is its use of a binary message format rather than SOAP .NET Remoting solu. tions are generally more focused on object invocation using remote procedure calls (RPCs). On the other hand, XML Web service solutions tend to be more focused on invoking services by passing message-based requests, including between diverse platforms. But these differences are simply a function of what the technologies are best at today. With today s technology you do have flexibility and a choice on whether to deploy .NET Remoting vs. XML Web services for the same application solution. And where you do not, it is fair to ask why the technologies should have different capabilities. After all, they are based on the same concept: allowing remote service calls over a defined transport channel. See Figure 1 in the January 2004 MSDN Magazine article A Guide to Developing and Running Connected Systems with Indigo at http://msdn.microsoft.com/msdnmag/issues/ 04/01/Indigo/ for a diagram that illustrates the high-level architecture for WCF. (See the Appendix of this book for detailed reference information.) There are five major areas within the WCF architecture: 1. The WCF service model: Provides general support for services and messages. The service model provides programming and infrastructure support for implementing and managing code as a message-oriented service. 2. The WCF connector: Provides communications support for services and messages, including multiple transport channels, ports, and built-in support for reliable message delivery. The connector provides the infrastructure that allows your service to exchange messages with the outside world in a secure, reliable fashion. 3. Hosting environments: Provides support for several different hosting environments for message-oriented services, including traditional IIS-based ASP .NET hosting. 4. Messaging services: Provides support for managing messages, including message queuing and routing. Messaging services provides the functionality that we currently associate with MSMQ. 5. System services: Provides support for transactions and other low-level system support infrastructure that is complex and that needs to be managed by the framework on behalf of the service. Let s review each of these areas in more detail.