On 9/20/06, John O'Hara <[EMAIL PROTECTED]> wrote:
On a different strand - there is also the fact that while JMS is obviously a very important API for the Java community it makes a lot less sense in other languages. It's not even a great API to talk to middleware with, which is why people using MQ series used the native Java binding for so long (and still do).
I don't think I can agree. I've used the native Java binding and it was a POS. But I HAD to use it. Why? Because I needed to talk to a MQ series c app and it was impossible to use IBM's JMS impl create the messages exactly has that native app expected them :( It is just a simple case of IBM having the market locked in.
So for C++, Python et al, why not do (dare I say this) a little bit better than JMS?
Sure this if fine. But the basic concepts in JMS are on solid ground. This is very similar to JDBC. It basically a clone of ODBC. Is this a bad thing? I don't think so. The basic concept is lets build an abstraction layer of that maps to most of the existing implementations.
A year ago, people would have called me a heretic for saying this, but look at those people over at Spring proposing better ways to access messaging. From what I hear there is a lot of agreement with the sentiment.
Are your referring to spring remoting?
I would assert that AMQP is cleaner than JMS; when we sort out the last
I don't think they can even be compared. AMQP is a wire protocol. JMS is abstract API to messaging. They are not even in the same category. I would say you can compare AMQP to STOMP or HTTP or ActiveMQ's Openwire, etc. etc. etc. But JMS would need to be compared to API like MQIC (MQ Series C API), or MSQM API, etc.
niggles in the exchange/queue/binding arrangement you will have a very nice abstraction of middleware. No one who have reviewed the spec dislikes that setup. Dare we surface it into the API?
Sure! Sounds great for yout QPID impl. I only bring up implementing a common abstract API for our messaging servers since API's are what lock users in. I think most user don't want their apps locked into any specific messaging technology or protocol. That is the MAIN reason JMS, JDBC, and even ODBC has been so popular. They avoid lock in. Right now there is no standard abstract messaging API in the c and c++ world like JMS. For databases, you can use ODBC... It would be nice if ActiveMQ and QPID could agree to both implement the same API.
I think yes - it makes a whole lot more sense to send a message to an exchange than to send it to a destination. And that's the way the internet and postal services work too (you can give your parcel to DHL or FedEx or whoever) and indeed stock exchanges. What you don't do is give your parcel directly to the destination address :-)
I think this is a new concept and it needs to be field tested before it becomes core to any abstract messaging api.
For Java there has to be JMS -- but why limit other languages?
I believe you build on the shoulders of giants. ODBC was proven, hence why sun created JDBC. JMS is proven.. should we not follow suit?
Cheers John On 21/09/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > On 9/20/06, Robert Greig <[EMAIL PROTECTED]> wrote: > > On 20/09/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > Remember that the specification != javadoc that is available. > > > > Yes, I realise that. Are you claiming that you have never read the JMS > > specification pdf? > > > > > > The issue of re-implementing the APIs is a completely separate > topic, > > > > related (I believe) to permitted uses described in the licence you > agreed > > > > to when you downloaded the JDK. > > > > > > > I think that the Geronimo JMS API that was developed at Apache we as > > > done just using the javadoc as the reference. > > > > OK, but in the Sun JDK licence it states: > > > > "D. Java Technology Restrictions. You may not create, > > modify, or change the behavior of, or authorize your > > licensees to create, modify, or change the behavior of, > > classes, interfaces, or subpackages that are in any way > > identified as "java", "javax", "sun" or similar > > convention as specified by Sun in any naming convention > > designation." > > > > I don't think we are doing anything of the above. We are not > specifying any of the C++ stuff as bing JMS.. We call it CMS. They > fall in a 'cms' namespace thus I don't think the above clause applies > since our stuff is in no way 'dentified as "java", "javax", "sun" or > similar convention as specified by Sun in any naming convention > designation." > > > I believe this is the issue that also affects people who might want to > > work on e.g. GNU Classpath. > > > > > So I think it would be VERY hard for sun > > > to argue that a C++ api for ActiveMQ in in violation of any copyrights > > > or licenses. > > > > I think they would only have to show that you have at some point read > > the JMS specification, and using Google I was able to find fairly > > compelling evidence that you have. > > > > For example, in your blog post of 21 June 2006 you state: "In some > > cases the JMS spec requires messages to be sent synchronously". And in > > a thread linked from the comments on that blog post you state: > > > > "I just reviewed the JMS 1.1 spec and section 4.10 seems like the most > > pertinent to this discussion." > > > > I'm not saying I never read it :) I'm saying that the folks that > created those APIs may not have read it. > > > In any event, I am only taking advice from our legal counsel. I have a > > duty to the shareholders of JPMC and cannot therefore ignore the > > advice of our legal counsel even if I happened to disagree with it > > (not that I am really qualified either to back up or refute that > > advice). > > > > Yep. I'm in the same boat. But I also don't want to shy away form > implementing something worthwhile unless the subject is well explored. > Does anybody know what the mailing list is that the Apache legal > folks chat on? > > > I should point out that I find that clause in the JMS specification > > licence really frustrating! > > > > I think those kinds of clauses are all over all the Sun APIs. > > > RG > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com >
-- Regards, Hiram Blog: http://hiramchirino.com
