Re: [Java] Message API design notes

Good point! I will - with a smile - refrain from commenting further on MS and their insights. Enjoy :-) Michael Den 23/08/2007 kl. 12.10 skrev Rupert Smith: But hold on. We already agree that such an API should look 1:1 like the protocol. Its not as if the API, even if implemented as a

Re: [Java] Message API design notes

But hold on. We already agree that such an API should look 1:1 like the protocol. Its not as if the API, even if implemented as a blind-fold experiment, by different groups with no contact, in different languages, is going to look radically different. The protocol XML itself is already the language

Re: [Java] Message API design notes

Den 23/08/2007 kl. 11.27 skrev Robert Greig: On 23/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: One thing that seems to have come up a few times, is the idea that it would be hard to have the same API across different languages. I don't think it would be technically hard to do this. Ye

Re: [Java] Message API design notes

On 23/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > One thing that seems to have come up a few times, is the idea that it would > be hard to have the same API across different languages. I don't think it > would be technically hard to do this. Yes, plus it's practically hard given other factor

Re: [Java] Message API design notes

On 23/08/07, Gordon Sim <[EMAIL PROTECTED]> wrote: > I think it would be premature to start trying to standardise. The java > world is not (in my opinion) looking for a standardised messaging API; > that role is currently fulfilled by JMS. Yes, exactly. One other point that I would add is that my

Re: [Java] Message API design notes

One thing that seems to have come up a few times, is the idea that it would be hard to have the same API across different languages. I don't think it would be technically hard to do this. If we assume OO as a base line, and define the API as a class diagram in UML (1:1 the protocol, of course), the

Re: [Java] Message API design notes

Michael Arnoldus wrote: From my point of view it's very cool to stop the standards at the wire level protocol. That means several java API's can coexist, and people can use several brokers. Freedom increases. I very much share this view. The API is in my view one of the distinguishing featu

Re: JMS extentions (was [Java] Message API design notes)

On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > However for JMS users, they can cast down to the native Qpid Interface and > use AMQP features. > (This is something I initially disagreed, but I understand that this may > provide a more gradual migration path) I should point out that on

Re: [Java] Message API design notes

On 8/22/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > On 22/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > > I do not particularly see the need for an API which is neither JMS that > > doesn't look exactly like the model layers of AMQP [that is the API need > not > > expose all the 0-10 fea

Re: [Java] Message API design notes

> > I do not particularly see the need for an API which is neither JMS that > doesn't look exactly like the model layers of AMQP [that is the API need > not > expose all the 0-10 features for connection establishment, session > maintenance etc... those are functions of the client library and should

Re: [Java] Message API design notes

On 22/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > I do not particularly see the need for an API which is neither JMS that > doesn't look exactly like the model layers of AMQP [that is the API need not > expose all the 0-10 features for connection establishment, session > maintenance etc...

Re: [Java] Message API design notes

Robert Godfrey wrote: On 22/08/07, *Carl Trieloff* <[EMAIL PROTECTED] > wrote: Robert Godfrey wrote: > My view... > > In any sane development environment people who code in Java are going to > want to code against JMS. My view is...

Re: [Java] Message API design notes

Den 22/08/2007 kl. 20.11 skrev Martin Ritchie: On 22/08/07, Michael Arnoldus <[EMAIL PROTECTED]> wrote: Den 22/08/2007 kl. 19.08 skrev Martin Ritchie: On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: But not one that allows access to AMQP functionality. I don't see why the AMQP WG

Re: [Java] Message API design notes

On 22/08/07, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > Robert Godfrey wrote: > > My view... > > > > In any sane development environment people who code in Java are going to > > want to code against JMS. > > My view is... > > Same as Robs for App development guys, they will most likely use JMS. >

Re: [Java] Message API design notes

Robert Godfrey wrote: My view... In any sane development environment people who code in Java are going to want to code against JMS. My view is... Same as Robs for App development guys, they will most likely use JMS. For people that are building services of infrastructure on top of us will

Re: [Java] Message API design notes

My view... In any sane development environment people who code in Java are going to want to code against JMS. That is THE standard for Java Messaging. What we want to be able to do is allow these people to progress to use features that are in AMQP but cannot be exposed purely through a JMS imple

Re: [Java] Message API design notes

On 22/08/07, Michael Arnoldus <[EMAIL PROTECTED]> wrote: > Den 22/08/2007 kl. 19.08 skrev Martin Ritchie: > > > On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > >>> > >>> But not one that allows access to AMQP functionality. I don't see > >>> why > >>> the AMQP WG couldn't provide a set o

Re: [Java] Message API design notes

Den 22/08/2007 kl. 19.08 skrev Martin Ritchie: On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: 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.

Re: [Java] Message API design notes

On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > 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 expos

Re: [Java] Message API design notes

On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > 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 expos

Re: [Java] Message API design notes

> > 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 ne

Re: [Java] Message API design notes

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

Re: JMS extentions (was [Java] Message API design notes)

Two remarks: - We must provide JMS support for portability purpose and ease of migrating messaging applications onto AMQP. The benefit of developing pure JMS AMQP based applications are: - interoperability with all AMQP brokers (no vendor lock-in) - as with standard JMS, provider

Re: JMS extentions (was [Java] Message API design notes)

No the record was some 80 odd emails, when discussed the API thing last time :) Rajith On 8/22/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > I strongly oppose it to be the official way to use AMQP. > > > I agree with you here. I w

Re: JMS extentions (was [Java] Message API design notes)

On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > I strongly oppose it to be the official way to use AMQP. I agree with you here. I would like to see a Qpid API, that is 1:1 the protocol, and wrt language conventions, the same across all our target languages, that does not look like JM

Re: [Java] Message API design notes

Should just have done that the first time round! Here it is: http://cwiki.apache.org/confluence/display/qpid/Low-Level+API+Diagram Rupert On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > Rupert, > > I think the zip got filtered out. > Howe about attaching it to the wiki and sending a

JMS extentions (was [Java] Message API design notes)

Folks, I started a new thread on this topic as I felt it deserves some attention. And for me atleast I got some facts relating the JMS extensions confused while engaged in the client API debate. Here is my thinking about JMS extensions.

Re: [Java] Message API design notes

Rupert, I think the zip got filtered out. Howe about attaching it to the wiki and sending a link. Rajith On 8/22/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > There is a subtle difference between the structure I have described, that > is > dimensions 1 + 2, versus the comm layer + proposed cl

Re: [Java] Message API design notes

Dentoing both subchannel and layer in the XML will be done... we've started talking about this issue now in the AMQP 0-10 group... hopefully the xml will soon be updated with this information. -- Rob On 22/08/07, Alan Conway <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-08-21 at 14:44 -0400, Carl

Re: [Java] Message API design notes

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

Re: [Java] Message API design notes

On Tue, 2007-08-21 at 14:44 -0400, Carl Trieloff wrote: > > Is it the case that every method belongs to one of these layers? > > > I would expect so. Yes. The layering is described in the spec text and in various JIRAs. > > In which case, will the layer numbers be put into the 0-10 xml? > > >

Re: [Java] Message API design notes

There is a subtle difference between the structure I have described, that is dimensions 1 + 2, versus the comm layer + proposed client API as a layered system. As two separate dimensions, a client application would be coded against both. It would use dimension 1 to invoke the protocol directly as

Re: [Java] Message API design notes

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 > > eff

Re: [Java] Message API design notes

Is it the case that every method belongs to one of these layers? I would expect so. In which case, will the layer numbers be put into the 0-10 xml? No idea, or a least I don't know of any vote to do so. However the channels in 0-10 should be enough to derive this, so I don't think we n

Re: [Java] Message API design notes

> > 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 > Q

Re: [Java] Message API design notes

Yes I believe the Qpid API sits above the API you talk about. And I would like that to be the API we promote to users as a client. What you are essentially talking about is a slightly different approach to how the comm layer should expose it self. We need that API for sanity and design purposes. E

Re: [Java] Message API design notes

Yes, but my proposal differs slightly, in that it uses interfaces, not concrete classes, and splits server and client chassis up. Other than that, yes, the comm layer seems to fit the bill perfectly. No surprise, given that I started with Rafeal's stub and pulled an interface only API out of it. O

Re: [Java] Message API design notes

On 8/21/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > On 21/08/07, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > > > Watching the debate, I think you guys are actually quite close to each > > other. > > > Yes, as I say, we are to some extent talking at cross purposes. I'm > primarily coming from t

Re: [Java] Message API design notes

On 21/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > 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, bu

Re: [Java] Message API design notes

On 21/08/07, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > Watching the debate, I think you guys are actually quite close to each > other. Yes, as I say, we are to some extent talking at cross purposes. I'm primarily coming from the point of view of modularizing, and allowing multiple implementati

Re: [Java] Message API design notes

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 si

Re: [Java] Message API design notes

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 messa

Re: [Java] Message API design notes

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 ou

Re: [Java] Message API design notes

> > > I find it strange though because it is like JMS in a parallel universe: > > JMS Qpid > ConnectionConnection > Session Session > MessageListenerMessageListener > ExceptionListener ExceptionListener > MessageMessage > BytesM

Re: [Java] Message API design notes

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-

Re: [Java] Message API design notes

-- > From: Rupert Smith <[EMAIL PROTECTED]> > Date: 20-Aug-2007 16:23 > Subject: Re: [Java] Message API design notes > To: [EMAIL PROTECTED] > > I find it strange though because it is like JMS in a parallel universe: > > JMS Q

Fwd: [Java] Message API design notes

-- Forwarded message -- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 16:23 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED] I find it strange though because it is like JMS in a parallel universe: JMS Qpid Conn

Fwd: [Java] Message API design notes

-- Forwarded message -- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 15:54 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED] On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > So today the current API could be seen

Fwd: [Java] Message API design notes

-- Forwarded message -- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 15:09 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED] But what I am proposing has already been compared with that proposal, because Rajith said that his proposal was 1:1 pr

Fwd: [Java] Message API design notes

-- Forwarded message -- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 14:48 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED] Yes, I was not sure which way round to put the names either. In the end I decided to do it by what you are calling, rathe

Re: [Java] Message API design notes

On Mon, 2007-08-20 at 14:41 +0100, Rupert Smith wrote: > > Exposing the entire AMQP protocol 1:1 does seem like overkill from the > point of view of writing applications against, since in the vast > majority of cases it is just create connection, create session, send > messages (in which case use

Re: [Java] Message API design notes

On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > 3. Use of the inverse symmetry of the API so that the outgoing interface > > that the client calls, is identical to the incoming interface that the > > broker routing layer implements. > > This is a requirement for the common layer and I th

Re: [Java] Message API design notes

On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > 2. Full mapping of the protocol 1:1 onto the API. > > This is again a debatable criteria. I personally think that some > convenient features like providing support for connection negotiation > would be very helpful. This does not mean that t

Re: [Java] Message API design notes

On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > 1. Methods as classes, rather than exposed arguments. > > This is debatable indeed. I am not sure that the performance should > disfavor usability and ease of programming. > Ok, but there is a very easy way out of that one. In my API I h

Re: [Java] Message API design notes

On Mon, 2007-08-20 at 13:19 +0100, Rupert Smith wrote: > On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > I like what Rupert is proposing but it may be too low level. > Rupert you > are saying that the current API does not expose the AMQP ping > mechanism. >

Re: [Java] Message API design notes

On 20/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > So is this what the example, 'Option3', is describing? Is it a streamed > messages split into chunks? And we are doing streaming through the 'message > class' now? I think this should be described as chunking not streaming, since that is all

Re: [Java] Message API design notes

On Mon, 2007-08-20 at 12:09 +0100, Rupert Smith wrote: > Onto some ideas about low-level API, what I had imagined such a thing would > look like. I've been hacking this around on my laptop, but without internet > access for it (or time to rebuild my kernel with WiFi support ;-), should > get hooked

Re: [Java] Message API design notes

And I do agree, there needs to be a slightly higher level client API, to make this very low-level direct protocol API usable to code against. In Java I believe that it is JMS + horizontal extensions, in other languages, something similar wrt JMS licensing issues, or better if you come up with a nic

Re: [Java] Message API design notes

On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > I like what Rupert is proposing but it may be too low level. Rupert you > are saying that the current API does not expose the AMQP ping mechanism. > Is that all? Can you provide an exhaustive list of the AMQP features > that are not exposed? >

Re: [Java] Message API design notes

On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-20 at 10:42 +0100, Rupert Smith wrote: > > //Option3 - can use it with any message size, recomended for large > messages > > public void messageTransfer(String destination, short confirmMode, > > short acquireMode); > > public

Re: [Java] Message API design notes

On Mon, 2007-08-20 at 10:42 +0100, Rupert Smith wrote: > //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);

Re: [Java] Message API design notes

And public interface ProtocolBroker extends ClassMethodBroker, ClassSessionBroker, ClassExecutionBroker, ... should be public interface ProtocolBroker extends ClassMessageBroker, ClassSessionBroker, ClassExecutionBroker, ... On 20/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Typo: > > pub

Re: [Java] Message API design notes

Typo: public interface ClassSessionAttached { public void sessionAttached(SessionContext context, MethodSessionAttached attached); ... } should be: public interface ClassSessionClient { public void sessionAttached(SessionContext context, MethodSessionAttached attached); ... } On 20/

Re: [Java] Message API design notes

Onto some ideas about low-level API, what I had imagined such a thing would look like. I've been hacking this around on my laptop, but without internet access for it (or time to rebuild my kernel with WiFi support ;-), should get hooked up at home again on thursday), I will just have to give an out

Re: [Java] Message API design notes

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 propose

Re: [Java] Message API design notes

> > > 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

Re: [Java] Message API design notes

Ok, but I have some tests to run and write up, so maybe not till tomorow afternoon or monday. On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > My comments are more directed at: > > http://cwiki.apache.org/confluence/display/qpid/Message+API+Design, > which > > I > > don't feel is

Re: [Java] Message API design notes

> > My comments are more directed at: > http://cwiki.apache.org/confluence/display/qpid/Message+API+Design, which > I > don't feel is really the low-level protocol 1:1 API. As I pointed out in the previous emails. The API expose everything except for the connection negotiation and failover. And

Re: [Java] Message API design notes

I think saying that sping/hibernate/tomcat disproved EJB is nearer the mark. I think spring/hibernate sold themselves on their intuitive API's. 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 sur

Re: [Java] Message API design notes

Yes, the current common layer, the stuff Rafael has been working on, looks very good to me. As I say, all I have really done is to split the invoker/delegate concept up into methods that client can call vs methods that broker can call, and to expose everything through interfaces rather than as conc

Re: [Java] Message API design notes

> > > > 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 use

Re: [Java] Message API design notes

On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > gets up to such tricks. There is also an out-of-date project, > > http://www.eecs.harvard.edu/~mdw/proj/old/jaguar/, that does this sort > of > > thing too, no idea but maybe the Terracotta folks got some ideas from > > there. > > > [RA

Re: [Java] Message API design notes

On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > Rupert, > > first of all thank you for talking the time to go through and comment. > Let me try answering the first 4 questions. > > On 8/16/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > Hi, I have tried putting a case forward for t

Re: [Java] Message API design notes

Hi, It looks to me that the solution you are describing is very similar to the current common layer (I am not speaking about the API described @ http://cwiki.apache.org/confluence/display/qpid/Message+API+Design). I would help (me at least) if you can highlight the main differences between the tw

Re: [Java] Message API design notes

Rupert, first of all thank you for talking the time to go through and comment. Let me try answering the first 4 questions. On 8/16/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Hi, I have tried putting a case forward for three things. > > 1. Methods as classes, rather than exposed arguments.

Re: [Java] Message API design notes

Hi, I have tried putting a case forward for three things. 1. Methods as classes, rather than exposed arguments. Reason: Methods created by factories, allowing multi-version support (although Raphael points out that if the args change significantly then the protocol is changing too much between ve

[Java] Message API design notes

folks, I have captured the design notes for the new client API at http://cwiki.apache.org/confluence/display/qpid/Message+API+Design This is to give a heads up on the direction we are talking. I believe this is extremely close to the ideas we agreed on the dev list. Regards, Rajith