If everything is addressed using an extended JMS front end how complicated does the JMS API become? At what point do the abstractions required become too extreme? If implementing some of the basic use cases pushes the extended JMS API too far then I'd think from a developer's POV that would not be OK.
Are there any use cases that would currently create this situation? You may not be able to predict every conceivable case, but you can predict a lot of them. > -----Original Message----- > From: Robert Greig [mailto:[EMAIL PROTECTED] > Sent: Monday, September 18, 2006 5:04 PM > To: [email protected] > Subject: Re: QPID/HermesJMS > > > Two more use cases > > -------------------------------- > > I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage > the > > protocol artifacts using a more intutive API and not JMS or an extended > JMS. > > There is also a JMS binding and if use the same interface then were is > the > > differentiation factor? > > The differentiation would be that there is an "extended JMS" API for > AMQ. So that API does not duplicate existing JMS concepts but adds > AMQP concepts to it - for example, the immediate flag. > > > I also want to use AMQP as a protocol for Axis2. Now I really haven't > though > > about this, but some of the unique features that AMQP offers maybe > useful if > > they can be accessed using a more natural API than through JMS. > > The idea is not that you would be limited to JMS "lowest common > denominator" functionality but that you could exploit AMQP where > appropriate but via the extra methods and classes exposed in > conjunction with JMS. > > Or do you actually want to work at the protocol level? If so, we need > to understand why the JMS API is deficient. > > RG
