- Exploring the Windows Communication Foundation (WCF)
- Windows Communication Foundation: The Official Definition
- Building Solutions Using the Windows Communication Foundation
- Running Windows Communication Foundation Solutions
- Next Steps
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building Solutions Using the Windows Communication Foundation
With the Windows Communication Foundation, you’re either building a service or building a client that consumes a service. That description generalizes the point, but when you start to examine the WCF deeply, you really get an understanding of the simplicity of service-driven solutions.
Solutions are built through the exchange of contracts. This structure is similar to the token exchange used in web applications, but the approach is broader for all .NET solutions. The contract exchange starts through declaring starting and ending points.
The following example illustrates the declarative nature of defining contracts in the Windows Communication Foundation:
using System.ServiceModel;
namespace ServiceExample
{
[ServiceContract(Namespace="http://localhost.org/mySample/")]
public interface ThisDemoService
{
[OperationContract]
string ThisService(string msg);
}
}
Note that you have both a ServiceContract and an OperationContract. The strength of the Windows Communication Foundation can be demonstrated by the OperationContract. In this instance, the default contract is a SOAP message, but you can add additional OperationContracts to perform different messaging types from one object, thereby allowing a service to run as both SOAP and .NET Remoting in the package, if you choose.
Notice that the language is a typical .NET language, not a new language with its own syntax and learning curve.
Receiving and consuming the service can be managed in a similar way. Extensions to the Configuration document, an XML file used in forms, services, and web applications, has been extended. The following example demonstrates this principle:
<configuration>
<system.serviceModel>
<services>
<service type="ServiceExample.ThisService">
<endpoint address="svc" binding="basicHttpBinding"
contract="ServiceExample.ThisService"/>
<endpoint address="net.tcp://localhost:8081/ThisService/svc"
binding="netTcpBinding"
contract="ServiceExample.ThisService"/>
</service>
</services>
</system.serviceModel>
</configuration>
In this example, the endpoint contract is looking for either a SOAP or a TCP service call. The reason for the two endpoints is that the application can choose which service it wants to consume. This is particularly useful when you don’t know what type of communication you’re consuming in your application, or if multiple choices are available.