I've been using mosquitto for several months now, but now I've got to the point that I'd like to build a standalone broker into my Java application. Is it possible to do this, or would I need to have to have mosquitto running by itself on a server?
You may be able to create a JNI wrapper around mosquitto, but you may do better looking at one of the other broker implementations, specifically one already written in java.
There are several listed on the mqtt.org server wiki page.
https://github.com/mqtt/mqtt.github.io/wiki/servers
e.g. Moquette, HiveMQ or ActiveMQ
Related
Is there a look a like structure of JMS on PHP which can be implemented? JMS can run only on ApacheMq which I have developed a system on PHP that runs on Apache which if I run both only one is running. I dont have to have another server to run JMS? Is there look alike which can be run to Apache?
Thanks in advance.
AFAIK, JMS only runs on Java or a native compiled version e.g. Tibco EMS. These servers have clients for a wide range of languages and you shouldn't need to know what language the server uses for its implementation.
You could build a PHP version of JMS. But I would be surprised if one exists.
BTW ActiveMQ is not the only JMS server, there are many others. http://en.wikipedia.org/wiki/Java_Message_Service#Provider_implementations
Anyone has expirience on having Jruby project running on Jboss (using torquebox or whatever) with an ability to communicate with another "japps" not on the same jboss where jruby app is, i.e. some java project on another jboss?
I know there is an torque-messanging but dunno if it's possible to communicate with external(out of jruby-app's jboss) app?
Best practices are welcomed.
Thanks in advance.
P.S. placing that other app on the jboss where jruby app is not acceptible solution.
I can recommend you to use Thrift and build communication via them.
Thrift have generator for both your needed languages (Java and JRuby) and provide good and fast communication.
UPDATED:
Thrift is RPC (remote procedure call) framework developed at Facebook. In detail you can read about it in Wiki.
In few word to save you time, what it is and how to use it:
You describe you data structures and service interface in .thrift file(files). And generate from this file all needed source files(with all need serialization) for one or few languages(what you need). Than you can simple create server and client in few lines
Using it inside client will be looks like you just use simple class.
With Thrift you can use what protocol and transport used.
In most cases uses Binary or Compact protocol via Blocked or Not-blocked transport. So network communication will be light and fast + with fast serialization.
SOAP(based on XML on HTTP) packages, its in few times bigger, and inappropriate for sending binary data, but not only this. Also XML-serialization is very slow. So with SOAP you receive big overhead. Also with soap you need to write (or use third-party) lib for calling server(tiny network layer), thrift already made it for you.
SMTP and basically JMS is inappropriate for realtime and question-answer communication.
I mean if you need just to put some message in queue and someone sometime give this message and process it — you can (and should) use JMS or any other MQ services(Thrift can do this to, but MQ architecture is better for this issue).
But if you need realtime query-answer calls, you should use RPC, as protocol it can be HTTP(REST, SOAP), binary(Thrift, ProtoBuf, JDBC, etc) or any other.
Thrift (and ProtoBuf) provide framework for generate client and server, so it incapsulate you from low level issues.
P.S:
I made some example in past https://github.com/imysak/using-thrift (communication via Thrift Java server + Java Client or node.js client), maybe it will be useful for someone . But you can found more simple and better examples.
Torquebox supports JMS. The gem you specified torquebox-messaging allows for publishing and processing of HornetQ messages on the local JBoss AS server/cluster that the JRuby app is running in. I don't think it currently supports connecting to remote servers.
Using this functionality in your JRuby app you could then configure your Java app on another server to communicate with HornetQ running in the JBoss AS that the JRuby app is running on.
Alternatively you could always implement your own communication protocol or use another Java library - you have access to anything Java you want to run from JRuby.
You can use Web Services or JMS for that
I have an application that needs to also be the JMS server (broker). So I would like to start within the same JVM the OpenJMS server. I have loosely read that this is possible, but I could not find any examples or explanation on the http://openjms.sourceforge.net site or anywhere else for that matter.
Has anyone done this, how simple is it? I know with HornetQ it is very simple but we want to remain with OpenJMS.
Thanks
Yes in HornetQ you could start an embedded jms server with only two line of code and a configuration xml.
Being that HornetQ is POJO based and opensource, why don't you choose it?
Piero.
You could also check more details on embedding HornetQ in the new HornetQ book
www.amazon.com/dp/1849518408/?tag=packtpubli-20
What is a good solution for communication via message broker that supports both (C)Python and Java/JMS applications? My particular requirements are:
open source solution
Available on Linux-based systems
No rendezvous between sender and receiver required (i.e. uses a message broker)
Multiple producers and consumers supported for a single event queue (only one consumer receives each message)
Unit of work support with two-phase commit (XA support nice to have)
Support for persistent messages (i.e. that survive a restart of the broker)
Supports JMS for Java clients
No component is "fringe", meaning at risk of falling out of maintenance due to lack of community support/interest
If there is a Python client that manages to "speak JMS" that would be awesome, but an answer including a task to write my own Python JMS layer is acceptable
I have had a surprisingly hard time finding a solution for this. Apache's ActiveMQ has no Python support out of the box. ZeroMQ requires a rendezvous. RabbitMQ does not appear to support JMS. The best candidate I have found is a combination of ActiveMQ and the pyactivemq library. But the first and last release of pyactivemq was in 2008, so it would appear that that fails my "no fringe" requirement.
The ideal answer will be the names of one or more well-supported and well-documented open source packages, that you have personally used to communicate between a Java/JMS and Python application, and that do not require a lot of integration work to get started. An answer that includes an "easy" (up to a few days of work) implementation of additional glue code to meet all the requirements above, would be acceptable. A commercial solution, in the absence of a good open source candidate, would be acceptable also.
Also, Jython is out. (If only I could...) The same Python applications will need to use modules only available in CPython.
JMS is a specification not implementation . RabbitMQ is a really option .
I have also happily used HornetQ http://www.jboss.org/hornetq from Jboss as with every thing it is more aligned with every thing Java EE but RabbitMQ would be choice espcially if you are using Spring as well
I have had a surprisingly hard time finding a solution for this.
Apache's ActiveMQ has no Python support out of the box.
ActiveMQ brokers fully support using the Stomp protocol out of the box. Stomp is a text based protocol for messaging that has clients for many platforms and languages.
ActiveMQ's documentation should contain information on how to set up a connector for stomp. In its simplest form, enabling a connector would look something like:
<transportConnectors>
<transportConnector name="stomp" uri="stomp://localhost:61613"/>
</transportConnectors>
Once enabled on the broker side, you can then use any python library that supports stomp. You can then use Stomp on the python side and JMS on the java side for communication with the broker and sending/receiving from specific destinations.
You might want to take a look at OpenAMQ and another look at RabbitMQ.
The underlying messaging technology used by RabbitMQ and OpenAMQ is AMQP. You should be able to easily find Python and Java clients that work against both of these brokers (and ostensibly any other spec-compliant broker).
If JMS is a must-have, then you might be able to find a JMS client out there implemented on top of AMQP (OpenAMQ provided such a client at one time, but I am unsure of its current status).
We had been using GlassFish Message Queue (formerly Sun Java MQ) - it is inherited from OpenMQ
It satisfies most of your requirements, if not all.
We had been using fail over-clustered brokers in Red Hat Linux (RHEL) - it is reliable for heavy usage. Though some 'quirks' lurk here and there.
I just need notification system. javax.jms.* - good solution I think, but I can't understand what do I need to use JMS?
I don't want to use any app. servers like GlassFish or Tomcat, I just would like to use standard jdk and myserver(very light) and myclient(very light too) and some MessageSystem to exchanging bitween myserver and myclient. As I understand to use JMS I need JMS Provider. For example: ActiveMQ. But I don't uderstand ActiveMQ needs any server?(GlassFish probably), and what kind of *.jar do I need from Java EE ?
JMS provider or more correctly a Message Broker can be a stand-alone application. Most of J2EE app servers include a broker inside them but yes we also have many very good stand alone JMS brokers, ActiveMQ is good, then there is OpenJMS and many others. And as they are stand alone they don't need another app server to run them. And they usually come with every needed jar as well :) SO you'll not need to copy any jar from other app-server to say ActiveMQ or OpenJMS.
ActiveMQ runs as a standalone server; it requires the Java VM like any Java application but nothing else beyond that.
Other stand alone JMS brokers (open source) which can be run standalone or even embedded in your Java application are Open Message Queue (OpenMQ) which is also included in GlassFish, and the new JBoss HornetQ message broker which will be the JMS implementation in JBoss application server.