> It would be really great if we could define this API as a > standard and not just specific to apache/qpid. Is there > anywhere this might live? Do others think that would be important?
I think that's very important, and there was some sentiment from (potential) users expressed in favor of this sort of idea at the AMQP face-to-face public meeting last week. I don't think trying a formal industry standard is adviseable, but certainly trying to get some participation from other AMQP-implementing bodies would be a positive step. -Steve > ----- "Gordon Sim" <g...@redhat.com> 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-subscr...@qpid.apache.org > > --------------------------------------------------------------------- > 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
