On 15/09/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
>
[RA] As AMQP evolves we *may* have functionality in AMQP that cannot be
trivially expressed using a JMS client.
So to make the full use of it we may need an AMQP API.
I really don't see what harm it would cause if we have a seperate AMQP API?
(other than the confusing factor which I dont' buy)
Clear documentation is all we need to get rid of the confusion this might
cause.
The problem is that you a forcing people to make a choice if you have
different levels of functionality in each API.
Let's say someone writes an application using JMS (or migrates an
existing application from another JMS provider - a very common
scenario if the JPMC use cases we have seen so far are typical). That
works fine, so they develop the next version of their application and
want to use an AMQP-only feature (such as the immediate flag in the
current implementation).
Do we have to say to those users that they have to change all their
existing application to use our other API?
Using an extended JMS API would mean they only have to change some
imports and maybe alter some code but most of it would remain the
same.
[RA] Not at all. I was saying that JMS might be too simple to make use of
the full power of AMQP.
Or rather JMS might not expose the full power of AMQP as expected.
Yes, JMS definitely does not allow you to expose the full power of
AMQP. As far as I am aware every JMS provider has their own
extensions.
If what people need is just JMS then it's fine, but if they need to go more
deep into the protocol level how are we going to cater to them??
We can extend the JMS API, as we have done currently.
> Can you expand on this point? I don't know much about SCA.
[RA] SCA - Service Component Architecture.
Bindings define how the the invocations are mapped from there native format
to that expected by the SCA runtime and the target component.
For example the native format might be a JMS message , AMQP message, SOAP
message, JSON RPC, RMI ..etc
We are trying to provide a AMQP binding for SCA (there is already a JMS
binding). So we need to utilise the full power of AMQP to differentiate it
from the JMS binding. So having a AMQP client API is going to make things
very easy.
OK, I understand now (roughly). I presume the JMS binding does not
allow any use of properietary extensions. In that case, why not create
an AMQP binding but make it a JMS-AMQP binding that can use our
"extended JMS" API. That might be easier anyway since you could use
some of the existing SCA/JMS code?
[RA] Exactly, but why can't we have a clear seperation? Why can't we have a
well defined AMQP client API and then implement JMS on top of it? Are there
any technical reasons for not doing so?
Can we achive a clear seperation?
I think the usage issues are a stronger argument than technical issue
but I am not sure whether a completely clean separation could be
achieved.
It certainly would not be *more* efficient, and there may be
requirements to "leak" implementation details from the AMQP layer to
the JMS layer which may be less elegant.
[RA] Robert why an extended JMS API?
Why not we have our own client API which is much more natural to implement
than trying to shape it upto the JMS messaging model.
Why can't we write a JMS adapter on top of the AMQP API.
An extended JMS API gives a clear "upgrade" path for users and reduces
the testing and documentation requirements (two APIs means two sets of
documentation and testing). By being seen to be fully behind JMS
rather than viewing it as a poor cousin of another API we give our
users confidence that we are fully behind JMS.
My vision for the future is that as AMQP becomes more widely
established and therefore that other messaging providers adopt it and
want to expose the functionality the protocol offers, that our
extensions get added to the JMS specification and API.
Right now AMQP and JMS are mixed to gether and this much more confusing than
having a clear seperation?
The intention was that people know only know JMS could use that API
quite happily without really having to know very much about AMQP, but
that as they became more familiar with AMQP they could use that
functionality.
Are there any specific aspects of the extended API that you think is confusing?
RG
