Elczar Adame's Shared Points on SharePoint


 

WCF in Windows Server 2008

Part II of II : non-HTTP Transports 

Groundwork

As we have brought up previously, the objective of this piece is to carve up basic and high-level considerations on Windows Communication Foundation in Windows Server 2008. We have focused on HTTP transport implementation in Part I, and we will hub on non-HTTP transports in this part. Along the demonstration section, we will seek to enhance our previous WCF service and WPF client applications, then we will attempt to put in plain words some of the fundamental codes.

Review

In the previous part, we have given attention on one of the three constituted technologies of Application Server Core in Windows Server 2008, the Windows Communication Foundation. It is a new service-oriented programming model, edged by .NET Framework 3.0, to intercommunicate and interoperate with other applications.

We have also mentioned that in hosting a distributed WCF application in the Internet Information Services 7.0, it entails employment of Windows Process Activation Service (WAS) to facilitate activation and communication over network protocols including HTTP, NET.TCP, NET.PIPE, and NET.MSMQ.

 

Non-HTTP Transports

In TCP-based communication, the messaging session between machines is established before exchanging data. Each machine is identified through a logical IP address. In the process of delivering a unit of information on a network, the TCP manages the fragmentation of message into packets (a unit of transported information), and the reassembly of the same message from packets. Moreover, the same protocol resends lost packets and guarantees that no data fragment is duplicated.

In the heart of WCF TCP transport is the TCP Port Sharing service. It is a Windows service that allows TCP ports, over Intranet, to be shared across applications that are using WCF for communication. By principle, it is faster than HTTP protocol, but it is no more than for WCF-WCF communication.

A named pipe, on the other hand, is an object in the Windows operating system kernel, including a section of shared memory. It can be employed to grant communication channel between processes on the same computer or between processes on different computers across a network. For WCF, moreover, it is employed using net.pipe schema and ideal for an on-machine implementation of message delivery between WCF applications.

MSMQ, running as an NT service, is one of the features of Windows Server 2008. It is employed by WCF for its queued communication using net.msmq schema. The MSMQ Managers manages message-transfer from a Transmission Queue to a Target Queue. Unlike other transports, queued transport puts into operation the isolation between service, client, and transport. Hence, the transacting parties can fall short without producing an effect on the real communication. Furthermore, it provides reliable communication in spite of failures of the sender and receiver by backing up the message in their corresponding message store.

To endow with consistent communication, MSMQ employs transactional messaging where message is communicated under a transaction. Transaction is a set of operations designed in such a way that if one operation fails, the entire transaction will not be sent to queue.

Additionally, MSMQ provides an asynchronous communication pattern. Hence, the sender needs not to wait for the message to be received and processed by the receiver. Sent message may remain in the Transmission Queue, based on the defined value, until it is sent to the Target Queue. Else, it will be transferred to a Dead Letter Queue.

Demonstration

1.    Primarily, we will verify if non-HTTP protocol is supported. Let us open our Internet Information Services Manager. Click our WCFService site, then click Bindings. In the Site Bindings dialog box we could identify the protocols that are supported.

2.    To complete the configuration, we will open the applicationHost.config file of our IIS at %SystemDrive%\Windows\System32\inetsrv\config directory and add some values to the <enabledProtocols> tag of our Web site. In this case, the results will be:

 

<site name="Default Web Site" id="1" serverAutoStart="true">

<application path="/WCFService" applicationPool="DefaultAppPool" enabledProtocols="http,net.tcp,net.pipe,net.msmq">

<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\WCFService" />     

      </application>

      <bindings>

<binding protocol="https" bindingInformation="*:443:" />

<binding protocol="http" bindingInformation="*:80:" />

<binding protocol="net.pipe" bindingInformation="*" />

<binding protocol="net.msmq" bindingInformation="localhost" />

<binding protocol="net.tcp" bindingInformation="808:*" />

      </bindings>

</site>

 

NOTE: Enabled Protocols property does not have corresponding user interface in Windows Server 2008 Beta 3.

 

3.    Now we will open the WCF Service application we have created in Part I.

4.    In the Solution Explorer, let us open the Service.cs file.

 

Notice that the System.ServiceModel is being referenced. It is the namespace that brings Windows Communication Foundation to existence. As the name suggests, this is what we referred as WCF service model.

 

Other noticeable attributes that characterizes the service model are the [ServiceContract] annotation for the interface (dispatching) and the [DataContract] annotation for the data definition (serialization).

 

5.       Let us add a Namespace to our [ServiceContract] attribute and an Action named parameter to our [OperationContract] attribute. The results will be:

[ServiceContract(Namespace="http://tempuri.org/IService&quot;)]

public interface IService

{

    [OperationContract(Action="Operation:String")]

    string Operation(string Value);

    [OperationContract(Action="DataOperation:String")]

    string DataOperation(Profile Value);

}

An incoming SOAP message is dispatched to a corresponding method based on the Action attribute of an operation contract. Thus, a message with Operation:String action is identified with Operation method, its target operation contract.

 

6.       Upon enhancing our service contract, let us as well carry out basic enhancement on our [DataContract] attribute by adding a Namespace named parameter and some named parameters to our [DataMember] attribute. The results will be:

[DataContract(Namespace="http://tempuri.org/Profile&quot;)]

public class Profile

{

    string firstname;

    string lastname;

 

    [DataMember(Name="First", Order=0)]

    public string FirstName

    {

        get { return firstname; }

        set { firstname = value; }

    }

 

    [DataMember(Name = "Second", Order = 1)]

    public string LastName

    {

        get { return lastname; }

        set { lastname = value; }

    }

}

The data contract is defined for serialization, where the data in the incoming SOAP message is mapped to a corresponding .NET object. In the above code, the SOAP payloads to the .NET string data type. The [DataContract] annotation signifies that we are using the default serialization engine of WCF. This engine serializes fields annotated with [DataMember].

By data contract, WCF service communication is directed through the SOAP body. If required to channel data through header, we can create a message contract and specify the message header and message body fields respectively. To wit:

[MessageContract]

public class Message

{

    [MessageHeader]

    public HeaderMessage HeaderMessage;

 

    [MessageBodyMember]

    public BodyMessage BodyMessage;

}

7.    The next step is to revisit the service implementation we have made in Part I and do an enhancement on its behavior through [ServiceBehavior] attribute. The results will be:

 

[ServiceBehavior(Namespace="http://tempuri.org/IService&quot;, ConcurrencyMode=ConcurrencyMode.Multiple)]

public class Service : IService

{

    public string Operation(string Value)

    {

        return "Hello: " + Value;

    }

 

    public string DataOperation(Profile Value)

    {

        return "Hello: " + Value.FirstName + " " + Value.LastName;

    }

}

8.    Let us open our web.config file and extend our service endpoints to non-HTTP protocols by adding the following <endpoint> attributes to the <system.serviceModel> section of the file:

 

<endpoint binding="netTcpBinding" contract="IService" />

<endpoint binding="netNamedPipeBinding" contract="IService" />

Unlike in self-hosting, IIS hosting does not require us to specify the endpoint address because it is already provided by the location of our .svc file.

9.    Lastly, let us to build our enhanced WCFService.

10. Now, let us open the WPFClient Windows application we have created in Part I and update our Proxy service reference. To do this, right-click the Proxy.map file under the Service References folder, then click Update Service Reference.

11. In app.config file, we will notice additional entries for net.tcp and net.pipes protocols in both <bindings> and <client> sections. Since the service contract interface could not be loaded with multiple <endpoint> configuration, we need to select preferred endpoint in the <client> section, then omit the others.

12. With this, we could rebuild and execute our application enjoying various types of communication protocols.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Tag Cloud

%d bloggers like this: