Hi everyone, some time ago Justin Ross introduced the idea of an
imperative messaging API that could be implemented in various languages
and live alongside our existing AMQP clients like Qpid JMS and the
various Proton-based reactive style clients that we offer.
The goals of the imperative API are to allow for development of clients
that utilize modern language features to offer a mixture of asynchronous
programming with options for blocking as needed within the application.
These new clients would be client only implementations no server
functionality is offered.
The Imperative API spec as previously introduced resides here:
http://www.ssorj.net/pumpjack/client/index.html
The previous mailing list thread introducing the imperative API can be
found here:
http://mail-archives.apache.org/mod_mbox/qpid-users/202001.mbox/%3CCANVjZ_R31Hw4r9tWq6rDWNR6i-bJeyM9jKNbkRcWWOkbw%3DwBeA%40mail.gmail.com%3E
Here I am introducing an initial Java-based implementation of the
proposal imperative API that uses Java Futures to back the asynchronous
APIs allowing for blocking if needed but also for pipelined operation
when desired.
Within this implementation I’ve provided support for things like the
asynchronous sends and disposition tracking defined in the imperative
API presently as well as support for transactions and large message
streamed send and receive. Future work remains around client
reconnection and other possible API extensions.
As a reminder, the imperative API and this Java implementation remain
subject to change. We want to gather feedback from the community and
make any important API changes that are called for.
The Java client code is located here for review:
https://github.com/tabish121/protonj2
A set of examples has been provided which should help in reviewing the
basics of the new imperative API client, these are all located here:
https://github.com/tabish121/protonj2/tree/master/protonj2-client-examples/src/main/java/org/apache/qpid/protonj2/client/examples
The client is implemented atop a new AMQP protocol engine that is
implemented as a more reactive or event based model than the existing
proton-j engine which can hide some important details due to the
temporal squashing that occurs in its state machine, that means some
state changes can’t be discerned. This new engine exists within a new
set of Maven coordinates and Java packages which allows us to preserve
and support the existing Java-based engine for the foreseeable future.
The new engine is similarly subject to change.
--
Tim Bish
