Re: [.Net] NMS

[John O'Hara <jo...@gmail.com>]

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.

This is the relevant license, copied directly from the JMS Spec document:

"Subject to the terms and conditions of this license, Sun hereby grants you
a fully-paid, non-exclusive, non-transferable, worldwide, limited license
(without the right to sublicense) under Sun's intellectual property rights
to review the Specification internally solely for the purpose of designing
and developing your Java applets and applications intended to run on the
Java platform. Other than this limited license, you acquire no right, title
or interest in or to the Specification or any other Sun intellectual
property. The Specification contains the proprietary information of Sun and
may only be used in accordance with the license terms set forth herein. This
license will terminate immediately without notice from Sun if you fail to
comply with any provision of this license. Upon termination or expiration of
this license, you must
cease use of or destroy the Specification."


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"

We know that JMS as an API for messaging leaves some things to be desired.
We do it on Java because its what everyone expects and knows.  We shouldn't
carry JMS onto .NET without a really good reason, and some clear legal
advice.

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.

What do you think?
John


On 31/05/07, Tomas Restrepo <to...@devdeo.com> wrote:
>
> Arnaud,
>
> > When looking at the .Net client it came to me that we should look at
> > what the guys from ActiveMQ have done. They have created an Apache
> > project that defines a .Net Messaging API. The project name is NMS
> > for .Net Message System API which is an interface to messaging systems
> > rather like JMS is for Java (the project can found here:
> > http://activemq.apache.org/nms/what-is-nms.html )
> >
> > The main strengths of NMS are that it is already implemented (ActiveMQ,
> > STOMP and MSMQ) and integrated with Spring. Note that I know people
> > form
> > the industry that use NMS (especially the ActiveMQ implementation).
> >
> > The idea would be to first implement NMS and then use it to implement a
> > WCF channel or a BizTalk adapter. Thus, the way things would
> > look is:
> > WCF channel <------
> >                   ----- NMS implementation (C#) ---> Qpid broker
> > BizTalk adapter <--
> >
> > (We may have spring .Net in between the WCF channel and the BizTalk
> > adapter)
> >
> > One main advantage of going this way is that we would be able to reuse
> > existing WCF implementation done for ActiveMQ.
> >
> > It would be nice if the .Net guys (Carlos, Tomas, Marnie, etc.) can
> > comment on that. We may even decide to host our NMS implementation on
> > the NMS project.
>
> Thanks for the suggestion. I was not aware of this (indeed, I didn't even
> know ActiveMQ had a .NET implementation), and it certainly looks
> worthwhile.
>
> I'll spend some time over the weekend looking at this and I'll post my
> findings here.
>
>
> Tomas Restrepo
> http://www.winterdom.com/weblog/
>
>
>
>
>

Re: [.Net] NMS

[Arnaud Simon <as...@redhat.com>]

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