I agree .As per other mail rather than trying to make some new api or something
esoteric.It be much better to simply update NMS api to 2.0 e.g. add shared
durable and shared non durable consumer methods to api. Along with others.This
then give you what you need KPNMS is meant to be a port of the JMS api in .NETÂ
And with those methods in 2.0 youd be able to do what you needSent from my
Samsung Galaxy smartphone.
-------- Original message --------From: Justin Bertram <[email protected]>
Date: 09/01/2020 23:04 (GMT+00:00) To: [email protected] Subject: Re:
Artemis: AMQP create queue based on FQQN This seems a little strange to me.The
power of JMS is that it is broker agnostic. It's just an API of fairlygeneric
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, wasmeant to mitigate
that weakness by porting the same basic API to .Net (andthe same goes for CMS
with C++). The goal was to have an API for which anybroker could implement a
client. Early implementations could talk toActiveMQ (via the OpenWire
protocol), Tibco EMS, and IBM WebSphereMQ. Oneimplementation was even
apparently built on Microsoft's MSMQ API. There wasalso a STOMP implementation
and then later an AMQP one. The benefit ofthese two is that they used standard
communication protocols and thereforecould be used with any broker which
supported that protocol. So, forexample, 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 anAPI on top
of it that mirrors the ActiveMQ Artemis address model. Thisruins the
flexibility that AMQP provides and marries client applications toa single
broker. Furthermore, AMQP doesn't "know" about routing types,addresses, and
queues. It has different concepts which we *map* onto theArtemis addressing
model in the broker.The Artemis addressing model is low-level in order to be
able to supportall kinds of different protocols which each have their
ownsimilar-but-slightly-different models.Why don't you just implement the core
protocol in .Net? It appears to methat if you use AMQP you're going to have to
somehow shoehorn in Artemisaddressing model concepts on the client and then
interpret those on thebroker. 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 usedthe core protocol then you'd have access to everything.Aside
from that, what's wrong with the APIs for other AMQP or STOMP clientsfor
.Net?JustinOn Thu, Jan 9, 2020 at 4:12 PM Krzysztof <[email protected]> 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 <[email protected]> wrote:>> > What protocol is the client
going to use?> >> >> > Justin> >> > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof
<[email protected]> 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?> > >> >>
