Alan Conway wrote:
Here is a simplified version of the proposal. It involves fewer classes but I think is just as flexible and extensible as the original.


------------------------------------------------------------------------

/**
   This is a sketch of some highre-level patterns of use intended as a
   supplement to (not replacement of) existing API. These patterns
   hide wiring and subscription details of setting up common patterns of use.

   Main changes from Gordons proposal:
    - Fold MessageProducer into MessageSink
    - No generic MessageSource, subscribe directly to pattern classe objects.
      Listener + Subscription already provide a generic representation of the 
source.
    - Avoids double layer of factories.
    - Pattern classes are real objects not just static function namespaces.
    - Using LocalQueue rather than MessageReceiver here, we can argue about the 
name later.
    - Drop bool synchronous arg, sync/async send have different return types, 
async must return a Future.

   ALTERNATE IDEAS:
    Build LocalQueue into Subscription, allow a listener to be attached to a 
subscription
    after it is created (it will receive any queued messages)
*/

class Future {...}; // Need a future for async send.

class MessageSink {
    // NB: Send can modify the message, e.g. set its routing key or attach 
properties.
void send(Message&); Future sendAsync(Message&);
    // Should cancel automatically in dtor, do we need an explicit cancel?
    void cancel();
};

// Re-cast LocalQueue as a Listener so there's only 1 mechanism to deliver 
messages to app.
// A single subscribe(Listener) function supports both push and pull.
class LocalQueue : Listener { ... };

class Topic {
    Topic(Session, name);
    Subscription subscribe(Listener, pattern);
    Subscription subscribe(Listener, pattern1, pattern2);
    ...
    Subscription subscribe(Listener, vector<string> patterns);

    MessageSink getSink(pattern);
};

// Avoid name Queue since that has a different meaning in AMQP than the pattern 
described here.
// Note inherits MessageSink since there's only one sync for a SimpleQueue - 
built in.
class SimpleQueue : public MessageSink {
    SimpleQueue(Session, name);
    Subscription subscribe(Listener);

// send/sendAsync/cancel from MessageSink };

I think explicitly indicating intent to publish is important and I don't think SimpleQueue above does that.

I think it would also be desirable to be able to write code that is independent of the specific 'pattern class' used (e.g. can operate with simple queues or topics).

Other than that I agree with many of your points.


class XQueryEvaluator : public MessageSink {
    XQueryEvaluator(Session, name, ... ?);
    Subscription subscribe(Listener, xquery);
// send/sendAsync/cancel from MessageSink }; // ==== Example code sketches.


// SimpleQueue
int main() {
    Session s = ...;
    SimpleQueue queue(s, "foo");

    // Sending
    for (...) {
        message = ...;
        queue.send(message);
    }
    // Pull style:
    LocalQueue lq;
    queue.subscribe(lq);
    while (...) { Message m = lq.get(); ... }

    // Push style
    MyListener l;
    queue.subscribe(l);
    sessoin.run();
}

// SimpleQueue
int main() {
    Session s = ...;
    SimpleQueue queue(s, "foo");
    for (...) {
        message = ...;
        queue.send(message);
    }
    // Pull style:
    LocalQueue lq;
    queue.subscribe(lq);
    while (...) { Message m = lq.get(); ... }

    // Push style
    MyListener l;
    queue.subscribe(l);
    session.run();
}

// Topic
int main() {
    Session s;
    Topic topic(s, "myTopic");

    // Sending
    sendMessages(topic.getSink("usa.news"), count, "news about usa");
    sendMessages(topic.getSink("europe.news"), count, "news about europe");

    // Pull style
    LocalQueue lq;
    topic.subscribe(lq, pattern);
    for (...) { Message m = topic.get(); }

    // Push style
    MyListener l;
    queue.subscribe(l);
    session.run();
}

void sendMessages(MessageSink topic, int count, string news) {
    for (... count ...) { topic.send(Message(news); }
    }



------------------------------------------------------------------------


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to