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.

Service Oriented Architecture

Problem :

In todays business environment, where customer requirements and demands are changing frequently and businesses are operating in heterogeneous markets, business process automation requirements are becoming more complex and new changes to business processes are coming so frequently. Business are asking for software systems which are highly integrated, easy to modify , highly scalable and customizable so that the changes to business processes and requirements can be accommodated easily with less cost and efforts.

To achieve all these business need, software systems has to be highly modular, business functionality from different business units should be divided into distributed components and these components should be accessible in location transparent way and should be highly interoperable.  System components should be deployed across process and machine to deal with performance bottleneck, to introduce security boundary and to facilitate enterprise level reuse.

Question is how do we do it?

Here, Service Oriented Architecture Comes as rescue. SOA is an architectural style or I would say a reference architecture which guides architects on, how they should decompose business functionality into components and how does the functionality of these components is available to other components. SOA brings the concepts of public contracts, policies and interoperability. Because of these concepts, system components can communicate with each other without worrying about the technology, other component has been implemented.  SOA also posses some constraints on component design and the design of communication links between components.

What is Service?

The term service has different meaning at different level of abstractions. At system architecture level, service is a business functionality which is distributable and is accessible to consume in some way.  It is a window through which business functionality cab be reached. 

Consider the application architecture in Following figure. The client application represents an Agency Management

System that includes many chunks of business functionality such as Certificate Issuance, General Ledger, CRM, and Reporting. The client application coordinates access to these features by consuming business components directly. In

this case, components are not distributable in such a way that they can be location transparent, thus they are not services.

 

So how do you implement a service in SOA?

You expose your system components as serviced components using different distributed technologies. Some of the technologies you can use are : Enterprise Services, a .NET Remoting component, an ASMX web service , or a WCF service. Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment, without communicating directly with the business

components.

Following is an updated diagram of Agency Management System. Here each business functionality is exposed using one of the distributed technologies. Serviced components are reached using DCOM over TCP,.NET Remoting components via RPC over TCP,ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.

The point is that services are not necessarily web services—they are merely chunks of business functionality exposed in some way such that they respect the tenets of SOA.

Some of the constraints SOA poses on serviced components

1. Service boundaries are explicit : Services are responsible for exposing a specific set of business functionality through a well-defined contract, where the contract describes a set of concrete operations and messages supported by the service. Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients. Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client. In addition, the location of the service isn’t important to the client as long as the client knows where to reach it. All the distributed technologies provide a way to expose your system components by following this constraint.

2. Services are autonomous : Services encapsulate business functionality, but they must also encapsulate other dependencies of the business tier. In this way the entire service should be moveable or even replaceable without impact to other services or system functionality. A service represents a major chunk of business functionality that owns its own business components, data access components and data storage if applicable. It should be able to perform key functions without external dependencies. This is what is meant by atomicity.

3. Clients and services share contracts, not code : As service boundaries are explicit, Contracts are used to define this boundary to client application. The contract must not change once published, or must at a minimum remain backward compatible to existing clients.

4. Compatibility is based upon policy: While contracts describe the business functionality available at a service boundary, policy describes other constraints, such as communication protocols, security requirements, and reliability requirements.

If the above information is useful, Please provide your valuable feedback.

Thanks.