> > This increasing usage comes with new requirements some of which native > AMQP > functionality can achieve. Should we require the client to re-write > their app using the Qpid API? I hope the answer is no, as the re-write > effort would most likely eliminate any potential saving in moving to > Qpid.
This is a tough question to answer. Depending on what is needed they may need to rewrite certain portions. Rewriting doesn't necessarily mean that you loose savings. After all which application can survive feature requests forever without having to go through modifications. My argument is that you can only expose simple AMQP functionality as JMS extensions. If they want to do more then it make sense to program at the AMQP level instead of JMS. Bcos once u do that then there is no advantage in sticking to JMS. You simply can't move to another JMS provider bcos your code is using AMQP extensions. You got to use the right tool for the right job. Hybrid tools will only take you so far. As concrete examples are good. Two recent applications that I've > assisted developing have both written code to send a ping message to > the broker to ensure the connection is up. I felt terrible telling > them that Qpid currently does that but sorry you can't hook in to the > callbacks. That is more due to poor design than anything else. Asking an application to do that is not the right thing. We should provide a connection exception listener which should notify the application with a proper error code that notifies when the connection is lost or when the broker terminates by calling close. In the event of connection lost it should try failover and only notify when it is unsuccessful. In fact you can do that using JMS exception listener too. The only thing the application needs to do is to interpret the error code properly. The client code in trunk does that. So I am very much in favour of JMS + AMQP extensions. I > don't really see any alternative. I can see why JMS would discourage > vendor extensions but don't forget we are not adding vendor specific > extensions; We are exposing AMQP functionality. As I said this is a poor effort in exposing AMQP functionality. There are certain functionality that you cannot expose that way. For example configuring the confirm mode and acquire mode for a transfer. Unless you cast it to the AMQ class and then use those methods. AMQSession ssn = (AMQSession)jmsSession; ssn.messageTransfer(....) If you do that, then what is the purpose of using JMS? I might as well code to AMQSession class. Anyone implementing > AMQP based applications need to be acutely aware that the protocol is > still at a beta level. Folks you want to do that will do with that explicit understanding. >From 0-10 onwards I doubt we will see drastic changes. When AMQP hits 1.0 and historic version > compatibility is required then use of these extensions should be less > risky than they are just now. This will be greatly assisted when AMQP > provide an API I doubt the AMQP spec group will ever provide an API. I don't see a need to do so. The semantic model already defines how a broker and client should interact. Not sure what more you can do. at which point it would be a Qpid-AMQP-API only > extension, it would be AMQP-API which we were exposing. The proposed Qpid API is a java version of the 1:1 mapping of the protocol for the client side (with a few exceptions + sugar). As Rupert points out the comm layer is 1:1 mapping of the protocol for both the client and the broker. > 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 > > > > > > > > > > > > -- > Martin Ritchie >
