@Justin
In my humble opinion the greatest power of JMS is also its greatest
weakness, and it's not the fact that its Java based. It's the
specification, that enforces some serious constraints like requirement of
serial execution of consumer callbacks inside the same session, ability to
"recover" session on the client, enforcing transactions on all link actions
(acks and sends) inside the same session, session based acknowledgment etc.
that doesn't add much value from the user perspective, and at the same time
seriously degrade the overall implementation and usability.
I think that from Artemis perspective there is no concept of AMQP
flexibility. As you pointed out, AMQP doesn't "know" anything about routing
types, addresses, and queues (actually it does know sth about addresses ;)
But at the same time it doesn't know anything about topics, queues, shared
durable subscriptions, non shared durable subscriptions, and all that
either. You do not map AMQP concepts onto the Artemis addressing model. You
are mapping qpid-jms implementation to Artemis addressing model. As a
result Artemis amqp provider is so tightly coupled to jms, that if you do
not know the internals of qpid-jms amqp protocol you are forced to either
pre-configure all of your messaging topology upfront on the broker, and use
FQQN, or you can use only some rudimentary features of the addressing
model.
I don't want to implement the core protocol because there is already a
great low level library AmqpNetLite (it is the counterpart of proton in
java world) that I am using as a base for my Artemis client. I don't want
to reinvent the wheel. But at the same time I don't want to adapt JMS
addressing model and concepts because it simply doesn't feel right to me.
It doesn't have to be so complicated.
I was talking with developers from my company for the last 6 months and
collecting feedback regarding NMS.AMQP implementation (that I was working
on) and they were all complaining about the API. Most of the teams ended up
creating their own abstractions on top of it, just to hide the nms bits.
And they haven't even seen jms 2.0 spec. I think in java world it is quite
similar (that's why there are bits like JmsTemplate,
SimpleListenerContainers and the like.
I don't want to impose anything. I just think that Artemis is a great piece
of technology and it is a shame that it's so dramatically unpopular in .net
world. It deserves better. But without a decent client it's hard to hope
for it.
I don't want to shoehorn anything. I think the concept of FQQN provides a
nice loophole for everything I need, besides maybe some minor changes
(creating queues if they aren't created upfront, and basically that's it).
On Fri, Jan 10, 2020 at 12:04 AM 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?
> > > >
> > >
> >
>
