Comments on the minutes, "distributors"

[David Hull <dmh@tibco.com>]

The AM minutes show that I was volunteered in absentia to handle the "continuity" use case.  I'm fine with that.

The PM minutes show a very interesting discussion of queuing issues.  A couple of comments, particularly those concerning different flavors of SM, turned on the proverbial light bulb in my head.  As usual, the pieces have been floating around for a time and I doubt I'm the first to come up with this particular formulation.

For quite a while I've been looking for a way to separate the basic pattern of subscription via logical addresses (read, topics) from the combinatorial explosion of ways to deliver messages.  One way to crack this is to introduce a separate entity between the NP and the ultimate consumer.  I say "ultimate" because nothing needs to change from the NP's point of view.

Call this new entity something besides "queue".  For now I'll use "distributor".  The NP's job is to send messages to the distributor.  We specify that such messages are delivered exactly once to the distributor in the order sent.  Any deviation from this is due to the distributor itself.

It is the distributor's job to deliver the notifications to the ultimate consumer or consumers.  It may do this in any of the ways we have discussed, or in any other conceivable way.  It may place them in a queue from which the ultimate consumers pull.  It may distribute each message to any number of the consumers.  It may drop messages, re-order them, or whatever it pleases.  All this depends solely on what sort of distributor is used and how it is configured.

A subscription request then consists of

• The EPR of a distributor
• Optional filtering parameters (topic, etc.) describing what messages will be sent to that distributor.
• Security tokens as required
  

There are two very important points here

1. This description does not imply any particular implementation.  The only condition is that the net effect be equivalent to the NP sending to a distributor which handles delivery.  In particular
2. Designating the distributor by an EPR does not imply that it must be separate from the NP.  For example, the NP might also export a "distributor factory" interface.  You give it your delivery requirements, it gives you an EPR you can use in a subscription request, which it may choose to handle entirely by itself or with help from other entities.

The existing pattern of sending a subscription request with some random consumer EPR will still work.  You just won't have fine control over the delivery, and the NP may refuse your subscription entirely.  If you want more advanced delivery, you have to get an EPR for a more advanced distributor, either from the NP in it's "distributor factory" role, or somewhere else.  I believe brokering may be largely a special case of this.

Since an NP, as always, may refuse to deliver to an EPR it doesn't like, we can enforce whatever access control we like.  For example, if I try to get an NP to spam a random address, it can just refuse.  I would instead have to get a valid distributor EPR from it, either by presenting credentials to the distributor factory interface, or by allowing it to send a test message.  Note that this moves double opt-in's asynchronous fault to the EPR creation phase, so there's one less reason we might need asynchronous faults for the subscription proper.

On the other hand, the lightweight case of dumb devices on an isolated network still works fine.  Just give them the consumer EPR directly.

This factoring also allows for advanced delivery to be used independently of WSN.  A distributor could be used anywhere something produces a sequence of messages (e.g., perhaps, anywhere a 2.0 WSDL specifies an out-only service).  In other words, we (WSN, OASIS, the WS community at large) can specify as many distribution patterns as we like whenever we like.  These would add value to WSN and to any other similar scenario, completely non-intrusively.