On 06/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Hey Rob , knew this was comming :)
Glad I did not let you down :-)
As for the flexible part considrer the following example. If I want to send the same message to several destinations (different exchanges/routing key), I can use the low level client to do a "transfer by reference" where I send the content once followed by a several transfer methods to send the different message headers. Very efficient if the message is large. ex. SOAP attachment. ( message.open , several mesage.append methods to send the large message , x nof message.transfers and message.close)
I do not see why we would not want to expose this functionality via JMS. From the description it sounds to me very much like it would not be difficult to extend JMS to support this. Why would our business users not all want this for some specialised cases?
Here are some projects that are intested in this. Apache Axis2 like a AMQP transport. They already have JMS transport and most people use ActiveMQ :)
It does mean they have to write the transport from scratch rather than just tweaking their JMS one.
A user on apache synapse said in one application he likes to do specific things create/delete exchanges, queues etc only. If thats the case why would he have to use JMS and only use the *non* standard" extensions we added. He'd rather use the lowlevel client with minimum overhead and dependencies.
The question is whether that fits into an overall strategy for all our users. As I see it we have different users with different requirements: 1) people who have an existing codebase written in terms of JMS (including e.g. Spring JMS higher leve stuff) and want to migrate to Qpid with as few changes as possible 2) people who are starting from no code but their corporate policy dictates that messaging should use JMS (I know at least one large corporation like that :-)) and the apps are simple so will just use standard JMS 3) people who have a codebase written in terms of JMS but are interested in some of the capabilities that are being designed into AMQP 4) people who have no codebase and don't care about the API but want to exploit the features of AMQP Will the people in (4) walk away if they have to use a JMS-like API? I understand they will walk away if the API doesn't give them the flexibility or performance they require but from your post you imply that the mere fact it is a JMS API is a deal breaker.
[RA] I'd rather like to say that JMS support is a nice value addition than the main goal of Qpid java.
I find that a staggering statement. To help me understand can you please explain what you think the main goal of Qpid Java is?
People understand the limitations of JMS. If u are driving a morris minor and want the performance/experience of a ferrari u can try to change the appearance or modify the engine. But to get the real experience of a ferrari u need to get the actual one.
You are phrasing this in terms of performance. Are you saying that a different API can provide better performance than one that implements JMS?
Yes cost/time will be an issue. Managers always play this card. There is nothing free in this world.
I think there is a serious underlying question here that we as a project have not yet written down: what are the goals for the project? What is our 6 month plan? You are right - nothing is free - and I think that we need to understand much more clearly the opportunity cost of another Java API.
[RA] People using a low level protocol API do so with the explicit understanding that they may need to change code if they want to support a newer version of the protocol. We don't need to kill ourselves to maintain some pseudo API to insulate people from this kind of change. The low level protocol is a 1-1 map of the AMQP classes and if they are additions/deletions/modifications then it will be reflected in the new version.
But if that low level protocol API is the only way of getting access to certain features then we are effectively steering people to using that API.
All the messages they produce are of type AbstractJMSMessage which implements javax.jms.Message.
Is that such a big deal?
[RA] This is a good idea that I want to reuse. The ability to register different factories for various mime types.
It is kinda there just now but has not fully made it into the public API.
[RA] We need to build a product on a solid platform that can handle changes to the protocol etc. The current client did have some problems in that regard. We like to see this situation addressed as soon as possible before our user base grows.
I think there are a couple of discussions going on here: what should our API look like and what should we do with the current codebase for the client. You can argue for refactoring of the client codebase (as I would) without saying that we need to write a new API.
I understand that there are quite a few early adopters in JPMC, but I also think they understand the risk of working with a protocol thats changing rapidly.
So we should have a page on the Qpid wiki saying "Note: please understand the risk of using this product due to the rapidly changing protocol" ?
[RA] Well indiscriminate use of system properties with no documentation is not an acceptable alternative.
You make tradeoffs based on the resources available and the priorities. Nobody is arguing that system properties with no documentation is the way to go but given the limited set of things that anyone would want to change (mostly these were added for testing out performance tweaks) it was acceptable at the time. Opportunity cost again.
[RA] Well this is not the proper way to do it. We are working on adding the nessacery support for JMS features like queue browsing etc to the protocol. So as a temporary messure it's ok.
I am glad you approve.
[RA] I think this will confuse end users. We have the javax.jms.Session.createQueue(String name) and if people want to use AMQP stuff there is the createQueue(String queueName, boolean autoDelete ....). But to use that now u need to cast the jms sesson in to AMQSession.
You don't need to cast to AMQSession anywhere - that is an implementation class.
I would rather people use JMS properly and if they need AMQP features they can use a proper API for that. YMMV
So you are saying to people with an existing codebase that they need to rewrite if they want any real value from using our project. RG
