I'm thinking of what should be practical example of using WCF one way message exchange,
since I'm concerned about success or failure of any operation which I send to WCF service
and in one way message exchange - WCF service does not report success or failure of operation.
When your binding is MSMQ, you must use one-way operations.
All service operations must be one-way because the default queued binding in WCF does not support duplex communication using queues - Queuing in WCF
Plus, callbacks to a possible client regardless of protocol should be one-way in case the client has snuffed it.
Related
I have system like this:
Windows service (WCF, data/events) <-> Web app <-> Web client
I need simultaneous response for clients requests. I have some events from service for clients too. So duplex channel is the way to go. But I need high throughput, because clients calls simultaneously.
Request/reply approach
In order not to serialize channel requests I need more channels for parallel calls, right? But how to handle callback channel then? Ho to keep it still open for receiving events, even on channel errors?
OneWay approach
On channel should be enough (no waiting for data preparation), but how to link data sent to callback with original request, to be able to compose response for client?
What is the way to go? Thank you.
In a simple case, when a web client sends a request to the web app, and web app (possibly) sends a request(s) to WCF service, there's no need in duplex binding at all.
As for events, raised by the service to be fired in Web client, I'd suggest to use a message broker which supports WebSockets - for example RabbitMQ. It has a plugin compatible with WebSockets and WCF binding.
Putting things together, one can create a RabbitMQ server, which accepts messages from WCF service and sends it to Web client, which subscribes to the event feed from Javascript.
I have an application that places messages on MSMQ, than I have a WCF service that I want to automatically read these messages from MSMQ.
I do not want to trigger my WCF service but I want it to be notified whenever a message is pushed on MSMQ. I have found some stuff related to WAS and netMSMQBinding, but the details seems a little unclear about automatic notifications from MSMQ to WCF.
Any help/direction in this regard? Thanks.
What is it that you're trying to achieve?
There is really no such thing as "be notified when a message is pushed on MSMQ". MSMQ uses a pull model to retrieve messages from a queue, so there always needs to exist some kind of "listener" that reads messages from the queue and processes them.
In this case, this "listener" is provided by the WCF NetMsmq or MsmqIntegration bindings automatically, so the programming model for a WCF service that is exposed over MSMQ is just like that of a regular one-way service.
As you state, you can either host that WCF service using your own custom host (such as a Windows service), or, in many cases, the preferred method will be to host that service in IIS 7.X/8.X through WAS.
The following sample shows how to host an MSMQ service in WAS: http://msdn.microsoft.com/en-us/library/ms752246(v=vs.110).aspx
Notice that you do need some specific configuration in IIS to be able to host non-HTTP services, which includes enabling the "Non-HTTP Service Activation" feature. The following articles will be useful to get this done:
http://blogs.msdn.com/b/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/07/13/msmq-wcf-and-iis-getting-them-to-play-nice-part-2.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/07/14/msmq-wcf-and-iis-getting-them-to-play-nice-part-3.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/05/17/building-a-pub-sub-message-bus-with-wcf-and-msmq.aspx
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.
We have a solution where we are picking the messages using Windows Service.
The Windows Service fires every after 2 minutes and retrieves the MSMQ message to pass it to a Web Service.
Can I create a WCF service which will automatically picks up the messages from MSMQ Queue?
Can I avoid Windows Service by using WCF Service if it support auto invocation?
Q1: you can automatically pick up messages from MSMQ, you will need to look into the netmsmqbinding, there are some design considerations that you have to think about though, if you are used to the native MSMQ, you know that you have the ability to peek at the messages. But when you use WCF, you loose that ability to peek. WCF will intercept the messages in MSMQ and you are responsible for keeping your WCF service and the peeking app in synch.
You will also need to look into whether you need transactional or non-transactional queues and you will have to modify your binding based on that.
Q2: You will need to host the WCF service in windows service or in IIS7. if you host in IIS7 look into enabling MSMQ WAS listener
Here is a nice article:
http://blogs.msdn.com/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx
One way to transfer messages from an MSMQ to a web service call is to use a netMsmqBinding service endpoint and a basicHttpBinding client endpoint that support the same contract. The netMsmq service will automatically grab messages from the queue and deserialize them into an object. In your implementation of your netMsmq service, just instantiate your basicHttp client proxy and just call the same method. Basically a pass-through or proxy pattern from the web-service to the MSMQ and vice-versa. In Juval Lowy's "Programming WCF" he calls this pattern the "HTTP Bridge" for queues.