Hey Rob , knew this was comming :) On 6/5/07, Robert Greig <[EMAIL PROTECTED]> wrote:
On 05/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > There is also some demand for a very low level protocol level client that > works at AMQP method level from other projects who want fast AMQP support > w/o bothering to use any JMS. There is also a demand for a slightly higher > level java client w/o any JMS. Where is this demand and what is the reason for it? Is this because a low level API must be in some way faster, or that Real Men program at the lowest level and JMS is for quiche eaters?
[RA] LOL , not everybody wants another dependency (in the form of JMS) added to their project especially if it's just infrastructure and not visible to the end users. What they want is AMQP support and not JMS. If they wanted JMS only they do have other choices too. Apache itself has two projects :) A low level client w/o an additional JMS layer and a threading model can be faster and flexible than a JMS implementation. 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) 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 :) I like to add an AMQP transport with out the additional overhead of JMS and be able to optimise for large messages. 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. I have said this many times now so I promise this will be the last,
but I think having two end user APIs is a mistake. What do you say to users who use JMS and want to take advantage of some specific AMQP feature? Rewrite your application to use our "other" API?
[RA] I'd rather like to say that JMS support is a nice value addition than the main goal of Qpid java. We do so bcos JMS is the standard java API. If specific AMQP features are needed then they can try to use Qpid java client or the AMQP client to do them while continuing to use JMS. I don't like that option unless you are forced to add AMQP support (not expressed through JMS like creating an exchange) to an existing app. 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. If u want to use JMS only then fine use the API. If u want JMS primarily and some AMQP features then try to use both clients to supplement what JMS don't offer. If u want to leverage AMQP to it's fullest extent, please consider using the low level client or Qpid client instead of JMS. Yes cost/time will be an issue. Managers always play this card. There is nothing free in this world.
While most end users prefer JMS, most infrastructure projects wants native > support and likes a framework like client to work with. Why is this?
[RA] Rob see my comments above.
Adding more methods to JMS is IMHO not the correct way to expose AMQP > features, neither does it do any justice for the AMQP features. Why not? Can you give a concrete example?
[RA] Rob see my comments above.
If we are trapped in the JMS mentality for long we will not evolve. It's > wise to have support for JMS. However it's prudent to be a bit more radical > and have an AMQP client. It certainly has enough merit to deserve it's own. I don't understand this argument. You accept the need for a JMS client but you seem to think that we are then doing our Java users a favour by making that some third rate distant cousin that we send a Christmas card to every year but otherwise shun? I have argued strongly in the past (before Qpid was open sourced) against having an API that too closely mirrored the protocol, because of the likelihood of protocol changes and the impact that would have on existing users. Imagine we had a wire level API (oh we could have called it WireAPI to pluck a name from the ether) that people were coding to. How would we deal with the kind of changes planned for the protocol? We would be faced with either having a lot of work to maintain the API and map it to the new protocol or tell our users "sorry you're just going to have to rewrite your apps".
[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. If u want more insurance and be insulated from these changes, then they can use JMS. If people adhere to the JMS spec properly there is absolutely no need to worry (provided wire format changes don't apply as all apps talk the same version or is backward compatible).
[RA] No the existing message factories are too tightly coupled with JMS. > I am proposing three generic message factories. > TextMessageFactory, XMLMessageFactory, BytesMessageFactory. (We can add more > in the future .. example SOAPMessageFactory). In what way are they coupled to JMS? I had envisaged there being a method with signature:
All the messages they produce are of type AbstractJMSMessage which implements javax.jms.Message. Message createMessage(String mimeType)
on Session that would allow the creation of arbitrary message types (that had been registered).
[RA] This is a good idea that I want to reuse. The ability to register different factories for various mime types.
[RA] The intent is to replace the existing client. Please read my general > comment about the rational behind it. > Several of us tried to re-factor the existing client with limited success. > Hence we decided to rewrite the client. I think it's a good time to revisit the client as we approach the 0-10 protocol. Having a proper logical separation of the client into an upper and a lower layer is important to help us keen sanity while the protocol evolves. There are other things we should be isolating ourselves from too, such as MINA so that we could plug in other network frameworks (e.g. Grizzly).
[RA] One of the reasons for the refactor was to isolate all these aspects. Currently u can replace the transport phase (in the AMQP client) with a grizzly implementation w/o any implications to any layers above it. One reason for abandoning the old client was that the MINA specific aspects have bled all the way to the JMS layer and a seperation was very difficult. I do however tend to agree with Joel Spolsky who argues far more
eloquently than I can against complete rewriting in general: http://www.joelonsoftware.com/articles/fog0000000069.html. > Continuous innovation is the way forward. That's what people expect from > open source projects as opposed to proprietary projects. A product-focussed mindset is essential if we want to grow our userbase. People who want enterprise features such as more flexible authorization are not going to be impressed if you say "by the way, if you want to use these features you're going to have to spend $100k on code changes to your app".
[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. And that why I think we need make the changes now, not later. We are an incubating project and people understand that there will be changes and innovation happening. We are still in the growth phase. However once we mature we need to think more about stability etc. How can we stabalize as a product when the underlying AMQP protocol is still suffering from growing pains ?? 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.
[RA] One of the problems of the existing client is the indiscriminate use of > the system properties with virtually no documentation. The code is littered > with the use of system properties. One improvement I made is to unify the > configuration using commons configuration. Now all configuration has been > moved to an xml file which can be documented properly and configured easily. > However u can continue to override these properties using system properties > if u will. This is an improvement to someone and another unwanted dependency to someone else. There was a deliberate decision not to use commons configuration. A client will be used in all sorts of situations, embedded in app servers etc. What if someone else wants to use another version of commons configuration that we don't support? We really need our own abstraction layer so that people who want to use different config mechanisms can do so (a bit like slf4j does for logging).
[RA] Well indiscriminate use of system properties with no documentation is not an acceptable alternative. We also had properties file for some config. I think people will appreciate a unified approach to configuration that is easy to configure and modify. But our own abstraction is important and will work on that. After Rob Godfreys suggestion I am planning to use slf4j for logging as well.
w.r.t amqp strict flag, what does this do? the java implementation is > notorious for introducing non standard features. If u set this false does it > mean we are doing something non standard ? why do we want to do that? It was added to draw the user's attention to the fact that a particular feature used non-standard extensions to the AMQP protocol. As you may recall some JMS features could not be implemented with the existing AMQP protocol.
[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.
Frankly there was no API to start with, so there want be any incompatible > API changes. Did we have an AMQP API visible before ?? (other than a few > methods added as extensions to the JMS interfaces). I don't think u can call > that an API. Why not? I think it could have been extended but that is a different argument.
[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. I would rather people use JMS properly and if they need AMQP features they can use a proper API for that. YMMV --Rajith RG
