On Fri, Jan 30, 2009 at 6:11 AM, David Ingham <david.ing...@microsoft.com> wrote:
> Carl's right, we have been investigating the idea of layering a WCF channel > implementation on top of the C++ client library. That is, the managed code > channel implementation would pinvoke down to the native C++ code. This is the > approach that we used for the MSMQ channel that ships in the .NET framework > today and it works pretty well. We're drawn to this approach primarily > because of the maturity of the C++ code base. The pure .NET approach clearly > has merit too; one of the key advantages being that it offers the potential > to factor the code in a way that's more in line with WCF best practice, i.e., > as a set of layered channels rather than as a monolithic block. Doing it on top of the C++ client has two current disadvantages over the Java client that I can see: not 100% managed code only supports 0-10 Not having all managed code reduces portability (since you're now limited to the platforms that the C++ client supports) and limits the security profiles that the client will run under. Only supporting 0-10 means it won't talk to the current Java broker or any of the other AMQP implementations such as OpenAMQ or RabbitMQ. Related to this, it seems likely that the Java client will support AMQP 1-0 before the C++ client does, if only because the Java client already supports multiple protocols. On an unrelated note, what do you mean by the "the maturity of the C++ code base"? What about that client made it a better choice from your PoV than the Java client? - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
