Ok, sorry about the delay, I got the tests fixed up. First off, why I think the proposed API (http://people.apache.org/~rajith/qpid_docs/client_api/) offers almost nothing that JMS does not already cover. And then a second email about what my opinions/ideas about the low-level API are.
The proposed API, is primarily geared towards listening for messages, of course, combined with sending messages, the most important thing a messaging API is interested in providing. So you have a 'MessageListener', as does JMS. You also present a little example, of sending messages through a push driven streaming API: //Option3 - can use it with any message size, recomended for large messages public void messageTransfer(String destination, short confirmMode, short acquireMode); public void headers(Struct... headers); public void data(byte[] data); public void data(ByteBuffer buf); public void data(String str); public void endData(); as if this is an important innovation. But then JMS has the StreamMessage class, that provides this capability. There is a difference, and that is that in the example, the transfer comes before the appending of data, followed by an explicit end to terminate. Does this mean we are doing real streaming over the protocol 'message class'? Again, I am not clear on this, 0-8 had separate 'message' and 'stream' classes, does 'message' in 0-10 now covers streaming too? If so, then it looks to me like this would be a useful JMS API extension, that would sit side by side with the JMS implementation, rather than as a lower-level that sits beneath it. In a similar way to how the current 0-8 implementation provides horizontal extension of JMS for AMQP specific features. This proposed API lets me bind exchanges, about the only thing it offers that JMS does not already cover. I have looked at MessagePartListener, and it does not convince me that this API is a 1:1 mapping of the protocol. Looking inside the protocol XML, I am looking at every method in it, some are marked as: <chassis name="server" ... and some as <chassis name="client" ... and some as both of these. Now looking at the Session class, I certainly see a lot more of the 'server' chassis exposed, but not all of it. The only part of the protocol 'client' chassis I see exposed in this API is 'messageTransfer', and there is a lot more besides. Whilst I do agree that it is questionable whether or not we need to expose the full protocol as our low-level API, doing so would be undoubtedly low-level. As to the question of whether or not we should, we have had customers implementing their own heart beat pings, when there is a perfectly good ping/pong API in the protocol session 'class' that they could use. I do concede, that in the majority of cases, client code will not want to interact with the protocol so directly, being primarily interested in sending and receiving messages. But in that case they will use JMS. There seems to be a difference of opinion about what this so called low-level Qpid API is for. I see it as being a 1:1 mapping of the protocol, that JMS will be implemented on top of (and a similar or better client API in the other languages). All features of the protocol exposed for the convenience and symmetry of programming against. I see the low-level API as being mostly internal to Qpid, as an interface and abstraction that will help us to build the software in a cleanly modular fashion. Rajith, you keep arguing that you are inventing a new messaging API for Java, that people will somehow shift over to using as they defect from JMS. Comparing JMS to EJB's is an analogy that attempts to confer the faults of EJB onto JMS, but a weak argument; there was a lot wrong with EJB, hence people were all to keen to defect to the funky spring/hibernate model. What exactly is so wrong with JMS? Just as I have been asked to drop my argument that too much layering will slow things down, I think this JMS replacement argument should also be dropped. I'm for horizontal extension of JMS to provide AMQP specific features, not layering. Rupert On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > > > As for JMS, yes things can change, but personally, if I were trying out > a > > new an as yet unproved technology (Qpid), I would program to JMS, just > to > > be > > sure I keep my options open, so I could switch easily to a different JMS > > provider if need be. > > > The entire Qpid community is working towards making it a proven AMQP > implementation. > The AMQP spec group is working very hard to be the messaging protocol of > choice. > I have heard from users who are keen to take the risk and I have provided > who they are in my previous email. > I am willing to help people who put faith in AMQP and Qpid. > I like to think that we as a community will provide the best solution out > there. !!!!!! > > I think your API copies too much from JMS and is not > > low-level enough. The API that the comm layer exposes, gets it just > about > > right IMO. > > > > Can you please provide concrete examples of where it copies from the JMS?? > The message listener is not a JMS concept. It's been use before and will > be > used after JMS > > Rupert you are making vague comments and beating around the bush. > What low level AMQP method it doesn't expose? or where it fails to be low > level. (other than connection negotiation and failover) > You are yet to answer this question. > > On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > 1. Methods as classes, rather than exposed arguments. > > > > > > > > > > > > > > > [RA] On a general note, as an API user I like to use arguments > > rather > > > > than > > > > > classes. > > > > > I think that's what a majority of users would prefer as it looks > > more > > > > > natural. YMMV > > > > > > > > > > > > > > > > > Yes, but two points: > > > > > > > > Most users will use JMS, not the low-level API. The low-level is to > > > > implement JMS on top of, and to provide extra capabilities in some > > > > scenarioes. > > > > > > > > > [RA] Well as AMQP gets more popular people may want to use AMQP > > directly. > > > Rabbit already has a no JMS java client. > > > Synapse is interested in using AMQP without JMS > > > We already have a customer who doesn't care about JMS but a java > client. > > > > > > I am not discounting JMS. But let the users take what they want. > > > Nothing is forever. EJB proved that beyond dobut. > > > > > > Can provide the exposed argument forms as convenience methods on top > of > > > the > > > > method-as-class/factory style. > > > > > > > > > >
