On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > On 8/21/07, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > > > On 21/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > > > > 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. > > > > But if AMQP provided an API you could move between AMQP implementations. > > > As I said I doubt AMQP will ever provide language specific API. > It shouldn't make the same mistake CORBA did. > Besides Rupert and you keep reminding me that Java "already" has a messaging > API :)
But not one that allows access to AMQP functionality. I don't see why the AMQP WG couldn't provide a set of Interfaces and a client lib could then implement jmx.Session and amqp.Session. Then again I've never had any exposure to CORBA to know what they did wrong. Is the lesson simply never to provide an API? That seems a bit harsh. > > 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. > > > > And on the branch but AFAICS there isn't a way to be notified of every > > 'idle ping', which is what the applications wanted to do. I'm making > > no comments about the reasoning behind this simply pointing out that > > clients want access to the events on the client and when they can't > > get it they re-implement it. > > > With the restructure you can easily hook into events if you need to. > In general an app shouldn't bother with low level pings and should only > care/know about when the connection is lost. > Without knowing the specifics of your use case I can't comment either - > however I understand the need for you to be silent on the issue. I don't know the specifics of the use case either. I agree with you that the client shouldn't care about ping-ing and should just watch for the connection being lost but users sometimes can't be told. They want to write their app the way they want to and given the protocol does what they want it seemed to make sense to be able to provide the hooks. > > 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(....) > > > > Ideally you would cast to an AMQP interface that is moving towards a > > standard provided by the AMQP WG. > > > Qpid Session API aims to be this interface from Qpid. > Come 0-11, people who code against this API may only see minimal changes. > > > If you do that, then what is the purpose of using JMS? I might as well > > code > > > to AMQSession class. > > > > If it is an interface then you may very well do that, as your > > application evolves. > > > > > 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. > > > > That may be true but there are no guarantees offered by the WG until 1.0 > > > Well given the way things are going right now, I feel there want be any > radical changes. > I agree that there are no garuntees though. > > > 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. > > > > I think this would be a mistake. AMQP is positioning itself as a > > vendor independent messaging protocol. Attempting to commoditise > > messaging so that one solution can be swapped for another. This > > requires interoperability, for which I'm sure an official protocol > > test will come from the WG at some point. > > > It will provide a TCK. > > However, I would be surprised if we got to the state where vendors only > > provided the > > broker and if we can't swap clients as well as brokers then clients > > will still end up with a client code lock in unless there is a > > standard AMQP API which we can write our code to and compile clients > > against. > > > If you use pure JMS, then atleast in the java world you can swap client > libraries - but there is no point. > Even JMS was intended to abstract brokers not client libs as there was no > wire protocol defined. > Usually people want to switch brokers, bcos thats where the performance and > reliability lies. > > If people provide a thin 1:1 mapping of the protocol as a client lib, it > doesn't really matter at all. > Switching a client lib like that will give no performance benifit at all. > Broker is what matters. Unless of course the license from the vendor for the client libs only comes with the broker. I would just like to be able to pick an choose. That said I'd still 'pick' qpid but who knows what the future holds. Until AMQP more fully supports JMS functionality then I think the client libs will make a big difference. Just look at selectors as one example. As it isn't in the spec you can either adjust the protocol, (though acceptable extension points) getting vendor lock in but putting processing on broker. Or filter on the client but take the hit in sending all messages to the client to be rejected and reprocessed by the broker. > > 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 > > > > > > > > > > > > > -- > > Martin Ritchie > > > -- Martin Ritchie
