On 15/09/06, Robert Greig <[EMAIL PROTECTED]> wrote:
> Advantages:
> * Clearer structure for the JMS client code.
This may or may not be true. Depending on what we need to expose for
JMS, there may not be as clean a separation between the layers as you
might hope.
That's true. I think it's worth a look and see.
> * Ability to write tests for the broker that are rendered impossible via
> the JMS API.
> I guess we are using the Python client API for that though. I took a
> brief look
> at the Python client a while ago and I think it's excellent btw!
Yes, you can't work at the protocol level even with our extended JMS
API. But I would argue if we need to work at the protocol level for
test purposes we can do that in other ways (such as with the python
client).
Yes, I mentioned the Python client for testing. It's not a strong
advantage however it could have come in handy last week (as when I
fixed a bug in the client code I was no longer able to reproduce the
bug in the broker).
> * You can asynchronously send without having to worry about the send
> semantics
> in JMS. Specifically it appears that there is a need to block to
> detect and throw
> an InvalidDestinationException. In general you don't have to worry
> about JMS
> semantics which is nice.
Is this for the case where you specify a Destination in the send call,
as opposed to passing in the Destination when you create the producer?
Both.
For the latter case I have proposed and had agreement in principal to
add another method to the protocol to determine whether a given
routing key is routable by an exchange thereby allowing us to throw an
exception on creation of the producer.
That's not sufficient as it may (for instance) be a temporary queue
which gets auto deleted during the lifetime of the MessageProducer. In
this case send() should starting throwing InvalidDestinationException
- at least my my reading of the JMS API docs.
For the former case, we can block by default (which is nasty but
required for strict compliance) or provide an option allowing it to be
done asynchronously since I imagine some users will not want to take
the hit of the block. We should certainly discuss this issue
separately.
We cannot block at the moment as there is no way in the protocol to do
so. Using transactions closes the channel on error and in any case
doesn't seem to cover all use cases. I wonder what other JMS providers
do. I looked at ActiveMQ pages and found they have an option to turn
on AsyncSend but there is no discussion of
InvalidDestinationException.
> * You could directly supply headers as a field table.
We support this already in the extended JMS API?
I just mean that it needn't be encoded in a JMS-compliant way. Perhaps
with extensions to the field table types this problem may go away.
Yes, JMS suffers from being a lowest common denominator but it does
have widespread adoption.
Don't misunderstand me, I absolutely think that JMS (an extended JMS)
should be the primary API what we push. I just think that it could be
elegant to have a AMQP API layer that the JMS layer uses. This
AMQP-level API may be useful for direct use by other implementors (not
generally end-users) who are building adapters for other middleware
such as SCA or a middleware api adapter at JPMC that I am aware of.
I think we agree that we need to expose functionality that goes beyond
JMS. The question is whether we can do this though extension points to
JMS or whether we need a separate API.
Perhaps both. Application developers use JMS in order to remain
somewhat independant of the provider. For other uses that isn't a
requirement.
Steve.
