Rupert, I think you need to get yourself familiar with the 0-10 protocol before we continue the discussion. Most of your comments stem from lack of understanding of the 0-10 spec. I am not fully aware of all the details either, but u need atleast a resonable knowledge to discuss.
I left out message.qos bcos it's going to be dropped from 0-10. So is session.ping and session.pong Can you please list any other method? Session.ack has nothing do with with messsageAcknowledgment. It's for execution layer functionality. >Cover the entire protocol, both client and server chassis, as a 100% literal This is not a useful excerisie at all (for a client API). 0-10 defines 4-5 layers (depending on whom you talk to:) ). L1 - Transport L2 - Session L3 - Execution L4 - Model Methods defined in the XML corresponds to each of these layers. For an API it would be usefull only to expose L4 in 100% and certain method in the other layers. Some of the methods like in the session layer are for frame replay etc - absolutely no point in exposing them in a client API. In summary there is little value in exposing a raw set of methods. You need a thorough knowledge in AMQP to work at that level. I doubt our user base wants to write their own client impl. Do u think otherwise? Do you have users asking for that? What they need (based on the feedback received so far) is a usable client that can work at AMQP level (in addition to our JMS impl) >Follow a protocol methods-as-events model, with ability to register listen to any incoming event. You could already do this with the comm layer. This would only be done by somebody who has a good knowledge on AMQP. Please don't confuse this with the client API. Our main goal is to provide a client not a toolkit for people to build their own client implementation. However we also allow the flexibility to achieve the latter option. >With no risk of running into JMS licensing issues? This is a red herring and a very weak argument. There is always a risk. The entire AMQP protocol runs the risk, not just the Qpid java impl. >Here is a summary of how I picture things at the moment: >Orthogonal dimension 1: [..] This is the comm layer Orthogonal dimension 2: [..] This is the Qpid API So what is the disagreement here? Horizontal extentions for JMS --------------------------------------------- Why do we need this when we have your "Orthogonal dimension 2:" ? Why not use JMS for what it is intended for? Many folks that I spoke to thought of it as an akward way of exposing AMQP. Most of them liked a Qpid Java client. Besdies JMS (or any standard API) discourage vendor specific extentions. IMO encouraging people to use JMS extentions defeats the very purpose of JMS. Your case for JMS extentions based on feedback from users ? what is your basis? Do you think you can provide first class representations of AMQP concepts using JMS extentions? - I gave concreate examples where you cannot do so. Regards, Rajith On 8/21/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Thanks for private mails, I'd prefer to discuss on the list, that way we > can > all contribute and learn something. I think good ideas stand up to > scrutiny > and are best shared. I've nothing to hide, and I put my ideas out as ideas > without being afraid of being wrong. By sharing my ideas I will find out; > I > will also learn something and develop better ideas. > > Thanks for your explanation, and yes, you are right that I do need to > spend > more time reading the 0-10 specs. > > I think my confusion over your proposed API largely stems from the fact > that > we seemed to be in agreement some months ago that the common API for Qpid > should be 1:1 the protocol. Which I have interpreted as meaning literally > the protocol 'classes' and 'methods' directly represented in the code. I > thought that was a very orthogonal approach, in that it guarantees that > the > protocol commands in their entirety are there to code against, completely > taking care of one dimension of the design. > > I shall give a few concrete examples of protocol 'methods' that I cannot > see > in your API, as this is what you have asked me for. Picked at random, and > not a complete list, simply to prove the point that not everything is > there: > > session.ping > session.closed > message.qos > ... (there are more, its simply a case of comparing your API to the XML) > > So can I write a client against your API that is capable of attaching a > listener delegate to be informed of the session.closed event? Whether or > not > being able to do so is useful is, I admit, debatable. The JMS impl on top > of > this API will want to know that session.closed has been received, however. > > Also, there are some naming inconsistencies between your API and AMQP, for > example you have 'messageAcknowledege' in your Session interface, whereas > in > the protocol XML it is session.ack. Not hugely important, its just if > something is 1:1 I expected that the names would map 1:1 in a mechanical > fashion? I think that is what I was expecting to see, a completely > inclusive, literal, 1:1, transliteration of the entire set of protocol > 'methods' into an API, both for the client and server chassis. > > For example, instead of a MessageListener, I was kind of expecting there > to > be a 'delegate' or listener interface for the entire set of incoming > protocol 'methods' that a client can be sent by a broker. Possibly for no > better reason than the ideas of orthogonality and completeness that I am > always on the look out for in a design. > > After reading your explanation I realise that your messaging API does > stuff > that JMS does not. For example, in JMS if I want to send some messages and > get confirmation that my messages have really been received by the broker, > I > must use a transaction. Which in turn means that none of my messages can > be > delivered until the commit. In the 0-10 protocol, I can do a sync, like > you > describe, to get confirmation, but the messages can already have continued > on their way before then? Keep me right 0-10 experts. This certainly > sounds > more asynchronous. It certainly sounds necessary, for client applications > to > be able to code against these 0-10 concepts, that are not available in > JMS, > in order to take full advantage of its capabilities. > > We are to some extend talking at cross purposes, because I have identified > a > set of interfaces, that covers the entire protocol, largely with a view to > creating a modular design, and with some possible implementation > efficiency > benefits that I think could be derived from the method-as-class model. > This > is what the existing comm layer does, I just pulled out the interfaces, > splitting up the client and server chassis, that's all. This is already > approximately what you are placing your client layer on top of. > > You say you are opposed to horizontal extension of JMS in general, (hope > you > don't mind me quoting from a private mail here?): > > > I totally oppose horizontal extentions to JMS as it does not provide > first > class representation for AMQP concepts. > > So your API must duplicate some parts of JMS (as any messaging API would > have to). Just as I am constantly on the look out for completeness and > orthogonality in a design, I am also always on the look out for designs > that > eliminate duplication. I would like to put out the idea, that this can be > represented as a JMS extension, simply by adding a sync() method into the > extended Session interface? So I could send a JMS message, then call sync? > Eventually, of course, weaving things into existing API's starts to become > too cludgy, so I think there are definitely trade-offs to consider in > these > design choices. I think I am concerned that your replace rather than > extend > strategy means that the end user must entirely throw out JMS to use > advanced > AMQP features. The extend strategy is more of a gradual migration. JMS is > a > very good and highly successful API, which makes me reluctant to abandon > rather than try and extend it. > > One thing about the low-level API that I have proposed, is that it is > entirely different to JMS in its structure. It is based around the concept > of AMQP methods-as-events, with invokers and delegates for the whole > protocol. The 'session' and 'connection' concepts of JMS are merged into a > single interface (per client/server chassis), and you pass in your session > and connection context to call a method in the context of, as an explicit > argument: > > public void messageTransfer(SessionContext session, MethodMessageTransfer > mt); > > There is one non-intentional side effect of this approach, and that is > that > as this API is completely different to JMS, so it might be a good choice > across all languages, with no risk of running into JMS licensing issues? > > Here is a summary of how I picture things at the moment: > > Orthogonal dimension 1: > Defined as interfaces only. > Cover the entire protocol, both client and server chassis, as a 100% > literal > 1:1 transliteration. > Allow us to do methods-as-classes, with convenience methods for the > exposed > argument forms. > Follow a protocol methods-as-events model, with ability to register listen > to any incoming event. > > Orthogonal dimension 2: > Provide utility classes to handle the protocol interactions (connection > negotiate, execution synching, etc), on top of this. These will manage > session state. > > Then on top of that: > JMS + as many AMQP extensions as we can reasonably add to it. > > I believe that there is a way that 1+ 2 on their own can be presented as a > very usable cross-language, non-JMS API. > > Rupert > > On 20/08/07, Rajith Attapattu < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > I find it strange though because it is like JMS in a parallel > universe: > > > > > > JMS Qpid > > > Connection Connection > > > Session Session > > > MessageListener MessageListener > > > ExceptionListener ExceptionListener > > > Message Message > > > BytesMessage ByteBufferMessage > > > ? FileMessage (why in terms of files? could > be > > > > > more abstract in terms of InputStream?) > > > > > > > Quick clarification to go along with my other email. I am very very glad > > that u bought this up. > > Infact would have been extreamly happy if u stated this in your very > first > > > > email. > > > > Connection and Session are classes directly from AMQP - so no argument > > there. > > > > Message interface is a true reflection of the AMQP spec. Nothing to do > > with > > JMS. Note the distinction. > > AMQP defines different message properties, > > DeliveryProperties, ApplicationProperties ..and can extend. In 0-11 we > > might > > have MsgGroupProperties. > > read(), appendData() is obviously common to any message model. So > nothing > > to > > claim that it looks like JMS. > > > > The broker sends replies asynchronously and that includes errors too. > > ExceptionListener is a generic way of notifying errors asynchronously. > > It's nothing JMS specific. Do you agree? > > > > If u notice. > > MessageListener is just suger, not part of the core API. I am moving it > to > > the util package as u can only use it with the utility adapter class. > > > > BytesMessage is a utiility class that belongs to the implementation not > > the > > API. So why the fuss ? > > If u are not happy with the name u can implement the message API with > any > > name u want. > > I actually had an inline implementation for the message interface, only > > reason I moved it was to allow reuse for Arnaud. > > > > FileMessage : Another utility class - not part of the API. > > > > >>(why in terms of files? could be more abstract in terms of > InputStream? > > Did u look at the code or at the least read the java doc? > > I am using the FileChannel from nio to make use of the map function > which > > mapps regions of a file into memory. > > > > Does this explanation help u? > > > > Regards, > > > > Rajith > > >
