Why WCF when there are other technologies to implement distributed software systems?

 

Need for distributed software systems.

How do you create distributed application?

 

At architectural level you design your software systems by breaking the business functionality into multiple components and than deploy these components on separate process and machine boundaries.  All these components running on separate process and machine boundaries has to have some communication between them using some protocol so that they can collaborate to achieve the overall business functionality.

 

There have been many technologies available to develop the components and deploy them in distributed manner. Following are some the examples

 

1. .Net Remoting

2. COM and DCOM
3. CORBA  and RMI
4. Microsoft Enterprise Services

 

So what's wrong in using the above technologies to create distributed apps?

 

There is nothing wrong creating a distributed application using these technologies until your application is going to be used outside the organization or department and not going to interact with other applications in future. When the need to interact with other application comes in, it becomes really hard to achieve the desired interaction among applications because of the mismatch in data structures and protocol stack between your and other applications. Interoperability becomes  an issue because of proprietary standards and protocol stacks used to develop the applications. Other than interoperability issues, all these technologies has a limitation where firewalls can block the communication between components. 

 

How do you tackle with interoperability among distributed components?

 

We use web service technology in which components are exposed to other components using xml based open web standards (SOAP , WSDL, HTTP). These standards are acceptable throughout the software industry. As these standards are based on XML and HTTP which are supported on all platforms, components exposed using these standards are easily accessible between different platforms, ex a components running on windows platform can be accessed via components running on Unix platform. Following are some of the web service elements which makes interoperability possible.

 

Standard protocol: Functionality is exposed via interfaces using one of the few standard Internet protocols such as HTTP, SMTP, FTP, and so on. Mostly used protocol is HTTP.

 

Service description: Web services need to describe their interfaces in detail so that a client knows how to “consume” the functionality provided by the service. This description is usually provided via an XML document called a WSDL document. (WSDL stands for Web Services Description Language.)

 

Finding services: Users need to know what web services exist and where to find them so the clients can bind to them and use the functionality. One way for users to know what services exist is to connect to the listing of services. These listings are implemented via Universal Discovery, Description, and Integration (UDDI) repositories.

 

From above text it should be clear that there are many technologies available to implement distributed components with there own specific advantages and disadvantages and you should web services to expose your components outside your organization or department boundaries because of its open standards support all around in software community.

 

Now imagine that your organization or department needs to develop an application which has to be used internal to your organization and will also be accessed from outside your organization or department.  You might go and use .NET Remoting to expose your serviced components for internal users and will have to used web services to expose same components  to the users outside your organization. But if you do this your code base for the components will have the knowledge for both the technologies being used to expose the functionality as a service. Your developers will be investing more time in dealing with the technology implementation rather than the business functionality implementation.

 

What if you can abstract away the fact from your code base that your component is going to be exposed using multiple protocols and technologies? What if you can enable or disable any protocol in your already running component without stopping it or doing any code changes?  All these features were kind of dream before WCF came in market.

 

WCF introduction

(Develop once and use anywhere)

 

WCF is new Microsoft technology, actually a framework build upon .NET framework, which makes it really easy to develop serviced components and deploy them using multiple communication protocols. It supports net.tcp, net.pipe, HTML, HTTPS and MSMQ communication protocols. Biggest advantage of using WCF is that the knowledge of what all protocols are being used to expose your component is completely abstracted from the component code.  WCF framework is highly extendible as well. It provides so many extension points using them your can implement your own protocols and control almost all the expects of exposing your component as service. 

 

Following are main goals of WCF

 

1. Unification of existing technologies: 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.

 

 

 

2. WCF As a Service-Oriented Development Tool: WCF offers that foundation for service-oriented applications by supporting all the four tents of SOA mentioned in my post.

 

 

3. Coexisting with Existing Technology: WCF takes all the capabilities of the existing technology stacks while not relying upon any of them. All your existing investments will run side by side with WCF. Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed. It also provides you with an opportunity to communicate with, or even replace, existing Windows communications APIs and technologies, including ASMX, ASP.NET web services, Web Services Enhancements (WSE), Enterprise

Services, System.Messaging, and .NET Remoting.