qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject [c++]: Sketch of a high-level, protocol independent API
Date Mon, 06 Apr 2009 13:30:24 GMT
There has been much discussion around the need for a higher-level c++
API that insulates an application from any protocol specific details
while allowing specific features of any given protocol to be exploited
through the abstractions and extension points that this API offers.

I should note that the direct use of the AMQP 0-10 specific API will
of course still be supported.

The API I have in mind is based on the concepts of message sources
(from which messages can be received) and message sinks (to which
messages can be sent).

To send messages on a particular session, the application obtains a
MessageProducer for that session from the chosen sink, through which
it can then send messages. To receive messages, it subscribes the
session to the chosen source. A subscription can be assoicated with a
MessageListener (for 'push' style interaction) or it can create a
MessageReceiver (for 'pull' style interactions).

Two common patterns for sources and sinks are offered though the Queue
and Topic classes which allow sources and sinks to be created for
named queues in a point-to-point pattern, or publish-subscribe

The attached patch offers a working sketch of such an API. The API is
currently in the qpid::client::api namespace, primarily to keep it
separate from the existing AMQP 0-10 specific API.

There is also an implementation of this high-level API in terms of the
existing 0-10 API in the qpid::client::amqp0_10 namespace, and a few
example programs to demonstrate the use of queues and topics

This is still very much work in progress intended to demonstrate the
source/sink concept and how that can be mapped to different patterns
of interaction on a given protocol implementation.

A critical aspect that I have yet to address is the nature of the
Message interface (currently this just exposes raw data with no
properties or headers). I think we also need to figure out the common,
protocol independent options that we may want to directly support
e.g. browsing v. consuming, prefetch windows, automatic acking
v. application controlled acking etc. The threading model for connection 
processing and session dispatching also still needs to be thought 
through in more detail.

All queries, comments, criticisms etc are very welcome.

View raw message