I have two systems: HQ on Linux and Active MQ on windows
Both systems need to send and receive message between each other.
Anyone implemented a way of integrating between them?? In this case I would like to have an example
Thanks,
ray.
JMS providers in general are not interoperable, because there is no common internal message format, or the connection protocol.
The perfect solution would be unifying the providers, so that both systems use the same (could be different instances — don't know about HQ, but ActiveMQ can send to another ActiveMQ).
If this is not acceptable, you can always write adapters yourself, with message-driven beans. One MDB would listen on an MQ queue, to repack the message and forward to ActiveMQ; the other MDB would do the same other way round. The exact setup and configuration of connection factories and queues depends on the application server.
ActiveMQ provides a solution for this scenario, its called a JMS to JMS bridge this allows you to bridge destinations between JMS brokers either inbound, outbound or both. Have a look at the documentation at the link above.
Related
I am working with several different services which have been written in Python and Java. I have now come to the point where I need to have these services communicate with each other and ActiveMQ seems to be a sensible choice.
However, I am not sure I quite follow the concept of the different protocols available for ActiveMQ. The main question being, do I have to implement all my services to use the same protocol for accessing the bus?
Is it possible to run the same bus with multiple different connection protocols concurrently?
If yes to 1. Is it just connection to the bus which is governed by a Protocol or does the protocol choice also influence the type of the actual message content. I.e. will it be possible to post a message from Java JMS to a topic and have a Python STOMP client read that message correctly?
Inter language interopability can be made by different clients using the same protocol, such as JMS for Java, CMS for C++ and NMS for .NET (when it comes to OpenWire). I don't think there is a great OpenWire Python client out there, except some CMS wrappers.
On the other hand, ActiveMQ does a great job to bridge between different protocols so that they can share the same queues/topics. It works really well to read stomp, MQTT and AMQP messages sent from OpenWire/JMS. Please be aware that you may want to avoid advanced features of say JMS like MapMessage, rely on specific JMS headers and stick to simple text messages or byte messages. The bridge is not 100% transparent, but as I said, does a great job.
So, you can go with stomp or even AMQP 1.0, some instruction from Microsoft here.
I'm confronted with a system (Java, OSGI-based, Equinox, Blueprint) that needs to send asynchronous notifications via SOAP messages to a remote system. The system must ensure that the notifications reach the remote system (i.e. it reponses with a confirmation message, WS-ReliableMessaging is not available).
Now I see two Options:
Use the EventAdmin mechanism of OSGI to trigger the notifications, implement my own handler which persists the notification in a queue. A quartz job would poll the queue and try to send the Soap message. The message would only be removed from the queue if the remote system reponses successfully.
Use a messaging middleware like ActiveMQ (e.g. as part of Apache Servicemix) to make use of JMS and make the whole task a lot easier.
What do you suggest?
Take JMS, if you go for 1 you'll end up implementing some of the stuff that is already provided by a JMS system. OSGi events are nice, but after a shutdown of the container they are gone. So this will be at least one of the drawbacks that you'll have to re-implement that a JMS messaging system like ActiveMQ already provides.
I am getting into Message Queueing recently (with ActiveMQ) and experimenting.
So far I have been able to set up one producer with 2 consumers written in Java implementing JMS over Tcp. The producer sends 2 types of messages to the queue in ActiveMQ, while at the other end, 2 consumers from a different machine pick up the messages based on the message properties.
My question was:
Does the consumer/producer need to implement the same protocol, or
Would it be possible to have a producer send messages to the Queue with JMS and
have a client (like node js) use another protocol (like AMQP) and collect messages from the same queue?
Thank you for your advice,
Probably the answer to your question is documented at Oracle's JMS as a MOM Standard:
It’s important to note that JMS is an API standard, not a protocol standard. Because all JMS clients implement the same interface, it is easy to port one vendor's clinet to another vendor's JMS provide implementation. But different JMS vendors typically cannot communicate directly with one another.
ActiveMQ implements the standard JMS client library using it's own protocol (OpenWire) however it also supports several other protocols allowing you to connect from other client like an MQTT client, STOMP client or an AMQP client and consume / produce from a Queue.
To see how to use AMQP for instance refer to the ActiveMQ docs and for best results use the latest release of ActiveMQ.
I need to enhance the JMX interfaces of a distributed java application. The reason for choosing JMX is the simplicity of exposing data. These distributed apps exist in several different machines connected to a JMS server (activemq 5.7) (which in turn is connected to another JMS server to bridge 2 networks, also activemq 5.7).
What I would like to do, is to be able to access the remote JMX interfaces on the individual servers from anywhere on the JMS network. I would nee full JMX access as if accessing through the usual RMI interface. That means every type of action.
I understand I could use lingo to make the remote jmx interfaces talk to the JMS server, and from there my bridge should allow me access to them (assuming its configured correctly).
Is this a good approach? has anyone tried lingo for this purpose? Are there other options out there I may have not found?
A plan B could be to use apache camel RMI module, but it seems like if lingo is an option, it will be much more plug & play than this.
I think it's not a bad way to go. The one downside of using JMS that I can think of, off the top of my head, is the dependency on a broker, which most JMS implementations rely on.
On the other hand, it does present some interesting capabilities like discovery, asynchronous JMX invocation and pub/sub multicast style JMX operations where you could issue one operation request and receive back a response from all your MBeanServers.
I am not aware of any actual implementations, but it's probably not too difficult to implement. You simply need a configured client on each target JVM that will:
Listen for JMX requests: The listener will unmarshall the request (which should be an encoding of an MBeanServerConnection method invocation). Use a common topic for pub/sub style invocations, returning the marshalled result
to the destination specified in the JMSReplyTo property in the request message. Otherwise, you could allocate a queue per JVM, or pick a unique identifier for each JVM and use message selectors.
If you want to implement JMX notifications, you will need to implement a proxy NotificationListener that registers for the desired notifications and forwards them to the designated JMS destination on receipt.
You may also consider implementing a full blown javax.management.remote implementation which may integrate more smoothly into your environment by virtue of the standard adherence.
I have found the OpenDMK project very useful for extending/implementing JMX servers and clients. The library provides the basic building blocks for implementing a standard JMX remoting solution using a "custom" protocol. Basically, you implement a javax.management.remote.generic.MessageConnection which serves as the transport and invocation mechanism. All JMX invocations, responses and callbacks are serialized
into instances of javax.management.remote.message.Message, and they're all Serializable so you should not have any issues writing them into and reading them from JMS ObjectMessages.
A couple of additional benefits you will get from this approach are:
Provided you configiure the classpath correctly, you should be able to connect to your JVMs using any standard JMX tool such as JConsole.
The OpenDMK also provides the ability to federate MBeanServers which makes all your MBeanServer instances appear, and be accessible through one central MBeanServer. This feature requires a standard JMX remoting
implementation.
The OpenDMK also implements an interesting service discovery protocol, and it comes in a couple of different flavours including raw multicast and a "phone-home" approach which would mesh nicely with your JMS protocol.
I posted a mavenised project of the OpenDMK here if you're interested.
I am implementing a basic JMX client for java-agents using netty, and it optionally supports asynchronous JMX requests. Responses are delivered through a registered listener which is like a "reverse" MBeanServerConnection. In case this is useful, find the source here.
Jolokia (http://www.jolokia.org/) is also a great project for remote accessing JMX using REST and JSON. It does this automatic for you. And support batch operations as well.
I suggest to take a look at that.
If you use JMX to get AMQ statistics then it offers a plugin, so you can just using JMS messaging to get the stats instead of JMX: http://activemq.apache.org/statisticsplugin.html
I would use JMS to discover the URLs of the servers I am interested in and use plain JMX from then on. I don't see the advantage of sending every RMI call over JMS.
I am currently evaluating JMS and I don't get what I could use it for.
Currently, I believe this would be a Usecase: I want to create a SalesInvoice PDF and print it when an SalesOrder leaves the Warehouse, so during the Delivery transaction I could send a transactional print request which just begins when the SalesOrder transaction completes successfully.
Now I found out most JMS products are standalone server.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
How does it interact with my application?
Isn't it much too slow?
What are Usecases you already implemented successfully?
JMS is an amazingly useful system, but not for every purpose.
It's essentially a high-level framework for sending messages between nodes, with options for discovery, robustness, etc.
One useful use case is when you want a client and a server to talk to one another, but without the client actually having the server's address (E.g., you may have more than one server). The client only needs to know the broker and the queue/topic name, and the server can connect as well.
JMS also adds robustness. For instance, you can configure it so that if the server dies while the client sends messages or the other way around, you can still send messages from the client or poll messages from the server. If you ever tried implementing this directly with sockets - it's a nightmare.
The scenario you describe sounds like a classic J2EE problem, why are you not using a J2EE framework? JMS is often used inside J2EE for communications, but you got all the other benefits.
What ist Java Message Service (JMS) for
JMS is a messaging standard that allows Java EE applications to create, send, receive, and consume messages in a loosely coupled, reliable, and asynchronous way. I'd suggest to read the Java Message Service API Overview for more details.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
Sure, in your case, Quartz is an option. But what if the invoice system is a remote system? What if you don't want to wait for the answer? What if the remote system is down when you want to communicate with it? What if the network is not always available? This is where JMS comes in. JMS allows to send a message guaranteed to be delivered and to consume it in a transactional way (sending or consuming a message can be part of a global transaction).
How does it interact with my application?
JMS supports two communication modes: point-to-point and publish/subscribe (if this answers the question).
Isn't it much too slow?
The MOMs I've been working with were blazing fast.
What are Usecases you already implemented successfully?
Used in system such as a reservation application, a banking back-office (processing market data), or more simply to send emails.
See also
EJB Message-Driven Beans
Why would a need a Standalone Server
for Message Processing, vs. e.g. some
simple inproc processing with Quartz
scheduler?
The strength of JMS lies in the fact that you can have multiple producers and multiple consumers for the same queue, and the JMS broker manages the load.
If you have multiple producers but a single consumer, you can use other approaches as well, such as a quartz scheduler and a database table. But as soon as you have multiple consumer, the locking scheme become very hard to design; better go for already approved messaging solution. See these other answers from me for a few more details: Why choosing JMS for asynchronous solution ? and Producer/consumer system using database
The other points are just too vague to be answered.
I've used it on a number of projects. It can help with scalability, decoupling of services, high availability. Here's a description of how I used it on a project several years ago:
http://coders-log.blogspot.com/2008/12/favorite-projects-series-installment-2.html
The description explains what JMS brought to the table for this particular project, but other projects will use messaging systems for a variety of reasons.
Messaging is usually used to interconnect different systems and send requests/commands asynchronously. A common example is a bank client application requesting an approval for a transaction. The server is located in another bank's system. Both systems are connected in an Enterprise Service Bus. The request goes into the messaging bus, which instantly acknowledges the reception of the message. The client can go on with processing. Whenever the server system becomes available, the bus forwards the message to it. Of course there needs to be a second path, for the server to inform the client that the transaction executed successfully or failed. This again can be implemented with JMS.
Please note that the two systems need not to implement JMS. One can use JMS and the other one MSMQ. The bus will take care of the interconnection.
JMS is a message-oriented middleware.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
It depends on what other components you may have. I guess. But I don't know anything about Quartz
How does it interact with my application?
You send messages to the broker.
Isn't it much too slow?
Compare to what ?
What are Usecases you already implemented successfully?
I've used JMS to implement a SIP application server, to communicate between the various components.
From the Javadoc:
The Java Message Service (JMS) API provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.
In other words, and contrary to every other answer here, JMS is nothing more than an API, which wraps access to third-party Message Brokers, via 'JMS Providers' implemented by the vendor. Those Message Brokers, such as IBM MQ and dozens of others, have the features of reliability, asynchronicity, etc. that have been mentioned in other answers. JMS itself provides exactly none of them. It is to Message Brokers what JDBC is to SQL databases, or JNDI is to LDAP servers (among other things).
I have found a very good explanation of JMS with an example.
That is a simple chat application with JMS queues are used to communicate messages between users and messages stay in the queue if the receiver is offline.
In this example implementation they have used
XSD to generate domain classes.
Eclipse EE as IDE.
JBoss as web/application server.
HTML/JavaScript/JQuery for UI.
Servlet as controller.
MySQL as DB.
The JBoss configuration step for queue is explained nicely
Its available at http://coder2design.com/messaging-service/
Even the downloadable code is also available there.