Rupert Smith wrote:
This describes the centralized approach advocated by Gordon. One
important difference with Gordon's proposal is that the assign role
(and some other control messages) are not sent out on a fanout
exchange like he describes, but on a topic exchange instead. This is
because there may well be a pure JMS test client, and the JMS
implementation only talks to direct and topic exchanges, not fanout.
The exchange type used isn't critical, the purpose was to allow the test
controller to easily address a particular subset of clients (e.g.
senders or receivers).
If the test clients merely return the name of their control queue then
the controller can bind them as it sees fit for the purposes of its
communication. Each test client is then only responsible for creating
its control queue, binding that such that it receives invites and then
reading all the control messages that arrive in the queue.
Also, I'm thinking that for each test case instance there will only be
one sender and one receiver client (although the receiver may be asked
to open multiple connections for pubsub tests), whereas Gordon's
solution was a bit more general purpose in that their could be many of
each.
One of each is fine to begin with (though I do think that many of each
will be desirable as well) and makes the point above (i.e. easy
addressing of a subset of clients) less of an issue.
- Re: Draft Interop Testing Spec - Please Read Gordon Sim
-