Here is a quick analysis of how to handle some of the use cases we've
discussed using the factoring of NP and distributor from my previous
post.
- Dumb devices on closed network. I would like to know,
say, each time a given printer finishes printing a document. I send a
subscribe request to the printer with an EPR for my host (and nothing
else). The printer trusts me because it's a closed network and sends
notifications directly to me. I get each notification, in order. The
printer is responsible for sending notification to each interested
party, but again it's a closed network so this shouldn't be burdensome.
- Pull-based Notification. This can work one of two ways.
- First, the subscriber could supply a queuing distributor to the
NP, which treats it like anything else. This distributor could be
managed by the subscriber, the consumer, or anyone else. The ultimate
consumer knows in advance where to poll for messages.
- Second, the NP could do the queuing itself and act as a
factory. The factory method for producing the distributor returns an
EPR to give to the subscribe operation and an EPR for the ultimate
consumer to poll. The EPR given to the subscribe operation is really
just a cookie identifying which queue to write to. In detail:
- The subscriber sends the NP "give me a queue with these
properties (buffer capacity, durability, etc.)"
- The NP sends back EPRs for the two endpoints of the queue.
- The subscriber sends the ultimate consumer the read end of
the queue.
- The subscriber sends the NP a subscribe request with the
write end of the queue and whatever filtering is appropriate for the
subscription.
- Limiting access. I want to be sure that notifications are
only sent if the NP trusts the subscriber or if the ultimate consumer
approves. The NP refuses to accept any EPRs accept its own cookies
(which contain a signature). Cookies are given out via a factory
method. The factory method applies whatever security policies are
appropriate and faults if they are not satisfied. The same process can
also establish a security context between the NP and the ultimate
consumer.
- 1-of-N/Shared State. This is modeled as taking place in
the distributor. The NP simply sends messages to the input end of the
distributor, and the distributor decides where to send from there.
There is clearly room for endless variations in delivery in this model,
e.g., load balancing, changing the ultimate consumer endpoint(s) on the
fly, etc. Again, the actual distribution could be handled by the same
process as the NP, and delivery from the NP to the distributor might be
entirely notional. That's an implementation concern.
- Reliable messaging. If we specify that delivery from the
NP to the EPR given in the subscribe request is perfectly reliable,
then any unreliability must be modeled in the EPR itself. This seems a
bit counterintuitive, and there are at least ways to deal with it:
- Specify unreliable delivery as the default. If you want
reliable delivery, obtain a reliable distributor and subscribe using
that. The problem is that the connection from the NP to the
distributor is still unreliable.
- Leave reliability up to the NP. The NP may or may not allow
for reliable delivery. This brings reliability into the core.
- Specify perfectly reliable delivery from the NP to the
distributor. An NP which cannot support reliable delivery (e.g., one
sitting in front of a complex broker-based system) cannot accept direct
subscriptions. Instead, the subscriber must first obtain a distributor
that it knows to be unreliable, then make the subscription with it as
the endpoint.
The overriding theme here is that the default delivery behavior is as
simple as possible semantically: Perfect delivery to a single
endpoint. Anything else has to be negotiated explicitly by obtaining a
distributor with the less-simple semantics. With this separation made,
the semantics of the distributor can be anything at all with no change
to the basic subscription pattern.
|