> My impression has been that WCF is purely an RPC abstraction. Does it > offer traditional messaging semantics as well?
Yes. For example, the Microsoft "StockTrader" sample application uses WCF and MSMQ to provide the same functionality as IBM's "Trade" sample application using JMS over IBM's Service Integration Bus - i.e. distributed transactions over durable message queues. A properly coded WCF application can switch its underlying messaging channel stack just by changing a configuration file, in the same way a Java application can switch JMS providers without code changes. Cliff -----Original Message----- From: Aidan Skinner [mailto:[email protected]] Sent: Thursday, January 08, 2009 2:35 PM To: [email protected] Subject: Re: Qpid .NET Strategy - Interested ? On Thu, Jan 8, 2009 at 8:39 PM, Robert Greig <[email protected]> wrote: > 2009/1/8 Aidan Skinner <[email protected]>: > >> I think System.Messaging is probably more relevant to .Net, this is >> the route that Mono has gone down with ActiveMQ and RabbitMQ: >> http://www.mono-project.com/SystemMessaging (there was also an attempt >> to implement it on top of our 0-8 client but that didn't work out). > > My experience has been that WCF is key for new .NET development. I > have recently worked on a project that used WCF with IBM MQ, along > with CXF (this was using SOAP over messaging). > > That's not to say System.Messaging is not desirable, but the WCF for > IBM MQ saved us a lot of time and effort. My impression has been that WCF is purely an RPC abstraction. Does it offer traditional messaging semantics as well? Having said that, I've never done any async messaging with .Net, just synchronous SOAP-over-HTTP. I also guess it's arguable that RPC semantics are what most people actually want with messaging, even if they haven't quite figured it out. ;) - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org
