On Fri, 2007-06-01 at 09:51 +0100, John O'Hara wrote: > The trouble with makeing a JMS-look-alike API is that the JMS specification > specifically licenses the technology "only for Java" or something like that. > > As part of keeping things clean, we really shouldn't be implementing a > JMS-alike API on Qpid; unless Apache is a Sun JMS licensee in some > capacity. So without advice from Cliff, I would say do something different.
NMS is an Apache API that looks like JMS, I was not suggesting that we define NMS but that we implement it. As NMS is already an Apache project I don't expect any legal issues. > > We also know that an API closer to AMQP constructs will be more efficient, > and since people are likely to ultimately access the API through WCF on the > .NET platform, this would make for a more efficient mapping: > > BizTalk -> WCF -> ".NET AMQP API" I think that the bottleneck is more on the wire level and I therefor do not expect that adding one level of abstraction would impact on performances. > Finally, there will be some work done to standardise the "shape" of the API > across languages/implementations later this year. That API is likely to > look AMQP'ish, not JMS like. This is certainly a good thing to do. However, currently NMS is an Apache API that is integrated with Spring .Net that a lot of people also use in conjunction with WCF. I would say that NMS support will be done on top of the AMQP'ish interface. It has two main advantages: 1) provides .Net programmer with a know interface 2) Allows AMAP to be plugged within Spring .Net 3) Increase reuse of WCF and BizTalk components 4) We can drop support when the AMQP'ish API is widely adopted Arnaud
