What does it mean for the NP to "send" a message?

[David Hull <dmh@tibco.com>]

Intuitively, sending a message means something like putting it on the wire so that the Consumer will receive it, but as it stands, this notion is not precise enough for our purposes.   The distinction between sending a message and putting it on the wire has just come up in the context of continuity, and it's clearly important for reliability as well.  I suspect that defining the concept rigorously will also clarify the semantics of other delivery-oriented policies such as durability, queuing, one-of-N delivery and so forth.

Since this is a sticky question, it seems best to steal leverage someone else's work.  As it happens, the two Reliability standards both define a two-tiered model which I think will fit nicely here.  Since we're OASIS, I'll use the WS-Reliability TC's terminology.  In this view, getting a message from producer to consumer is a three-step process involving four entities.

1. The producer submits a message to the sender (WS-RM actually calls it a "Sending RMP", that is a "Sending Reliable Messaging Processor", but I want to use the same notion for other purposes as well).
2. The sender sends the message to the receiver, wrapping it appropriately, noting serial numbers, handling acknowledgments, etc.
3. The receiver delivers the message to the consumer.

In WS-R, the consumer also responds to the receiver and the receiver and sender cooperate to allow the sender to notify the producer that the message has arrived.  This is clearly central to WS-R, but in the present context I'm just trying to emphasize the split between the producer/consumer tier and the sender/receiver tier.

In the case of continuity in the face of subscription property changes, the issue is that certain messages may never be submitted, not that submitted messages will never be sent.

I believe that the cleanest semantic for BaseN is that

• Each notification message relevant to a subscription will be submitted exactly once.
• The messages on a given topic will be submitted in the order their corresponding events occurred.

There is a further question of how messages on multiple topics may be interleaved, and whether separate subscriptions see the same interleaving.  For now, I'd like to raise this as an open issue.

In this view, all further semantics, including reliability, security, durability and so forth, are between the sender and the receiver.  The reliability standards are very careful not to say what kind of connection exists between producer and sender, or between receiver and consumer.  The exact meaning of submit and deliver are left implementation dependent.  The strong implication is that they are generally local calls with a single process space, and thus are reliable and secure barring catastrophes.  In any event, guarantees of reliability are only made between the sender and receiver, and I believe we should follow this pattern for all non-trivial delivery semantics.