During the past decade, a lot of research has been done in the field of distributed computing. Microsoft and other leading vendors have come up with various distributed technologies. Each of the technologies reduces the convolution of building rich applications and lowers development costs. The latest from Microsoft is Windows Communication Foundation (WCF), the next-generation uniform way of developing distributed applications by providing a service-oriented programming model.
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. We’ll now cover these technologies in bit more detail.
Introducing COM:
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.
Introducing DCOM:
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:
1. 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.
2. 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.
3. 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.
4. 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.
5. DCOM, like other distributed technologies, is based on two-tier architecture and suffers from some of the same flaws of two-tier architecture.
6. 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.
Introducing .NET Remoting:
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. It addresses problems that have wounded distributed applications for many years (that is, interoperability support, extensibility support, efficient lifetime management, custom hosts, and an easy configuration process). .NET Remoting delivers on the promises of easy distributed computing by providing a simple, extensible programming model, without compromising flexibility, scalability, and robustness.
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.
Why are Web Services the Preferred Option?
Unfortunately, with an existing distributed technology stack, you’ll often find a number of limitations, especially with interoperability between platforms. For example, if you try to deploy a COM+ application to converse across a firewall or to converse across smart routers or organizational boundaries, you’ll often find some significant differences. Most of the earlier distributed component technologies were by no means built to deal with firewalls and intelligent routers. For instance, if you build an application using Microsoft Enterprise Services (a set of classes provided by Microsoft to be leveraged in enterprise applications), how do you utilize the service from a Java client? Considering that most of the enterprises are working on different technologies and different platforms, interoperability is a major issue. Generally, companies used to buy some complex software and invest a lot of money in building a bridge between the existing components to make them distributed. Other complexities and difficulties soon arose when these custom solutions needed to be extended further. Web services solve these problems by relying on open standards and protocols that are widely accepted.
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.
What Does WCF Solve?
WCF is not just another way of creating a distributed solution but provides a number of benefits over its predecessors. If you look at the background of WCF, you’ll find that work on WCF started with the release of .NET. Microsoft unveiled this technology at the Microsoft Product Developers Conference 2003 in Los Angeles, California. In other words, it has taken years to build and come to market. WCF addresses lots of issues, and Figure below shows the three main design goals of WCF:
· Unification of existing technologies
· Interoperability across platforms
· Service-oriented development
Unification of Existing Technologies:
The current world of enterprise computing has many distributed technologies, each of which has a notion to perform a specific task and have its distinct role in the space. Apart from that, these distributed technologies are based on different programming models. (For example, if you are building an application that happens to communicate over HTTP, you will be required to change your programming model if you want to switch to using TCP. If you are used to building XML web services today, you don’t have the ability to support and flow transactions with message queuing enabled without changing your programming model.) This has created problems for developers, who have to keep learning different APIs for different ways of building distributed components.
The constant fight since the 1990s between distributed technologies has led to a debate about which technology is best suited for developing distributed applications in the long term. One of the interesting questions is, why not have just one technology that can be used in all situations? WCF is Microsoft’s solution to distributed application development for enterprise applications. It avoids confusion by taking all the capabilities of the existing distributed systems’ technology stacks and enables you to use one clean and simple API. 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.
If you look at below figure, you will find that WCF subsumes the best of all the distributed technologies.WCF brings together the efficiency of ASMX, the gift of merely adopting transactions with Enterprise Services just through using attributes, the extensibility and flexibility of .NET Remoting, the supremacy of MSMQ for building queued applications, and WSE’s interoperability through WS-*. Microsoft took all these capabilities and built a single, steady infrastructure in the form of WCF.
Interoperability across Platforms:
Most of the big software companies are developing software using proprietary protocols that are tightly coupled with a specific platform. This succumbs to the problem of not being interoperable with other software running on different platforms. When you look at any large enterprise in particular, you often notice a number of disparate systems built and bought over periods of time.
Often these systems are incompatible with one another. The ability to link the systems becomes a crucial need for a large number of organizations. In addition, newly developed applications need to interoperate with the existing platforms, and the business needs to support applications written in different programming languages with different technologies.
Also, companies need seamless interoperability across the organization between “purchased” software from different software vendors. 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.
One of the great features of the WS-I specifications is that they are simple, small, modular, and easy to implement. You are free to choose which specification you need to implement. For example, implementing WS-Security does not mandate that you implement transaction specifications. It is broken down into several layers. (For example, there is a specification for sending a digital signature in a SOAP message and a different specification for sending a simple username and password in SOAP.) The core architecture of a web service specification for all this is WSDL. Therefore, WCF speaks the language of the latest web service suite of protocols to achieve seamless interoperability across platforms.
Windows Communication Foundation (WCF):
Windows Communication Foundation (WCF) is an SDK for developing and deploying services on Windows. WCF is Microsoft’s unified programming model for building service-oriented applications with managed code. It extends the .NET Framework to enable developers to build secure and reliable transacted Web services that integrate across platforms and interoperate with existing investments.
Purpose of WCF:
Web services are just one technology that you can use to create distributed applications for windows. Others include Enterprise Services and .NET Framework Remoting. Another example is Microsoft Message Queue (MSMQ). If you are building a distributed application for windows, which technology should you use, and how difficult would it be to switch later if you need to?
1. The purpose of WCF is to provide a unified programming model for many of these technologies, enabling you to build applications that are as independent as possible from the underlying mechanism being used to connect services and applications together.
2. It is very difficult to completely divorce the programmatic structure of an application or service from its communications infrastructure, but WCF lets you come very close to achieving this aim much of the time.
3. Additionally, using WCF enables you to maintain backwards compatibility with many of the preceding technologies. For example, a WCF client application can easily communicate with a Web service that you created by using WSE.
Advantage of WCF:
1. WCF is interoperable with other services when compared to .Net Remoting where the client and service have to be in .Net.
2. WCF services provide better reliability and security in compared to ASMX web services.
3. In WCF, there is no need to make much change in code for implementing the security model and changing the binding. Small changes in the configuration will make your requirements.
4. WCF has integrated logging mechanism, changing the configuration file settings will provide this functionality. In other technology developer has to write the code.
Disadvantage of WCF:
Making right design for your requirement is little bit difficult.
Service and client in perspective of data communication:
A service is a unit of functionality exposed to the world. The client of a service is merely the party consuming the service.
Difference between WCF and Web services:
1. Web services can only be invoked by HTTP. While Service or a WCF component can be invoked by any protocol and any transport type.
2. Second web services are not flexible. But Services are flexible. If you make a new version of the service then you need to just expose a new end point. So services are agile and which is a very practical approach looking at the current business trends.