On 05/04/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
It is pretty important, I agree. In fact, writing a WCF transport channel as well as a BizTalk Server adapter was the reason I got interested in Qpid originally. It's just that the client was not quite in a state stable enough (imho) to use as the basis for them.
I think that's fair; also since the client was derived from a client that was intended really to support JMS it may not be a sensible structure for other types of client API.
So what I'm trying to do is improve the Qpid .NET client to a point where I could use it as the basis for the WCF and BizTalk adapters, and I think we've made some good progress here. Obviously, both would expose a fairly small subset of the entire AMQP functionality, as they are more concerned with simply sending and receiving messages than the rest, but it would still be a very compelling use case, I think.
I am a strong believer in the "extended JMS" approach for exposing other AMQP functionality within Java. (I think having a separate "AMQP Java" API is in fact counterproductive since it confuses users). JMS isn't very good in many respects but it is very widely used. I have not yet examined WCF in much detail but could a similar "extended WCF" approach be used? i.e. you can use vanilla WCF if you want but if you want to exploit AMQP-specific functionality you can do this with some casting.
I've been a bit busy lately so I haven't had the chance to work too much on this, though.
It's not clear yet but if the project I work on does go down the .NET route then I will probably have an incentive (and time) to work on this. RG
