Axon Framework supports Distributing Events which should allow to post events to the external message broken and read events from message broker.
Amazon provides two different messaging services
Amazon Simple Queue Service (SQS)
Amazon MQ
Questions:
What Amazon messaging service might be used (SQS, MQ or may be both) as message queue with Axon Framework?
What is the best practice for implementing distributed Axon message processing in Amazon EC2 cloud?
It looks like that Amazon MQ should work fine with Axon Framework as message queue because it supports AMQP. But I failed to find any references about any practical experience using MQ with Axon.
Any messaging service implementation which supports, AMQP should work just fine with the Axon Framework. More specifically together with the axon-amqp dependency, as you might already have found out.
Without personally having any experience with Amazon SQS or MQ, I did a quick search on both, and it seems Amazon MQ is indeed the go to solution to distributed your events on Amazon EC2.
I do not have or heard any best practices for distributed your Axon Framework events over Amazon EC2 specifically, sadly enough, but I can share this.
All the Axon Framework (when adding the axon-amqp dependency) does, is subscribe to the EventBus and publish any incoming events on a queue; no further specifics.
Hence I'd say any best practices for general use of Amazon MQ should apply on your second question.
Related
We've started our journey on a hybrid setup where we use a BizTalk on-prem and other teams in the company is working in Azure and want to use BizTalk as the glue between on-prem stuff and Azure, and since Service Bus is the new hyped thing, everyone is talking about that's where eve-ryone is going because messages can be handled async.
My team didn't get much choice in terms of talking solutions etc. how to handle this, the other simply decided to just go with a service bus straight up and pay for a premium tier to allow filers larger than 256kb, however even in BizTalk 2020 the SB-Messaging adapter does not allow larg-er than 1 MB because it runs on the SBMP protocol and not AMQP as the later SDK versions which is described on Microsoft’s own documentation.
We would have preferred to use AzureBlobStorage adapter with an event driven design that send a message to the SB that a message is available, but we’re force by their choice to go with a service bus, however since we’re limited to 1MB size because of the protocol and it seems like Microsoft does not plan on implementing AMQP protocol for the SB-Messaging anytime soon, CU4 does not change anything.
I was wondering if anyone else has found ways around this other than just straight up code our own adapter since each internal department doesn’t talk with each other at Microsoft and get-ting our internal to change their mind is a challenge on its own.
Tried updating BizTalk and searching far and wide if anything has solutions for this, I'm hoping for a workaround or just the confirmation that we need to develop our own SB-Messaging adapter that supports AMQP
I'm trying to create a C# program using ActiveMQ.
The main goal here is to experiment how to use ActiveMQ to send push messages to a client from a server which is supposed to be the message broker using the pub/sub pattern. The clients are web clients which are implemented with React.
There's an official link which suppose to have .NET examples of using ActiveMQ:
https://activemq.apache.org/components/nms/documentation#providers
What is the difference between the providers listed? What provider do I need to use in order to achieve my goal listed above? Is using this method means using ActiveMQ Artemis?
The Openwire based NMS client (NMS.ActiveMQ) speaks a protocol that supports most JMS style behaviours and is interoperable on both ActiveMQ 5.x and the more actively developed ActiveMQ Artemis.
Is it possible to scale out SignalR using Windows Server Service Bus?
I found sample of doing it with Redis, and I know there are libraries in GitHub for SQL Server (although I couldn't find a working sample for that), but I would like to implement it using the new on-premises Service Bus.
Any ideas / references?
Thanks!
In theory yes. The current stable versions support the Azure Service Bus, the latest source includes a rework of the scaleout providers such that even if it doesn't work out of the box (as the two service bus solutions are designed to have API parity) it should be straightforward to implement.
The service bus scaleout is enabled using its DependencyResolverExtensions class.
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
Both solve completely different problems:
An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
An RPC system provides client and server technologies for performing RPC operations.
NServiceBus and MassTransit are two tools that can be used to implement messaging with MSMQ and other message queues.
I find that once you start using messaging to have applications talk to each other, you don't really want to go back to the old RPC style.
My question is, what other tools are out there? What tools do you use?
Apache ActiveMQ is probably the most popular and powerful open source message broker out there with the most active open source community behind it as well as commercial support, training and tooling if you need it.
One of the more interesting aspects of ActiveMQ is its wide support for a large number of different language bindings and transport protocols
WebSphere Message Broker is IBM's flagship ESB which runs ontop of MQ.
They also produce WebSphere ESB which is a slightly lighter offering which specialises in ESB across web services.
We use WCF services for synchronous message based operations, and nServiceBus for anything asynchronous.
Rogue Wave is very popular [ http://roguewave.com/products/hydra/ ]
So are IBM's Websphere offerings [ http://en.wikipedia.org/wiki/Mqseries ]
WCF is extremely powerful and should be looked into by anyone in the .NET space starting up a message based system.
I would recommend against BizTalk unless you can make a lot of use out of it's adapters (ie. you have a lot of old systems to communicate with).
Nuedesic makes a great WCF based ESB, Neuron, if you are willing to pay a bit.
I use IBM software stack because it has the widest set of features (pub/sub, async, sync) and platform support (60+ combination of platform, languages) and also a great set of free tools provided by IBM
For Operations, I use use the linear log rotation IBM WebSphere MQ supportpac
For development and testing, I like RFHUTIL to generate fake cobol, java, MS objects, other binary and text objects and SOAPUI to invoke HTTP web services. If I need to invoke MQ based web services, I go back to RFHUtil. Of course Websphere MQ Explorer for admin.
We use the old WebSphere Message Broker 6.1 (now IBM Integration Bus) that is fast and reliable once you are acquainted.