qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: [.Net] NMS
Date Fri, 01 Jun 2007 08:51:50 GMT
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

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?

On 31/05/07, Tomas Restrepo <tomas.restrepo@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/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message