Question

has anybody experience with async WCF endpoints?

I am trying to understand if using the MSMQ bindings options I could have a setup in which the client knows to which queue the messages have to be put and would work transparently aslo if the wcf service (eventually hosted in IIS) is offline or does not responde.

I would really like to get this setup because in this way when the app server is back online (one of the many application servers we would have for our distributed application), it would process all incoming messages in the queue and elaborate.

I am more thinking about those operations which make sense to have delayed, like messaging management (sending emails out), logging services (write log entries to database, event log or send via email) and similar kind of backend processes.

My other option would be to use TIBCO business works and ems but trying to understand what is better and if simple WCF would work sync or async simply changing the binding from let’s say netTCP to MSMQ….

Thanks!

Answer 1

You have to differentiate between async and queued.

You can do async messaging with, say, NetTcpBinding using client based async invocation, async service execution, OneWay messaging and duplex or simply OneWay messaging.

However, as you say, queues bring the additional benefits of: resilience, load levelling and, depending on the version of MSMQ, scalablility.

The main two issues you have using queues are:

1. All messaging must be OneWay so if the client needs to have a way of knowing if processing was successful you have to design that into your solution
2. Queue failure semantics are very different from standard service failures. Dead letter queues and poison message queues need to be checked for unprocessed messages – again something you need to design into your solution