As a follow on to the prototyping work Justin has done for python I wanted
to also point to the work Robbie and myself have been doing around an
imperative API based Java client. This client follows the basic API
guidelines for a futures based client as outlined in the API specification :
http://www.ssorj.net/pumpjack/client/index.html
The Java based client is currently somewhat functional but has some gaps
yet to be worked out around credit handling and drain etc. Some basic
examples are in place to show off the API implementation are in the Git
repository. The current implementation is pretty up to date with the most
recent imperative API documentation changes.
The repository for the client is here:
https://github.com/tabish121/AMQPerative
And a compressed set of samples for various API interaction is located here:
https://github.com/tabish121/AMQPerative/blob/master/amqperative-examples/src/main/java/org/messaginghub/amqperative/example/Samples.java
It is also important to note that the Java client uses an experimental
proton-j engine implementation that we've also been working on which is
built around a more reactive model using modern Java language features and
offers easier coupling to the I/O layer of choice. The imperative client
is using Netty similar to the Qpid JMS client for its I/O. If you want to
run the examples from the imperative API client you'd need to also build
and install the new proton-j engine library into you local maven
repository, the code can be checked out from Github here:
https://github.com/tabish121/proton4j
The project names are not meant to be the final names just quick
placeholders to get something going, hopefully future discussion can work
out some more suitable naming for these should they gain traction.
On Mon, Jan 13, 2020 at 7:40 AM Justin Ross <[email protected]> wrote:
> Hi, everyone. For a while now, some members of the Qpid community have
> been working on a new style of messaging API. It now has a reasonable
> shape, and we want to share it and get your feedback.
>
> We currently offer either JMS or Proton's reactive API. These certainly
> aren't going anywhere - they're important - but for some use cases, the
> absence of a high-level command-oriented API for AMQP messaging is a source
> of inconvenience.
>
> This inconvenience comes in two forms. First, JMS is helpfully imperative
> (in part - it contains multitudes), but it doesn't expose some of the
> things you can do with AMQP. And it can't reasonably expose those things,
> because that would break the contract of the JMS API. Second, the Proton
> APIs, since they are reactive, make it harder to handle cases where you
> need to sequence the processing of events.
>
> The imperative client API we are talking about here uses modern language
> support for futures or coroutines. Most of the API's operation is
> asynchronous, but you can easily introduce blocking where you need to.
>
> It's a client API only. We think a comparably high-level server API would
> be its own dedicated thing, functioning more like Python Flask or JAX-RS.
> In any case, the Proton reactive API is already a good fit for writing
> servers.
>
> We have the outline of the API and some proof-of-concept implementations,
> but much remains to be done. We anticipate that this work will ultimately
> become a sub-module of Proton, such as proton/client.
>
> The API spec:
> http://www.ssorj.net/pumpjack/client/index.html
>
> I've worked on the Python prototypes, so I'll share them here. I did these
> some time ago, so they need updating for the latest API spec changes, but
> they serve to show how the API can use futures or coroutines. (For Python,
> coroutines are the preferred approach.)
>
> Python prototype (future-based):
> https://github.com/ssorj/gambit/blob/futures/python/demo.py
> https://github.com/ssorj/gambit/blob/futures/python/gambit.py
>
> Python prototype (coroutine-based):
> https://github.com/ssorj/gambit/blob/asyncio2/python/demo.py
> https://github.com/ssorj/gambit/blob/asyncio2/python/gambit.py
>
> Some of the other folks who have done exploratory work will follow up on
> this thread to show what they've done.
>
> Some caveats: this is in early stages, and the API will change as we
> discuss it more. There are also big outstanding pieces to look at, such as
> reconnect and failover, to name just one.
>
> Thanks for your time, and please let us know what you think.
>
--
--
Tim Bish
