I really like the .NET AMQP API that Microsoft itself develops.
although I don't spend my day to day in .NET, it was simple to use it
when I needed it.
On Thu, Jan 9, 2020 at 6:04 PM Justin Bertram <jbert...@apache.org> wrote:
>
> This seems a little strange to me.
>
> The power of JMS is that it is broker agnostic. It's just an API of fairly
> generic messaging concepts for which any broker can implement a client.
>
> The weakness of JMS is that it is Java based. NMS, as I understand it, was
> meant to mitigate that weakness by porting the same basic API to .Net (and
> the same goes for CMS with C++). The goal was to have an API for which any
> broker could implement a client. Early implementations could talk to
> ActiveMQ (via the OpenWire protocol), Tibco EMS, and IBM WebSphereMQ. One
> implementation was even apparently built on Microsoft's MSMQ API. There was
> also a STOMP implementation and then later an AMQP one. The benefit of
> these two is that they used standard communication protocols and therefore
> could be used with any broker which supported that protocol. So, for
> example, a messaging application using NMS AMQP could talk to RabbitMQ,
> Apache Qpid, ActiveMQ 5.x, or ActiveMQ Artemis.
>
> You're taking a standard communication protocol (i.e. AMQP) and putting an
> API on top of it that mirrors the ActiveMQ Artemis address model. This
> ruins the flexibility that AMQP provides and marries client applications to
> a single broker. Furthermore, AMQP doesn't "know" about routing types,
> addresses, and queues. It has different concepts which we *map* onto the
> Artemis addressing model in the broker.
>
> The Artemis addressing model is low-level in order to be able to support
> all kinds of different protocols which each have their own
> similar-but-slightly-different models.
>
> Why don't you just implement the core protocol in .Net? It appears to me
> that if you use AMQP you're going to have to somehow shoehorn in Artemis
> addressing model concepts on the client and then interpret those on the
> broker. You are certainly free to implement the client the way you want,
> but I don't think I would endorse broker changes to support it. If you used
> the core protocol then you'd have access to everything.
>
> Aside from that, what's wrong with the APIs for other AMQP or STOMP clients
> for .Net?
>
>
> Justin
>
> On Thu, Jan 9, 2020 at 4:12 PM Krzysztof <h4v...@gmail.com> wrote:
>
> > @Clebert
> > So the idea is to reduce the impedance mismatch between Artemis address
> > model (which is geat!) and the concepts from jms/nms (not so great, at
> > least for folks from .net world, who used to work with rabbit mq before).
> >
> > I would like to be able to create a consumer and attach it by defining its
> > address, routing type (Multicast, Anycast) and queue name. It would be nice
> > if I could define if the subscription is shared and durable as well. If
> > this particular queue doesn't exist, currently the exception is thrown. I
> > would like to change this behavior, to create the queue dynamically. The
> > same way as queues are created for jms 2.0 subscriptions. Sample api would
> > look like this
> >
> > var consumer = await connection.CreateConsumerAsync("test-consumer",
> > RoutingType.Anycast, "q1");
> >
> > @Justin
> > I'm using AMQP. The very early POC is here
> > https://github.com/Havret/ActiveMQ.Net
> >
> > On Thu, Jan 9, 2020 at 3:16 AM Justin Bertram <jbert...@apache.org> wrote:
> >
> > > What protocol is the client going to use?
> > >
> > >
> > > Justin
> > >
> > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <h4v...@gmail.com> wrote:
> > >
> > > > I'm just wondering if it should be possible to create queue based on
> > the
> > > > value specified via FQQN. Currently you cannot attach to the queue if
> > it
> > > is
> > > > not pre-configured.
> > > >
> > > > I'm working on POC of .NET ActiveMQ client and I am trying to give the
> > > > potential user as flexible API as possible.
> > > >
> > > > The draft API assumes that it should be feasible to specify address,
> > > > routing type (Multicast, Anycast), queue name, durability, and whether
> > > the
> > > > queue should be shared or not.
> > > >
> > > > This way user would be able to leverage most of the Artemis Address
> > Model
> > > > configuration options directly from the code without pre-configuration
> > > > anything on the broker side.
> > > >
> > > > What do you think?
> > > >
> > >
> >
--
Clebert Suconic
