1. Request and Reply

Request and reply is the default mode of operation invocation on a service. This essentially means, that the client blocks until the service has finished its operation and returns with the message to the client. In reality the service sends not one but multiple messages, and the client waits until all messages are received to construct the result.

This way of method invocation is straight forward to use and depicts the classic client server model. Yet it might not alway be what you want from your distributed services.

The request and reply is supported by every Binding of WCF except for MSMQBinding which only supports One Way calls.

2. One way calls

When you set the IsOneWay property on the OperationContractAttribute, you can expect to get no result from the service call on the client side. You would do this in several scenarios.

First when you are not interested in the result of the service, or if it is even executed. Another scenario is a disconnected, queued service, that uses a message queue (MSMQBinding) for message processing on the service side. This sort of message queueing must not have any other operational mode than one way call.

One thing to consider when utilizing one way operations, is that they are not equal to asynchronous operations. Also you would expect that a one way operation would not block the client, this might not be true. If the buffer for messages on the service side is filled, the client blocks until there is space in the buffer.

One way calls are supported by all the Bindings of WCF.

One thing to remember is that a one way call operation only makes sense on Per-Call or Singleton (see Servicebehaviors). Although technically possible in a Sessionful service it does not make much sense, because you would expect that the sessionful service manages some state on behalf of the client.

Also it is called fire-and-forget, it is not really forget, because you can still access any exceptions that the service encountered on the client side with the current operationcontext. To create true fire-and-forget methods you will need to create asynchronous methods on the client side which we will explore in point 5 of this list.

3. Duplex callbacks

Callbacks are most used for events to signal from the client to the service. It essentiallz flips the client and service relationship. These operations are called duplex operations.

Immediately two questions turn up when you think about this. First of all where is the endpoint that the client provides to the service? And secondly how does the client facilitate the callback object?

When you think about this, you will learn that the callback can only be facilitated via the current operationcontext of the client service interaction. This in turn makes clear that this way of operations can only be used in WCF-WCF communications and therefore only be used with TCP, IPC and WSDualBinding. Whereas the last one uses two http connections, one for the service call and one for the callback.

Callbacks in itself are extremely versatile and flexible. I often use them in pure WCF-WCF communications, especially in IPC contexts and that is why I wrote a complete post about it here.

4. Streaming

As I mentioned before (in the one way operation section) the messages as result from service to the client are buffered by default and build up until the full response is facilitated.

When you have a bigger payload like with multimedia types you would want a more convenient programming model. This is what streaming in WCF gives you. Yet WCF still sends the messages like with default mode, but the client can use parts of it instead of buffering all the messages. So this is not really a stream, but a programming model nicety.

Nonetheless it helps with huge payloads in a way that you can define the maximum message size and triangulate how big it needs to be for your use case of the service.

All of the below mentioned methods that use the Stream are allowed. Notice that you can only provide the Stream base class because it needs to be serializable.

[ServiceContract(Namespace="mydomain", Name="streamingservice")
public interface IMyStreamingService
{
[OperationContract]
Stream StreamedMethod();
[OperationContract] 
void StreamedMethod2(out Stream stream);
[OperationContract]
void StreamedRequest(Stream stream);
[OperationContract(IsOneWay=true)]
void OneWayStream(Stream stream);
}

To enable streaming you need to set the enum TransferMode property on the Binding that you initaite for your service with any of the threee Streamed enumeration values:

public enum TransferMode
{
Buffered, //defaults to this
Streamed,
StreamedRequest,
StreamedResponse
}

Streaming is only supported by TCP, IPC and Http bindings. It is also not available when the SessionMode is set to SessionMode.Required. Furthermore it does not support messagelevel Transfer security, because single messages that are sent can not be secured.

5. Asynchronous Methods

 

6. Queued or disconnected services

Categories: Contracts

0 Comments

Leave a Reply

Avatar placeholder