In Apache's ActiveMQ Artemis documentation, there is a statement:
Apache ActiveMQ Artemis does not have a JNDI server. Rather, it uses a client-side JNDI implementation that relies on special properties set in the environment to construct the appropriate JMS objects. In other words, no objects are stored in JNDI on the Apache ActiveMQ Artemis server, instead, they are simply instantiated on the client based on the provided configuration.
Now, I don't understand how does a client, e.g. Widlfly, connect to the standalone Artemis broker. I know there is a client library provided as a Wildfly's module, and I know to configure JMS bridge between local WF queue and remote one. But how does it know how to connect using client's JNDI server? Does it mean that by configuring standalone.xml file of Wildfly you configure JNDI names for looking up resources on Wildfly which are responsible for communication or am I missing something? What the quoted sentence has to do in Artemis' documentation then?
One of the goals of interfaces like JMS and JNDI is to relieve client applications of the burden of having to "know" anything about the underlying implementations. So, for example, an application written using JMS and JNDI can connect to any JMS compliant broker which provides a JNDI implementation. One day a standalone Java application can connect to ActiveMQ and the next day it can connect to WebLogic and all that would need to change is the configuration in jndi.properties.
Any Java application using the JMS and JNDI APIs, whether it's running standalone or in an application server like Wildfly, can connect to ActiveMQ Artemis if the JNDI configuration is correct. As long as you provide the correct JNDI configuration then it will "know" how to connect because all that knowledge is contained with the ActiveMQ Artemis JMS and JNDI implementation and is abstracted away from the application behind the interfaces.
The section you quoted from the ActiveMQ Artemis documentation is simply to explain to users that there is no network client/server communication when using its JNDI implementation. This is, for example, in contrast to Wildfly which does implement a "real" JNDI server and whose JNDI client does communicate over the network to look up objects.
Where objects are physically stored depends on what JNDI implementation you use. If you're using the Wildfly JNDI implementation then objects are stored on the server and any client communicates with the server to look up those objects. If you're using the Artemis JNDI implementation then objects are stored in the actual client-side JNDI implementation. Whether or not classes are modularized has no impact on the JNDI lookup.
Java objects stored in JNDI can be any kind of Object. The JNDI implementation doesn't care what kind of Object it is. You can store an Artemis JMS connection factory pointing to a remote Artemis broker in Wildfly's JNDI. If you have such a configuration and a JMS application in Wildfly looks up this Artemis JMS connection factory from Wildfly's JNDI then the JMS connection factory implementation itself will communicate with the remote Artemis broker.
Additional notes:
JNDI is not a protocol. It's just an API.
If you're using the Artemis JMS client in Wildfly it will certainly not be using JNDI to call objects on the remote Artemis broker. As noted previously, the Artemis JNDI implementation is client-side only. It performs no network communication whatsoever. The Artemis JMS client implementation performs network communication using its own "core" wire protocol.
ActiveMQ Artemis is most commonly used standalone so it needs its own JNDI implementation to facilitate JMS compliance.
Instructions on how to use the ActiveMQ Artemis JNDI implementation are in the documentation you cited previously.
Related
I wonder if it is possible to configure message redelivery on the client side. I have read the ActiveMQ Artemis docs and have not found any information about this feature. So I made a conclusion that there is no opportunity to configure message redelivery on the client side. The only place to configure message redelivery is the broker.xml file. Am I right about it?
By the way I can configure the connection to ActiveMQ Artemis by using broker URL params or by application.yml since I using Spring Boot 2.x.
ActiveMQ Artemis supports AMQP, STOMP, MQTT, OpenWire, etc. Many clients exist for these protocols written in lots of different languages across all kinds of platforms. Whether or not a given client supports client-side redelivery is really up to the client itself. You don't specify which client you're using so it's impossible to give you a specific yes/no answer.
However, I can say that ActiveMQ Artemis ships a JMS client implementation which uses the core protocol. That client does not support client-side redelivery. However, the OpenWire JMS client shipped with ActiveMQ "Classic" does support client-side redelivery, and it can be used with ActiveMQ Artemis as well.
I am trying install ActiveMQ Browser, and I wanted to connect with my ActiveMQ Artemis server. How do we configure that?
I assume you're talking about this ActiveMQ Browser GUI tool.
If that assumption is correct then there's no way to integrate it with ActiveMQ Artemis as it's hard-coded to use the specific JMX management beans from ActiveMQ 5.x.
I recommend you use the ActiveMQ Artemis web console. It has a rich set of functionality that should cover most of the use-cases you're interested in. Among other things, it will allow you to:
Send new messages to addresses.
Delete messages.
Move messages to another address.
Create or delete addresses & queues.
Shutdown broker.
etc.
We test Apache Artemis. We actual use ActiveMQ 5.x
We send messages from our Software to the broker like the URI:
localhost:8161/api/message/QueueName with a POST-Request, but this doesn't work in Artemis. I looked around but I didn't find how it should be in Artemis.
Do you know how we can do that?
As noted in the documentation for the REST interface, the default broker doesn't deploy the necessary HTTP endpoints. You'll need to configure and deploy the REST interface as described in the documentation.
That said, the REST interface in ActiveMQ Artemis is different from the one in ActiveMQ 5.x. The two are not compatible.
We have two applications which is running on Weblogic and JBoss AS respectively. We would like to Keep HornetQ as an intermediate server for Asynchronous messaging.
I would like to write a Publish/Subscriber. Whenever a data Inserted/Modified/Deleted(JPA) or whatever possible messages it could be.
Here Producer will be the Weblogic and consumer will be the JBOSS. How can i achieve it?
On wls end define a foreign jms server. Point it to the hornetq topic. Your application on wls will publish
Messages to foreign jms and your application on jboss can consume it.
When defining foreign jms make sure you provide user credentials for both the topic and jndi look up as needed.
I think You could use JMS bridge between wls and JBoss:
http://docs.jboss.org/hornetq/2.3.0.CR2/docs/user-manual/html/jms-bridge.html
From architecture point of view, I was wondering what would be the best practice on an integration scenario with 2 application and OSB as Middleware: JMS Consumer runs over JBoss while OSB application encapsulates a service provider. Should JMS Queues reside on the JBoss (foreign server) or on WebLogic Server? That is, If I get to choose, JMS Server should be on consumer or producer side? What would be the pros and cons?
Thanks in advance.
It depends on your needs, you can create a foreign destination in your web logic server that connects to the producer queue in the producer end. In this arrangement your consumer will listen in the local end of the foreign destination that connects to the producer queue.
I can think of the following benefits:
A> Foreign Destinations are mapped to WebLogic JNDI tree, any MDB that you deploy to the server can simply reference the remote destination using its local JNDI name.
B> As you are directly communicating with the remote resource there is no lag / latency in delivery etc.
C> One issue maybe you will not be able to produce messages in the consuming end because this user may not have enqueue access to the queue. But it all depends on your setup. This maybe required for some cases like testing etc.