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 15:14:30 GMT
Looking at the WCF specifications, I think there is a lot of value in doing
a WCF -> AMQP-midlevel - > Framing implementation.

WCF has a lot of nice toys that C# developers will want to use.  They'll not
be going near a JMS style API if they can help it at all.

Looking at WCF, the more important thing is to make sure we have a good
end-to-end experience from XML or binary XML between Java/C# using Qpid
drivers.

John


On 01/06/07, John O'Hara <john.r.ohara@gmail.com> wrote:
>
> Legal issues are troublesome for end users; it's the end users who get
> told to cease and desist!
>
> Also, I +1 Rob on the WCF front; it's WCF that Windows users will be
> using.  They won't care about JMS at all.  NMS only exists because JMS has
> no wire level transport....
> It would be a mistake to say Spring are the same project on Java and .NET;
>
>
> We should target WCF as our user visible API on .NET.  There will be WCF
> drivers for all major middleware products and 3rd party technologies will be
> plugging into WCF - not NMS.
>
> How we implement WCF then matters less; but NMS is unlikely to be the
> optimal way.
>
> Cheers
> John
>
>
> On 01/06/07, Arnaud Simon < asimon@redhat.com> wrote:
> >
> > On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote:
> > > On 01/06/07, Arnaud Simon <asimon@redhat.com> wrote:
> > >
> > > > As I said, we would not define the NMS API as we do not change the
> > JMS
> > > > API. We would only implement it.
> > >
> > > But we do currently extend JMS, through the use of eg
> > > org.apache.qpid.jms.Session extends javax.jms.Session.
> >
> > We can extend it but the API itself is not changed.
> >
> > > > I don think that implementing NMS would impact upon interop. An I
> > agree
> > > > with you that having an API isn't enough but again I am suggesting
> > that
> > > > we define it but that we implement it. Moreover this code should not
> > > > even be hosted by our project but rather on the NMS Apache project.
> > >
> > > But to implement it we need a clear understanding of the precise
> > > semantics. If they are defined to be "exactly the same as JMS" (which
> > > itself is open to interpretation in a few areas!) then that is a start
> >
> > > I suppose notwithstanding the legal issues with that.
> >
> > I suppose that the NMS project would have to worry about legal issues.
> >
> > > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions
> >
> > > can they be exposed elegantly with that model?
> >
> > I know a person that already has a WCF channel based on NMS. We would
> > therefor be able to reuse it without any change. We would also gain
> > being compatible with spring .Net.
> >
> > Again, I see a NMS implementation as a way of speeding up AMQP adoption
> > within the .Net community. We will have a WCF channel and a BizTalk
> > adapter, NMS is just an additional advantage for people that don't want
> > to deal with the cumbersome BizTalk.
> >
> > Arnaud
> >
> >
> >
>

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