Re: Unofficial ActiveMQ Artemis .NET Client

[Havret <ha...@apache.org>]

Actually, the Kafka community is really open and actively promotes all
open-source clients. :) -->
https://cwiki.apache.org/confluence/display/KAFKA/Clients

On Fri, Feb 5, 2021 at 2:53 PM Michael André Pearce
<mi...@icloud.com.invalid> wrote:

>
>
> You can actually send management messages in via NMS/JMS, so again not so
> sure we need to be maintaining two clients here.
>
> I would expect if something to do some extra bits, via management address,
> to make some kind of management client, that a wrapper over the NMS could
> be done there.
>
> Again an i re-iterate, i would encourage contribution to extend the NMS
> client where needed here, not divergence.
>
> On a separate note, re just adding docs pointing to your project, which is
> a not an ASF sister project, I think we want to be careful going down that
> route too much, as an Apache project it gets us into some murky waters, i
> don't think we need or want to go down.
>
> e.g. we then open ourselves to having to accept every request to link to a
> client project, to keep things fair, and then further what about propriety
> clients, that would end up in a very odd position, im not sure where we
> even stand, with an Apache ASF project essentially promoting a NON open
> source tool, should someone then insist we promote theirs too.
>
> If you look at Kafka eco system, it provides very few clients, but in
> actual fact it is well known there are clients in nearly all languages,
> many/most actually developed outside the Apache Kafka project, and even in
> some cases for the same language there are a couple of clients on offer.
> But the Apache Kafka project does not list or promote those.
>
> Best
> M
>
>
>
>
>
>
>
>
>
>
> On 5 February 2021 at 10:44, Havret <h4...@gmail.com> wrote:
>
> Hi Mike, thanks for the feedback,
>
> I totally get it. My main inspiration in this regard was RabbitMQ .NET
> Client, which of course works on AMQP 0.9.1 and (AMQP 1.0), but actually
> uses a proprietary protocol build on top of the mentioned (the same as
> ActiveMQ Artemis). Theoretically one could use NMS to talk to RabbitMQ but
> nobody does that. At least in the .NET world. This library is not to
> replace NMS.AMQP, it just to give the devs a simpler alternative. It is
> something between AmqpNetLite which is too low level and NMS.AMQP which is
> too overengineered (and constrained with many JMS-specific requirements),
> has a really high learning curve and requires additional tooling (spring
> container) just to start using it.
>
> I asked my initial question because I was looking for ActiveMQ Artemis
> counterpart of this page https://www.rabbitmq.com/devtools.html I didn't
> find one, so I asked.
>
> On Fri, Feb 5, 2021 at 10:37 AM Michael André Pearce
> <mi...@icloud.com.invalid> wrote:
>
> My points on this is two parts:
>
>
> 1) This only works for Artemis if this was the case, i would have expected
>
> an "Artemis" specific client to work on the CORE protocol level.
>
> 2) The point of NMS is its an API, and actually the NMS AMQP client has
>
> tested compatibility with ActiveMQ Classic, ActiveMQ Artemis, Solace, and
>
> because its agnostic should work with any other AMQP broker, thats working
>
> like with QPID clients.
>
>
> The main short coming of NMS atm is lack of task async api, and thats been
>
> acknowledged, but this is being added with the NMS 2.0 work, thats in
>
> progress as you know thats in PR.
>
>
> Obviously there's nothing stopping you continuing to maintain the client
>
> externally as its own project.
>
>
> For these reasons im personally not keen on supporting this/bringing this
>
> under the Apache ActiveMQ sub banner, i dont have the time, id rather if
>
> people feel something is missing in existing solutions, that they
>
> contribute there.
>
>
>
> On 4 February 2021 at 20:38, Havret <h4...@gmail.com> wrote:
>
>
> Hi Justin,
>
>
> You made an excellent point. I will try to answer as thoroughly as I can.
>
>
> AmqpNetLite is a .NET implementation of AMQP 1.0 protocol. It gives you
>
> full control and all the building blocks you may need to communicate using
>
> AMQP 1.0. Unfortunately, to use it properly, you need to write quite a lot
>
> of tedious boilerplate code. For instance, in order to create a connection,
>
> you would need to write sth along these lines:
>
>
>
> https://github.com/Havret/dotnet-activemq-artemis-client/blob/0c7a165c77744ff1d0042511e6d5afc44a3e38e2/src/ActiveMQ.Artemis.Client/Builders/ConnectionBuilder.cs#L10-L53
>
>
> The same rule applies to other resources like producers, consumers,
>
> sessions, etc.
>
>
> Having all this implemented one would only utilize the most basic features
>
> of ActiveMQ Artemis. There is however a good chunk of functionalities that
>
> require subtle knowledge specific to ActiveMQ Artemis implementation built
>
> on top of this protocol. For example things like scheduled message
>
> delivery, scheduled delivery delay, message selectors, attaching to
>
> address/queue based on routing type, fully qualified queue names, just to
>
> name a few. All these bits are not part of the original protocol and are
>
> proprietary to this specific implementation.
>
>
> My library packs all these scraps of knowledge into a simple strongly typed
>
> SDK, that can be used by any developer without the knowledge that to define
>
> a message selector on your consumer you need to add to FilterSet property
>
> of Source frame described value apache.org:
>
> selector-filter:string=0x0000468C00000004L.
>
>
> Besides that, it adds things that are not included in the raw AmqpNetLite
>
> by design but are pretty useful in real-life situations, like automatic
>
> recovery.
>
>
> The thing that I personally (and my fellow .NET developers :)) missed the
>
> most after switching from RabbitMQ to ActiveMQ Artemis is the topology
>
> management functionality built right into the client. In RabbitMQ .NET
>
> client, this is a first-class citizen, and there are extremely popular
>
> frameworks like NServiceBus and MassTransit that make heavy use of it.
>
> JMS/NMS 2.0 features like durable subscriptions try to compensate for the
>
> lack of this functionality to some extent, but unfortunately are far too
>
> limited. So this is the other thing that this library introduces, and that
>
> was welcomed with great enthusiasm when I showed it to my colleagues.
>
>
> As the lib doesn't implement nms/jms it is much simpler. You don't need a
>
> spring container, caching connection factories, single connection
>
> factories, etc, and the knowledge of how to configure and use them. You
>
> just need to create your producers and consumers and you're ready to go.
>
> Everything is thread-safe, so you don't need to worry about creating
>
> explicit memory barriers, etc.
>
>
> I started this library as a playground for experimentations while
>
> implementing nms-amqp, but in time it evolved into sth else. My current
>
> goal is to create a simple well-documented library that will make the
>
> adaptation of ActiveMQ Artemis as simple and non-intrusive as possible.
>
>
> I hope my reply is not too chaotic and answers your question at least to
>
> some extent.
>
>
> All the best,
>
> Krzysztof
>
>
> On Thu, Feb 4, 2021 at 3:14 AM Justin Bertram <jb...@apache.org> wrote:
>
>
> The docs [1] indicate that the client is "a very lightweight wrapper around
>
>
> AmqpNetLite." If that is the case why is it advertised as the "ActiveMQ
>
>
> Artemis Client for .NET"? Couldn't it be used for *any* AMQP 1.0 use-case?
>
>
> How is it different from AmqpNetLite? What specifically does the wrapper
>
>
> provide?
>
>
>
> Generally speaking, one of the nice things about implementing standardized
>
>
> protocols in the broker is that anybody can implement clients and those
>
>
> clients exist completely independent of the broker. There are *lots* of
>
>
> clients for STOMP, AMQP, and MQTT written in lots of different languages
>
>
> for all kinds of different platforms. If we cited your client in the
>
>
> documentation then someone could logically ask why we don't also cite
>
>
> client X in the documentation as well. Clients come and go over time and in
>
>
> my opinion it would kind of be a drag to develop and maintain a list of
>
>
> these clients.
>
>
>
>
> Justin
>
>
>
> [1] https://havret.github.io/dotnet-activemq-artemis-client/
>
>
>
> On Wed, Feb 3, 2021 at 3:21 PM Havret <h4...@gmail.com> wrote:
>
>
>
> > Hi Guys,
>
>
> >
>
>
> > I have been working for over a year now on unofficial ActiveMQ Artemis
>
>
> > Client for .NET, and a set of extension libraries that make its
>
>
> integration
>
>
> > with .ASP.NET <http://asp.net/> Core projects as seamless as possible.
>
>
> > Recently I have written an article describing how to use it on my blog.
>
>
> Do
>
>
> > you think there is any space in Artemis docs to include it, so it would
>
>
> be
>
>
> > easier for .NET folks who are thinking about using Artemis to find it?
>
>
> >
>
>
> > I've reached Clebert in the first place, and he suggested sharing this
>
>
> > here.
>
>
> >
>
>
> > I am sending you links so you could check it out:
>
>
> > article: https://havret.io/activemq-artemis-net-core
>
>
> > repository: https://github.com/Havret/dotnet-activemq-artemis-client
>
>
> > extensions: https://github.com/Havret/activemq-artemis-extensions
>
>
> > docs: https://havret.github.io/dotnet-activemq-artemis-client/
>
>
> >
>
>
> > Thanks,
>
>
> > Krzysztof
>
>
> >
>
>
>
>
>