[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: Unofficial ActiveMQ Artemis .NET Client
From:       Havret <havret () apache ! org>
Date:       2021-12-29 15:27:03
Message-ID: CAODH0L3ixOX45B3i2oFWAxCzDi9hJj-WewVYbdJC-EdALgnXxw () mail ! gmail ! com
[Download RAW message or body]


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
<michael.andre.pearce@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 <h4vret@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
> <michael.andre.pearce@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 <h4vret@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/0c7a165c77744ff1d00425 \
> 11e6d5afc44a3e38e2/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 <jbertram@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 <h4vret@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
> 
> 
> > 
> 
> 
> 
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]