qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: [c++]: Sketch of a high-level, protocol independent API
Date Mon, 13 Apr 2009 14:10:23 GMT


One comment I would have. In AMQP 1.0 we will have Queues and links, which
can still handle the 0-10 model. However in an API would we not want to 
drop the
noun Exchange and just use BindTo() or LinkTo() so that the API will 
work forwards
to AMQP 1.0 with naming?


Gordon Sim wrote:
> 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
> 'topics'.
> 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
> (examples/hla).
> 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.
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message