Rupert, I still think I haven't done a good job explaining. I also think that once you get familliar with 0-10 protocol you will also understand it better. Instead of answering your questions directly I will put forward a summary. Please read it carefully before answering. Also reading just the 0-10 xml will not help, you need to read the proposal on the AMQP wiki to understand subtle points. I highly recomend reading the new message proposal and others.
The API exposes every AMQP protocol method except for connection negotiation and failover. So it's a very close 1:1 map of the protocol. I have listed the methods in the API and highlighted the significance brieftly. You can decide for yourself after comparing with JMS and reading the protocol specs/proposals. Message Receiving ------------------------------- messageSubscribe - pay attention to the acquire mode and confirm mode - very useful messageFlow and Stop - credit based flow control messageRelease and messageAcquire - ownership of messages messageFlush - asking the broker to exaust the credit and send messages immediately if available executionComplete for transfer method - acking the message (messageAcknowledge) messageReject - rejecting the message. messageAcquired - the broker notifying u what messages were given to u. The protocl will send the messages in the following sequence. (Segment is a collection of frames) messageTransfer, Header Segment, Body Segments. Hence it naturally maps to message part listener. messageTransfer(commandId) headers(Struct[] ...) data(ByteBuffer) - This will be called each time a frame arrives end () will be called after the last frame of the last segment is received. Everything else like the MessageListener is just sugar - not part of the core API. MessageSending ------------------------------------ As I explained above sending is the same aequence, messageTransfer , headers(Struct[] ), one or more data(ByteBuffer) , end(). messageReject () - notifies u when a message is rejected Everything else like messageStream or messageTransfer with message as an argument is just suger - not part of the core API. ExecutionLayer ------------------------- sync() - Very very useful - it notifies when a particular method has been executed. In other words executionComplete has arrived. You can think of them as synchronization points. You can do things like. queueDeclare(A) queueDeclare(B) sync() messageTransfer (A) messageTransfer(B) sync() The Rest of the API is obvious 1:1 mapping of Exchange,Queue and Session methods. Rupert, what do u think? Does it still look like JMS? Can u point out which protocol method is not exposed? Regards, Rajith On 8/20/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > > > > > > > > >
