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 <michael.andre.pea...@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 <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 > > > > > >
