ActiveMQ Modified Broker - message

I wanto to write a modified ActiveMQ broker that when he listens to producers' messages of a specific topic to handle them alternatively (use HDFS API for example and not use default persisten store). Do you have any ideas where to start with?
thanks in advance,
Petrucci

You could either implement your own ActiveMQ message store for HDFS which would allow ActiveMQ to use HDFS as a persistence store, or you could create an ActiveMQ broker plugin which would allow you to intercept messages as they enter the broker. Both are very different approaches, so it really depends on your requirements as to which path to take.
Bruce

Related

Isolated topic namespace for MQTT

Considering MQTT's pub/sub behavior, topic namespace is not isolated and any user can access every other user's data on a topic.
I've seen services like flespi which claim they provide isolated name spaces but some of them use containers to isolate users...
Is it possible to modify an MQTT broker, e.g. Mosquitto, for that purpose? Or is there such open source broker?
Mosquitto can set access control to topics based on authentication username. This allows the administrator to restrict access to topics and restrict which clients can subscribe, publish or receive messages on particular topics. This is documented in Mosquitto’s documentation.
For greater flexibility you can also use the dynamic security plugin, or the mosquitto-go-auth plugin which allows you to use a variety of different data sources for authorization and ACL configuration.

Restricting / Protecting Topics with MQTT and Solace

I'm working toward an event-driven simulation infrastructure using Solace's PubSub+ for MQTT as a broker. I have a type of control message topic prefixed by control/.
Is there anyway to protect/restrict publish access to this topic prefix (or specific topics in general) to one authenticated user (i.e. the controller node)?
Thank you for your time!
yes indeed there is! What you are inquiring about is configuring access control list under the Client Authorization. Check out more information about ACLs in the docs here. ACLs are configured on the broker management console, so whether you are using a local broker (via docker for example), cloud solution (Solace Cloud) or an appliance, you access your ACLs from the "Access Control" tab and configure your users and topic subscriptions. You can also check out the Solace Community forum where you can see a bunch of people asking questions about Solace related concepts and messaging in general.
Note: if you are using MQTT to connect to the broker, you can create a username on the broker with predefined authentication. You will use this authentication during your mqtt client connection.

MQTT subscribe to # topic allows the user to read all messages?

I was reading this about topic subscription. So if I subscribe using a wild card, to the # topic, then I will receive all the messages.
Does that mean I could intercept the communication? When someone is publishing a message to a secret topic, then I will also get it.
Obviously that is not the case. But what am I missing?
On a related issue, how does the broker prevent users from subscribing to specific topics or publising to other? I assume not anybody can just send data to a broker. Is it somehow similar to HTTP?
With the basic out of the box configuration, anybody can connect to the broker and subscribing to # will get all the messages published and you can publish to any topic you want.
The MQTT protocol includes support for authentication as part of setting up a connection to the broker. Once you have an authenticated user it becomes possible to apply rules to what that user can do. Different brokers implement how create those rules in different ways, but mosquitto has support for ACLs.
With the ACL you can define what topics a user can subscribe and publish to. The built in mechanism for this is a flat file, but there is also support for a plugin system that allows you to keep username/password and allowed topics in a database. This allows the ACL to be easily updated without having to restart the broker.

Pushing MQTT through Node-Red to webpage

I just simply cant get it to work.
How can you push an incoming MQTT value to a php page in a Node-Red flow?
"1" is sent to topic "test", I then would like this to be pushed to a blank PHP page, just a simple "1". I do not want the PHP site needed to be refresh.
Appreciate all the inputs I can get! Thanks. :)
If you want truly instant updates then you have 2 real options
Skip Node-RED all together and just subscribe to the same MQTT topic using MQTT over Websockets and the Paho Javascript client. This requires the broker to be running a Websockets listener, but most of the major brokers support this these days.
Use the built in Websockets nodes to provide updates to the web pages. You will need to add a Websocket client to the page and then connect back to a pair of Websocket nodes (input/output) and wire in a MQTT subscriber node. An example Websockets flow can be found here

Can Fuse ESB implement message broker and message queue

I'm a really newbie in ESB (you can say no experience).
And actually I haven't really understood the real meaning of ESB.
My expectation of ESB is a middleware that can connect to whatever the client is
(.NET, Flex, Ajax, Android, etc.).
And I expect that ESB can implement MESSAGE QUEUE.
Cause I'm really really interested in message queue.
I just tried Mule ESB.
I successfully created SOA request-response.
But it seems that Mule ESB doesn't have message queue.
AND MY QUESTION IS:
Is it possible for Fuse ESB to implement message queue?
Thank you,
Rizki Sunaryo
Yes Fuse ESB has a message broker embedded (its Apache ActiveMQ). So you have that out of the box with Fuse ESB.
You can also with Fuse ESB connect to an external message broker of choice, using JMS as the protocol. For example to connect to a WebSphereMQ, WebLogicAQ, etc.
There is also a standalone Fuse MQ product that is just the message broker. So if you only want a messaging system, then you can go for Fuse MQ.
You can find some details here
http://fusesource.com/products/fuse-esb-enterprise/
http://fusesource.com/products/fuse-mq-enterprise/
Red Hat has since acquired FuseSource so the Fuse products is being rebranded as JBoss Fuse, and JBoss A-MQ. You can find details here:
http://www.redhat.com/products/jbossenterprisemiddleware/fuse
http://www.redhat.com/products/jbossenterprisemiddleware/amq/

Resources