qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Simon <asi...@redhat.com>
Subject Re: [.Net] NMS
Date Fri, 01 Jun 2007 09:19:25 GMT
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 



Mime
View raw message