WCF Service - Asynch Operation or Queued Messaging - wcf

I have a WCF service hosted as Windows Service with most of its methods currently defined as:
[OperationContract(IsOneWay = true)]
But, now I need to send response back to the calling Web application for these service methods.
Now, because service methods are bit heavy (FYI, they are reporting methods that needs to do mail merge for a no. of records), I am thinking to either queue them or to process asynchronously, so essentially when the request is sent to the service it should save the request to database/queue, returning Request-Id to calling Web application.
In the mean-time, WCF service can just process incompleted requests from the queue or database.
Then either calling Web application can ping WCF service for status of request because it has Request-Id or
WCF service can ping back to calling app when the process corresponding to a Request-Id is completed.
To achieve above, can anyone please guide what changes I need to make to my WCF service (which currently has all one way operation)?
Also, please guide me whether I need to go for Asynch operation or message queuing?
Thank you!

Of course, going Async is simple:
remove the OneWay on the OperationContract in question and regenerate your Service WITH Async methods. There's a reason why Silverlight forces you to use Async operations. They do force you to rethink your UI.

Related

WCF in UWP: should I explicitly call the OpenAsync() of the service client(proxy)?

I'm developing a UWP client project which need to consume some services of a WCF server. I uses the "add service reference" tool of Visual Studio to auto generate service clients(proxies). The binding type is NetTcpBinding. Below is some code snippet which create the service client:
NetTcpBinding tcpBinding = new NetTcpBinding();
tcpBinding.Security.Mode = SecurityMode.None;
tcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.None;
tcpBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
MainServiceClient = new MainServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8773/MyWCF/MainService/tcp"));
The question is do I need to call OpenAsync() method of MainServiceClient? It seems the service client can be auto opened when it is first called. But I read from this article that auto-opened service client would have some performance penalty. The article was written in 2007. I just wonder if this mechanism have changed today, especially in UWP project. Can anyone share more light on this topic? Thanks!
To explain this case, you should know three ways to do WCF instance management. WCF has provided three ways by which you can control WCF service instances:Per call, Per session, Single instance.
When we configure a WCF service as per call, new service instances are created for every method call you make via a WCF proxy client.
Very often we need to maintain state between method calls or for a particular session. For those kinds of scenarios, we will need to configure the service per session. In per session, only one instance of a WCF service object is created for a session interaction.
Often we would like to create one global WCF instance for all WCF clients. To create a single instance of a WCF service, we need to configure the WCF service as Single instance mode.
And there are three ways by which you can handle concurrency for each service instance in WCF :single, multiple, and reentrant.
Single: A single request has access to the WCF service object at a given moment of time. So only one request will be processed at any given moment of time. The other requests have to wait until the request processed by the WCF service is completed.
Multiple: In this scenario, multiple requests can be handled by the WCF service object at any given moment of time. In other words, requests are processed at the same time by spawning multiple threads on the WCF server object. So you have great throughput here but you need to ensure concurrency issues related to WCF server objects.
Reentrant: A single request thread has access to the WCF service object, but the thread can exit the WCF service to call another WCF service or can also call a WCF client through callback and reenter without deadlock.
In "Instance mode = Per Session and Concurrency = Single" combination, one WCF service instance is created for every WCF client session because the WCF instance mode is set to per session. All the method are executed in a sequential manner one by one. In other words, only one thread is available for all method calls for a particular service instance.
For the above scenario, you should always open WCF client proxy explicitly before you are making any calls. Because it will maintain service state between method calls and obtain high performance.
For more detail you could refer to "WCF Concurrency (Single, Multiple, and Reentrant) and Throttling" and "Three ways to do WCF instance management".

Wrapping async MSMQ with a sync WCF service

How can I build a synchronous WCF service that wraps asynchronous MSMQ communications?
Let us have a simple scenario. I have a client which supports only synchronous web service calls. I need to send a synchronous request for "Order", but the back end system exposes this as an asynchronous request and response MSMQs. The WCF does not need to have any logic just wrap the MSMQ asych communication and pass parameters back and forth.
Grateful for your help
Let us have a simple scenario. I have a client which supports only synchronous web service calls
Synchronous call means you are using same link (end point url) or channel for your communication between client and server, so according to your assumption no.
Reason: Every time your client will send a request, it will keep waiting for response from server and will produce error.
Alternatively,You can define two services (different end point url) in your wsdl or webservice, one for request and one for response.
At client side you need to invoke these end point url saperately for sending request and receiving response,so it will appear as synchronous but ultimately it will be asynch. Thats all you can do in this scenario.
As per my understanding.

WWF service - how do I make a service to be asyncronous?

I want to create a service which receives a request from the client, adds the request to a database and than calls another WWF service ASYNCRONOUS which does some time consuming job withthe data from the database.
How do I make a service to be asincronous in Windows Workflow service?
I use the second Windows Workflow service as a queue(as it can only be one instance of this service=I set canCreateInstance to false).
To make a Workflow Service behave asynchronously create a One Way contract by using a Receive activity without a correlated SendReply.
When another Workflow (or WCF client proxy) calls this service it will not wait for a reply from the service.
As for your comment about only one instance of a service you are mistaken. There is no way to have a singleton workflow service (as there is with WCF services) and CanCreateInstance has no effect on this behavior.

queuing requests with WCF service

I have a WCF service that can receive several requests/minute (or seconds) that need to write information to the database. Rather than write it synchronously, I would like to place these requests in some sort of a queue on the server so that another proces can come along and process them. The client just needs an acknowledgement that the request was received. I have read a lot about MSMQ and WCF etc, but it seems that with MSMQ you write to the queue from client and not to the web service, which is not what I want.
Is there a way to do the following inside a WCF method that does not involve a database. Perhaps i have not grasped the concept of MSMQ right.
public bool ProcessMessage(string message)
{
if(IsValid(message))
return AddToQueue(message);
return false;
}
EDIT: I need to validate the message before writing to the queue.
I do this currently in an application I created. A WCF service is hosted as an HTTP Service on IIS. It accepts calls, and packets of data, I take that data, validate it (tell the caller it's wrong or not) then send the data to another WCF service that is using netMSMQ binding, that service then does the final writing to the database. The good thing about this is it will queue up on one MSMQ and the WCF Service that is bound to this MSMQ pops off one message at a time and processes it. The HTTP WCF service can then handle as many requests as it wants and does not have to worry about pooled up messages as that's the job of the WCF/MSMQ-bound service. The common name for this pattern is a Bridge framework.
ETA: the second service (the MSMQ-bound WCF Service) is run as a Windows service always on. It also handles separation of concerns. The HTTP service validates and does not care about the database, the other service handles writing to the Database.
The point of using MSMQ should be to remove the need for your service to worry about queueing anything. MSMQ will guarantee that your messages get delivered in the proper order and that your service processes them in the proper order.
Your service shouldn't maintain a queue at all if you set this up properly.

Can I listen to a WCF event from a web client?

Can I listen to a WCF event from a web client? Is this possible? I am not talking about call backs, I want the WCF service to raise and event and the web client to be able to listen. Is there a good example of this in C#?
There are no events in WCF. If you want mimic event you still have to call some operation exposed on all clients = you must call WCF service or callback exposed on client.
What do you mean by web client? Do you mean javascript code running in web browser? In such case no you can't achieve that with WCF. You can only use AJAX calls from borowser and continuously poll the service for possible "event".
If you mean ASP.NET application then the answer is theoretically yes, practiacally it will be pretty hard. The reason is that in ASP.NET you handle only current HTTP request by some handler - for example Page. The lifetime of the handler is only for serving the single request. Due to that using duplex service doesn't make to much sense because for receiving callbacks by duplex service your client proxy must live. If you open the proxy in Page it will die after serving the request. If you open the proxy in separate thread you must somehow corelate incomming callbacks to actual client but the client still have to poll the web server to be notified about callbacks. Similar situation will be with exposing the service on ASP.NET application.
Difference between asynchronnous and duplex calls is big. In asynchronnous pattern single request always have single response. Resonse is not sent without request. In duplex pattern you can make single request and receive thousands callback from server.