Push-subscription
Is there a way in springboot or quarkus (or other framework) to consume messages from IBMMQ using push-subscription. I.e Not polling every minute to see if message exists.
Need not be JMS api.
The DefaultJms... in springboot is polling 1000x times more than the actual messages per day. It is not behaving as ' listener waiting for message push'
You could consume messages from IBM MQ using vert.x's AMQP client. This is a reactive toolkit that will give you an easy way of communicating with IBM MQ using the AMQP channel. Vert.x's AMQP client listens and reacts for push from IBM MQ.
What exactly is Solace JCSMP?
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
What exactly is Solace JCSMP?
JCSMP is the Classic Java API for Solace's SMF (Solace Message Format) protocol. Note that Solace recently introduced a more modern messaging API for java devs using their event brokers that is just referred to as the "PubSub+ Messaging API for Java". If you are new to Solace and using Java it may make sense to use that instead of JCSMP.
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
JCSMP allows developers to take advantage of the full feature set offered by the Solace Broker whereas the Solace JMS implementation only covers the features defined in the JMS specification itself. For example, use of Solace features such as Replay or having Queues subscribe to Topics are not programmatically possible via the JMS API and would have to be done administratively if using JMS.
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
Solace PubSub+ Event Brokers provide protocol translation between any of the protocols supported by the broker. It doesn't matter whether you are using SMF (which both Solace JMS and JCSMP use), MQTT, AMQP 1.0, etc. or what programming language you are using. For example when you send a message using JCSMP you can receive it using a Java app using JMS, a Python app using AMQP and a Go app using MQTT. The Solace Event Broker even has support for calling a RESTful webhook using it (Check out Solace "Rest Delivery Endpoints"). Just a heads up that if you're using headers you'll want to checkout the Solace docs to see how they're mapped during protocol translation.
I have 2 spring boot applications
On-premise teller application
Cloud based multi-tenant application that aggregates data from all teller applications
The teller application has to work offline(if connectivity is down) as well. What is the best approach to broadcast events from the teller application to the cloud. I would not prefer to implement code to persist events.
What is the best approach? ReST/message broker or some other approach. If using a message broker, will the spring cloud stream abstraction queue events when the connection to the broker is down and retry.
I would go with the message broker (rabbit, kafka) and spring-cloud-stream, since your use case was exactly what/how it was designed.
The microservcice (your app) is a consumer of the broker, that is: it can publish to and/or consume events from the broker. If the app is down the broker is up and potentially collecting events destined to the down app. Once app is up it consumes queued up events and so on.
I'll stop here given the general nature of your question but feel free to follow up with more details.
We develop NMS product that has been deployed by couple of telecom operators. Our application (uses ActiveMQ) will publish Fault notifications to the Fault Queue, the messages are set to be persistent. These messages are consumed by third party JMS clients. Not all the customers will have a notification client to consume the events(some of the deployments will not have any subscriptions). The question is, does ActiveMQ persist the messages if the queue never had a subscriber connected to the Queue?.
The Broker will persist messages to a Queue regardless of the presence of consumers when the message is tagged as persistent. That is the general contract of the Queue model.
How does RabbitMQ compare to Mule, I am going to build an application using message oriented architecture and AMQP (RabbitMQ) provides everything i want, but i am perplexed with so many related technology choice and similar concepts like ESB. I am having a doubt if i am making a choice without considering other alternatives.
I am mostly clear that RabbitMQ is a message broker and it helps me in mediating message between producer and consumer (all forms or publish subscribe and i could understand how its used from real examples like twitter , or Facebook updates, etc)
What is Mule, if i could achieve what i do in RabbitMQ using mule, should i consider mule similar to RabbitMQ?
Does mule has a different objective than that of a message broker?
Does mule assumes that underlying it there is a message broker that delivers message to the appropriate mule listeners (i could easily write a listener in RabbitMQ)
Is mule a complete Java bases system ( The current experiment i did with RabbitMQ took me less than 30 Min to write a simple RPC Client Server with client as C# and Server as Java , will such things be done in Mule easily).
Mule is an ESB (Enterprise Service Bus). RabbitMQ is a message broker.
An ESB provides added layers atop of a message broker such as routing, transformations and business process management. It is a mediator between applications, integrating Web Services, REST endpoints, database connections, email and ftp servers - you name it. It is a high-level integration backbone which orchestrates interoperability within a network of applications that speak different protocols.
A message broker is a lower level component which enables you as a developer to relay raw messages between publishers and subscribers, typically between components of the same system but not always. It is used to enable asynchronous processing to keep response times low. Some tasks take longer to process and you don't want them to hold things up if they're not time-sensitive. Instead, post a message to a queue (as a publisher) and have a subscriber pick it up and process it "later".
Mule is a "higher level" service implemented with message broker. From the docs
The messaging backbone of the ESB is
usually implemented using JMS, but any
other message server implementation
could be used
You can build an ESB with rabbit; however, you're going to be limited to sending byte[] packages, and you'll have to build your system out of messaging primitives like topics and queues. It might be a bit faster (based on absolutely no benchmarking, testing or data) because there are fewer layers of translation. Mule provides an abstraction on top of this, speaks a variety of transports, and can handle some routing logic.
Mule is a Enterprise service bus providing end to end integration solution where as Rabbit is message broker for queueing messages between subscriber and receiver.
RabbitMQ, a open source message broker software is written in Erlang programming language and is built on Open Telecom Platform for clustering and failover. It is easy to use, supports a huge number of developer platforms and runs on all major operating systems. It works on a concept called Exchange.
Mule connects RabbitMQ with AMQP connector.