On 6/1/07, John O'Hara <[EMAIL PROTECTED]> wrote:
Looking at the WCF specifications, I think there is a lot of value in doing a WCF -> AMQP-midlevel - > Framing implementation.
The route that I have taken for the re-factored java client is more or less the same. JMS --> AMQP client --> framing. If there is an established way of doing things in a particular language, then it's wise to follow that.(Ex JMS for java) It would be difficult to convince people to use a different API in java when there is JMS no matter what the short comings are. If WCF is what is established then it's wise to follow that route. However I have left the option for people who want do more than JMS and go haywire with AMQP the chance to do so. 1) They can use the more fine grained AMQP low level client to work at the protocol level classes 2) A more coarse grained AMQP client to work at a more high level. Even though both these clients have a clearly defined set of interfaces, I wouldn't call that an API. I'd rather introduce them as a framework (or a set of tools) for people who want more control of the AMQP messaging layer. There is already an interest from other projects in using this type of framework as opposed to using JMS. While end user will like to use JMS, other middleware related projects who wants AMQP support will prefer to use this type of framework to make things more fast and flexible). This is something I suggest that should be thought carefully when designing the .NET client as well. So designing a low level .NET AMQP client and on top WCF as our user visible API for .NET can satisfy both worlds. Regards, Rajith. 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > > > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> 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 > > > > > > >
