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?
> > >
> >
>
