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 <h4v...@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 <jbert...@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 <h4v...@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
