The Code Online

Windows Communication Foundation

Windows Communication Foundation (WCF) is Microsoft’s unified framework for building reliable,secure, transacted, and interoperable distributed applications. WCF represents a new step in distributed programming for developers using the .NET Framework. WCF provides the .NET Framework with a foundation for writing code to communicate across components,applications, and systems. WCF was completely designed with service orientation in mind. WCF, is a programming framework used to build applications that inter-communicate.

Originally tagged with the code name "Indigo", WCF is one of the four new application programming interfaces introduced with .NET Framework 3.0, which was released in December 2006. The .NET Framework is Microsoft technology that ships in Windows operating systems (client, server and mobile platforms). The .NET Framework v3.0 is included in Windows Vista and Windows Server 2008; It is available as a free download for Windows XP and Windows Server 2003, and a similar but separate version is also available for .NET Compact Framework version 3.5. Because WCF is part of the .NET Framework, applications that use WCF can be developed in any programming language that can target the .NET runtime.

The WCF unifies the various communications programming models supported in .NET 2.0, into a single model. Released in November 2005, .NET 2.0 provided separate APIs for SOAP-based communications for maximum interoperabilllity (Web Services), binary-optimized communications between applications running on Windows machines (.NET Remoting), transactional communications (Distributed Transactions), and asynchronous communications (Message Queues). WCF unifies the capabilities from these mechanisms into a single, common, general Service-oriented programming model for communications.

WCF is designed in accordance with Service oriented architecture principles to support Distributed computing where services are consumed by consumers. Clients can consume multiple services and services can be consumed by multiple clients. Services typically have a WSDL interface which any WCF client can use to consume the service, irrespective of which platform the service is hosted on. WCF implements many advanced web services (WS) standards such as WS-Addressing, WS-ReliableMessaging and WS-Security. While Microsoft is a board member of WS-I it is not clear how many WS-I profiles they are committing to support fully.

A WCF Service is composed of three parts — a Service class that implements the service to be provided, a host environment to host the service, and one or more endpoints to which clients will connect. All communications with the WCF service will happen via the endpoints. The endpoints specify a Contract that defines which methods of the Service class will be accessible via the endpoint; each endpoint may expose a different set of methods. The endpoints also define a binding that specifies how a client will communicate with the service and the address where the endpoint is hosted.

WCF provides Windows Activation Services which can be used to host the WCF service. Otherwise the WCF service can also be hosted in IIS or in any process by using the ServiceHost class, which is provided by WCF. Services can also be self-hosted, in a console-based application or a Windows-forms application for example.

A client can communicate with a WCF service using any of the RPC-based mechanisms in which the service can be invoked as a method call. Using synchronous communications, any call to the service will be blocking - that is, it will halt the execution of the client until the service processes the request. The client has to connect to a service using a proxy object, which is connected to the specified endpoint of the service and abstracts the service as an object. All method calls to the proxy object will be routed to the service and the proxy will return the results returned by the service to the caller. Tools shipped with the .NET Framework SDK can consume WSDL and create client-side proxy classes for use with WCF. Such classes handle the serialization and data transmission to and from the service, as well as faults and exceptions.

WCF also supports non-blocking (asynchronous) calls between client and service, via several mechanisms. One option is to use Message Queues as the transport for the delivery and receipt of the messages. (Keep in mind that the use of Message Queues does not imply a change to a Put/Get style programming model. Even with the use of persistent queues, the programming model still uses friendly proxy classes.) A second mechanism for supporting asynchronous communications is via multiple threads - there is a simple mechanism to do this in the generated client-side proxies for WCF. In the .NET Framework 3.5, WCF added support for REST-style communications.

Microsoft started its remote invocation technologies with Distributed Component Object Model (DCOM), which extended Component Object Model (COM). Then, .NET introduced technologies such as .NET Remoting and XML web services. Microsoft developed COM to enable applications to interact with each other and to promote reusability. COM is the set of specifications that, when followed, allows software components to communicate with each other. Each component exposes its functionality through an interface and is uniquely identified by global unique identifiers (GUIDs). The advantage of using COM is that different components developed in different languages can write these software components and interact with each other by using IUnknown and other standard COM interfaces. Most of Microsoft’s products, including Microsoft Office, SQL Server, and even Windows, are based on COM. Though COM provides the ability to reuse the components locally, it was not designed to work well with remote components.

Few specifications and extensions had been made that were based on COM and that interacted with remote components. However, the need for remote method invocations grew substantially. To solve this concern, Microsoft developed DCOM. This essentially is a combination of COM and the network protocol that allows you to run a COM object on a remote computer. DCOM was a proprietary wire-protocol standard from Microsoft to extend COM so it could work in distributed environments. DCOM provides an opportunity to distribute your component across different locations according to the application requirements. In addition, DCOM provides basic infrastructure support such as reliability, security, location independence, and efficient communication between COM objects that are residing across processes and machines.

The following are the problems with DCOM:

• DCOM and other distributed technologies such as CORBA, RMI, and so on, are based on several assumptions. One of the key assumptions is that one organization will manage all the components in the systems that are interacting with each other. Another is that the location of a component will not vary from one place to the other. This scenario can work fine within an organization, but as you cross organization boundaries, the limitations of DCOM become more significant.
• Microsoft has invested a lot in DCOM to ensure that calling a remote method is as simple as calling the local component by simplifying the low-level network communication requirements. Most of the time this resulted in bad programming practices by programmers, which resulted in increased network traffic and performance bottlenecks.
• DCOM, being based on a proprietary standard, was essentially built taking only the Windows operating systems into account, making it not suited for heterogeneous environments.
• Another issue with DCOM is that its client is tightly coupled with the server, so any changes done on the client mandate a modification on the server.
• DCOM, like other distributed technologies, is based on two-tier architecture and suffers from some of the same flaws of two-tier architecture.
• DCOM came before the computer world experienced the Internet boom. DCOM was never built with the Internet in mind. System administrators need to compromise the security of the firewall in order to use DCOM across firewalls/locations. DCOM is used to communicate through ports that are generally restricted by firewalls because the ports are susceptible to attacks.

Though COM and DCOM are able to provide reusability and a distributed platform, they also suffer from problems of versioning, reference counting, and so on. Microsoft .NET came up with a vision to be more connected than ever. It wanted to deliver software as a “service” and also resolve issues related to COM. The release of .NET was termed as the biggest revolution ever on the Microsoft platform after the introduction of Windows. .NET Remoting is one of the ways to create distributed applications in .NET. Developers now have additional options such as XML web services and service components. Essentially, .NET Remoting takes a lot of lessons from DCOM. It replaces DCOM as the preferred technology for building distributed applications.

.NET Remoting delivers on the promises of easy distributed computing by providing a simple, extensible programming model, without compromising flexibility, scalability, and robustness. It comes with a default implementation of components such as channels and protocols, but all of them are pluggable and can be replaced with better options without much code modification.

Earlier, processes were used to isolate applications from each other. Each process had its own virtual address space, and the code that ran in one process could not access the code or data of another process. In .NET, one process can now run multiple applications in a separate application domain and thereby avoid cross-process communication in many scenarios. In normal situations, an object cannot access the data outside its application domain. Anything that crosses an application domain is marshaled by the .NET runtime. Not only does .NET Remoting enable communication between application domains, but it also can be extended across processes, machines, and networks.

Though .NET Remoting provides the best performance and flexibility, it too suffers from some vital pitfalls. The following are the problems with .NET Remoting:

• .NET Remoting works best when assemblies that define the types that are used to integrate are shared. .NET Remoting works fairly well if there is full control over both ends of the wire. Therefore, it works well in an intranet where you have complete control of the deployment, the versioning, and the testing.
• Practically, .NET Remoting is proprietary to .NET and works seamlessly to exchange data between two .NET applications. It is deeply rooted in the common language runtime (CLR) and relies on the CLR to obtain metadata. This metadata means the client must understand .NET in order to communicate with endpoints exposed by .NET Remoting.
• .NET Remoting requires a big leap between programming at a high level and dropping down into the infrastructure. It’s pretty easy to code .NET Remoting with the available components, but if you want to start learning about adding your own transports, the level of complexity increases. .NET Remoting gives you finer-grained control on each architectural component but also requires a deep knowledge of its architecture.
• .NET Remoting suffers from the issues of load balancing because it is not intelligent enough to shift a request from a busy application server to one that is not as busy.

Web services are not just another way of creating distributed applications. The distinguishing factor of web services from other distributed technologies is that rather than relying on proprietary standards or protocols, web services rely on open web standards (such as SOAP, HTTP, and XML). These open standards are widely recognized and accepted across the industry. Web services have changed how distributed applications are created. The Internet has created a demand for a loosely coupled and interoperable distributed technology. Specifically, prior to web services, most of the distributed technologies relied on the object-oriented paradigm, but the Web has created a need for distributed components that are autonomous and platform independent.

XML web services are designed with interoperability in mind and are easily callable from non-Windows platforms. It is common to confuse web services with .NET Remoting. Web services and .NET Remoting are related, but web services have a more simplified programming model than .NET Remoting. In other words, they both look similar from a high-level architecture level, but they differ in the way they work. For example, they both have different ways of serializing data into messages. .NET Remoting supports RPC-based communication by default, and web services support message-based communication by default. Web services rely on XML Schema for data types, and .NET Remoting relies on the CLR. You can use .NET Remoting to build web services, but the Web Services Description Language (WSDL) generated by .NET Remoting is not widely adopted and might be ignored by some clients. Though you can use either for creating components, .NET Remoting is suitable for creating components to be used by your own application running in the .NET environment, and XML web services create components that can be accessible to any application connected via the Internet.

SOA is a vision of services that have welldefined interfaces. These loosely coupled interfaces communicate through messages described by XML Schema Definition (XSD) and through the message patterns described by WSDL. This provides for a great base architecture for building distributed applications. Since a web service and its clients are independent from each other, they need to adhere only to the XSD and WSDL document standards in order to communicate.

WCF is Microsoft’s solution to distributed application development for enterprise applications. In other words, WCF brings the entire existing distributed stack under one roof. All you need to do as a developer is reference the System.ServiceModel assembly and import its namespace.

WCF is a set of class libraries that comes with the .NET Framework 3.0. The .NET Framework 3.0 will become a core API with the Windows Vista operating system.

As you can see, interoperability has been a major issue for all the major software vendors, and they wanted to use a suite of protocols that was widely accepted and adopted. Therefore, leaders in the industry such as Microsoft, IBM, BEA, and Sun formed the Web Services Interoperability (WS-I) organization, which has developed a constant suite of specifications that, if adopted, allows software to seamlessly communicate with other software running on different platforms.

The WCF native messaging protocol is SOAP, which as an open standard provides the opportunity for the WCF service to interact with different technologies running on different platforms and non-Windows operating systems. Since services are based on open standards, other applications can use them without requiring that these clients possess detailed knowledge about the service’s underlying implementation. This is exciting for software architects, because they can know that their WCF application that runs on a Windows 2003 or Vista web server can do reliable messaging with a Java application running on an IBM mainframe.

Reference Articles

• Pro WCF Book By Apress