I have a requirement where a service should be sending a message to client every second. There can be only one client to the service.
I have a created a duplex service and now confused on instance, concurrency and session for the service.
Is session always required for a duplex service? SessionMode.Required
Does the InstanceContextMode should always be PerSession. InstanceContextMode = InstanceContextMode.PerSession?
What should be the ConcurrencyMode?
How can I prevent additional client connection to the service. Should the callback reference in teh client be static and check for null reference when client request is initially received.
I’ll be implementing a heartbeat operation to check the availablity of the service. Should this be a one-way or request reply call and would this call be in same session?
Thanks.
May be I'm late for a few month... If you have only one client and will not have more clients in future, you can use simplest settings: InstanceContextMode.Singleton, SessionMode.NotAllowed.
About ConcurrencyMode you can read in this tutorial: http://codeidol.com/csharp/wcf/Concurrency-Management/Service-Concurrency-Mode/
Related
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".
Is it possible a service to call client after 4 -5 days when client is offline? e.g.
1. The client request some reports through service.
2. Service updates database with client request.
3. Offline work is done on the request
4. Report is uploaded to the database.
Can we service call its client and send report as soon as report is uploaded to database?
Can WCF duplex service be used to call client when client is offline?
Yes. WCF can be configured to use MSMQ as a transport. MSMQ is the only WCF transport that allows for all three:
disconnected scenarios
resume when computer becomes online and
optionally provide a level of guaranteed delivery
MSDN:
If you need to support disconnected queuing, use netMsmqBinding. Queuing is provided by using Microsoft Message Queuing (MSMQ) as a transport, which enables support for disconnected operations, failure isolation, and load leveling. more...
Essentially you invoke a WCF method (send a MSMQ message) and it will be delivered when the computer comes on-line again. Assuming you have set the appropriate expiration options.
I have a WCF service hosted as Windows Service.
Nothing fancy InstanceContextMode and ConcurrencyMode is set to Single.
I know there is a default queuing mechanism that WCF uses because I can see that all the requests sent to the service are getting processed.
My question is this, is there a way to know at any particular instance the requests in the queue?
Basically I am looking at getting the requests in the queue and maybe log them to a file for a given instance.
Regards.
What is the main difference between Request-Response and Duplex in WCF Message Exchange Pattern?
The main difference is that, after the client establishes a channel to the service, the service can call the client independently at any time. In Request-Response the service only communicates back after receiving a Request from the client. So by using duplex you receive an event-like behavior from the client perspective. Obviously such enhancement requires a Session to be maintained (instance mode PerSession on the service). You can read more on the msdn.
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.