Saturday 25 June 2016

Message Exchange Pattern (MEP)

Calling a function from the application code always follows a simple Request-Response pattern i.e. we call the function, for the time the function is being executed the caller will wait for the function(block) and once the function call returns the calling code with become responsive again.

This is ok for the function that is quick .i e function does not takes long time. but if the function being called takes some considerable time to execute then the calling code will be unresponsive for that period. then what we can do. so for that WCF provides various way to manage such situation.


Before looking at the message exchange pattern let us think about the scenarios that we might need from a service consumers perspective.
  1. Scenario 1: We have some function calls that are not taking too much time and letting the application wait for such functions is totally acceptable.
  2. Scenario 2: (Fire and forget) We have some function call which is time consuming but calling that function is more like a trigger from our application code. We just want to call the function and don't want to wait for the response from the function.
  3. Scenario 3: (IsOneway True)We have a long running function, we want to call the function in such a way that the function call is not blocking and at the same time we want something out of the function(response) into our application.
  4. Scenario 4:(Callback Notification) We want a two way communication mechanism(like events) where we hook up our client with the service, call a function and return back. The service can in turn call a callback function to let the application know about the response.

WCF provides 3 message exchange patterns:
  1. Request/Response
  2. One Way
  3. Duplex
Request-Reply:
This is the default Message Exchange Pattern. In this pattern the client sends a request to the server and it waits for the response until the server does not stop processing, for example if the client a sends a request to get the name of all users then the service will proceed with it and the client must wait for a response when the service sends a result then the client is free. if we use the void keyword then it will also take more time. The one property to set the pattern of request/response is IsOneWay=false and all the WCF bindings except MSMQ based binding supports the request/response.

// specifies the request-reply message pattern  [OperationContract(IsOneWay=false)] //IsOneWay=false is optional, by default it is false. //declare the method which return type is string  string RequestReplyPattern(); 

Is One Way True:

In the one-way message exchange pattern, a client application sends a message to a WCF service but the service does not send a reply message to the client.
Use the IsOneWay property to indicate that an operation does not return a reply message.
We can not use Fault Contracts in Oneway(for implementing this we need to use one-way from service to client).
2.The return type is void is must.

[ServiceContract]
public interface IProjectManager
{
   [OperationContract(IsOneWay=true)]
   void Run();
}

Basically with a one way operation the client calls the service and the service may queue the call to be dispatched one at a time. If the number of queued calls exceeds the queue’s capacity the client will block. In the case of a one way call the message is queued but the client unblocked. It is not an async call but may appear that way.

Point to be remember for IsOneWay true:
  1. The service will release the connection (or complete the HTTP request/response byreplying with null, etc) before dispatching to user code. If the operation is not marked with IsOneWay then our Dispatcher won’t reply until the Operation has completed
  2. ServiceModel Runtime will ask for IOutputChannel first, before falling back to IRequestChannel or IDuplexSessionChannel if IOutputChannel isn’t available. This allows the underlying stack to make optimizations on send/receive.
  3. Service Model Faults will not be returned, so Exceptions caused by the Message-level processing are not propagated to the client (though it’s still possible to receive a framing-level fault such as an HTTP status code error).




No comments:

Post a Comment

Contact Us:

Email:

Vinodkumar434@gmail.com,
vinodtechnosoft@gmail.com

Skype Name:

vinodtechnosoft