Hi Ted,
many thanks for the quick response I've commented inline below
Frase,
I think you're mostly correct about the way that qpidtoollibs should
work with regard to object-ids. In QMFv1, the IDs were
broker-assigned and opaque. In v2, they are composed of the values of
the referenced object's "index" properties. This is why the id ==
name assumption worked. It might be more correct to do as you suggest
and compare to a properly formed getObjectId() result.
I guess that my take is that they are conceptually opaque whether we're
talking V1 or V2. To be fair in the API spec
https://cwiki.apache.org/qpid/qmfv2-api-proposal.html there's an
interesting line which says:
"
An object identifier can be assigned to the object by the agent when the
object is instantiated. Alternatively, a schema can define an object
identifier by defining an ordered list of names of data items. In this
case, the object identifier string is built by concatenating the string
representations of the value of each named data item
"
So I guess there's at least some allusion to the concept that an
ObjectId might in some circumstances be non-opaque, however there's no
mention anywhere of how to specify the list of names.
Well that's not totally correct, in "class
SchemaObjectClass(SchemaClass):" it has ".set_id_names([name-list]): set
the value of the order list of names to use when constructing the object
identifier." so the API could do this, but I've not seen anything
obvious in management-schema.xml that points to this. You mention
"index" in your response - so are you suggesting for example that the
Exchange ObjectId comprises the vhostRef and the name concatenated in
some way? The example in the spec shows simple concatenation, but from
what I've seen the BrokerObject __getattr__ is looking for colon separators.
In any case I still think it's dangerous from the perspective of object
references and think it's far safer to treat them as opaque and at the
very least if one uses an object name as a target of an object reference
that object's getObjectId *really* should return name in that case.
I know I'm labouring it a bit, but I spent ages trying to figure out
what was going on 'cause I had assumed that it's something I'd done.
With regard to using the topic exchange for replies, that was quite
deliberate. There's really no benefit to using a different exchange
for replies and it makes writing ACL rules more difficult. It also
makes it more difficult to use any form of federation for exchanging
messages. I would consider deprecating the qmf.*.direct exchanges
altogether.
Re "There's really no benefit to using a different exchange for
replies", hmm well yes I might agree with this comment but interestingly
if you consider the code you'll see:
self.tx = self.sess.sender("qmf.default.direct/broker")
and
self.reply_to = "qmf.default.topic/direct.%s;{node:{type:topic},
link:{x-declare:{auto-delete:True,exclusive:True}}}" % \
So using the topic exchange in the replyTo is indeed using a different
exchange for replies and I can't see what advantage this gives.
Re "I would consider deprecating the qmf.*.direct exchanges altogether".
I can't agree with you there. QMF is fundamentally implementing a
request response pattern, which is in essence very much a point-to-point
model. There's a bunch of work for service discovery (or in the case of
the broker a "well know" alias subject of "broker" as used in self.tx
above). Sending to a topic (to my mind at least) is about sending out a
"broadcast" message, whereas with QMF it's pretty much sending a query
to a given agent.
There's clearly a need to broadcast in the case of agent discovery, but
in terms of agent query I'm not clear that it makes any sense at all so
I'd normally expect each agent to have a different binding key. Even
multiple instances of the same agent ought in general to have different
names 'cause if not doing a get object request could lead to interesting
message race conditions.
The bottom line is that I very much think that a direct exchange is by
far and a way the most appropriate exchange to send message requests and
responses in a request/response messaging pattern you are in effect
sending a message directly to a unique named endpoint and asking for the
response to be returned to a unique named endpoint. As I say that feels
very different from publishing to a topic that may have multiple
independent subscribers. But even if publishing to a topic made sense
(and I don't think it does) a replyTo is almost always asking for the
response to be returned to a unique named endpoint (that's certainly the
case in QMF).
If there's truly a use case whereby a service requester wishes the
response to be broadcast to multiple recipients then I've got no
quibbles there of using a topic exchange, but that's a relatively
uncommon use case in request response messaging and I really don't think
it's the case in QMF.
If you're suggesting "deprecating the qmf.*.direct exchanges altogether"
you might as well argue for deprecating direct exchanges in general and
(ab)using topic or header exchanges. IMHO QMF request/response is
actually one of the classical messaging scenarios where it's entirely
the right thing to do to use a direct exchange.
I don't disagree that it's possible to "emulate" the behaviour of a
direct exchange using a topic exchange, but I think it's important to
consider semantics and intent.
Best regards,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
