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 >
