I am trying out a project on OpenShift using Aerogear UPS. I am able to push messages to the clients, but is there a way to get messages from the client?
Aerogear seems to be the only packaged XMPP solution on OpenShift, and it appears to be one way messaging platform. Please tell me it ain't so.
It ain't so. *
Well it kind of is so but not for long! In UPS 1.1.0 we are planning on introducing support for metrics support. Right now it is just a glorified read receipt with a phenomenally sexy dashboard. In UPS 1.2.0 we are moving the metrics from HTTP to XMPP messaging (for Android). Please comment on our JIRAs (https://issues.jboss.org/browse/AGDROID-433) or bug us on the aerogear mailing lists (https://aerogear.org/community/#contact).
Related
This is what I want
A user(bot) that always shows status Online
When a message comes for the user, I will hit a webhook associated with the user
The response from the webhook request will be sent as reply to the sender
This user will be able to intercept any message (let's say for profanity moderation)
This user will be able to send message to anyone (let's say broadcast)
This user will come in every users roster as default(like echo bot of skype)
I can't seem to find any resource on how to achieve this. I've found a way to intercept the incoming packet in openfire but I don't see any easy way to do this with MongooseIM. I haven't started diving deep into the source code yet, still looking for a way to do this without touching the source code and locking myself to a specific version of MongooseIM.
Disclaimer: I'm on the MongooseIM core team.
There are multiple ways this could be achieved. The easiest way to achieve this depends on your familiarity with Erlang, the programming language MongooseIM is written in.
You won't need any Erlang to use the event pusher module with its HTTP backend and the default settings, but you'd need some Erlang to control what messages get forwarded to the HTTP service or to make more complex setups. To send messages back, you'd either need to use the MongooseIM REST API or connect as an ordinary XMPP client to the server using one of the many XMPP libs available out there. This is probably the best approach to achieve your goal.
You can skip using the event pusher and just connect your bot as an XMPP client written in any language whatsoever. The bot might have your business logic within or can forward messages it gets to the HTTP service.
If you're comfortable working in Erlang, then the mechanism to extend the server is called Hooks and handlers and is described in the official MongooseIM documentation. This requires writing code in Erlang and building from source, but does not necessarily require modifying upstream MongooseIM code.
You could use the XMPP component protocol, which allows to extend the functionality of an XMPP server, yet structure it as multiple services. The components may be written in any technology you want and the most popular XMPP libraries should support the component protocol out of the box.
Depending on your choice from the above list and the language and environment you prefer, you might have to pick an XMPP library to use. There are XMPP libs available for iOS (ObjC and Swift), Android (Java and Kotlin), Python, JavaScript, C, and even some emerging ones for Rust, Dart and possibly more.
I've been searching high and low for a plugin that handles MUC administration through HTTP requests for Openfire. I've looked in the plugins and even in the community pages but I've had no luck so far.
Is there a plugin for this? Where can I find it?
If there are none, what are my alternatives aside from creating my own? Kinda like how ejabberd has mod_rest or even ejabberdctl.
If anyone can point me to the right direction, that would be really great!
I ended up creating a service for http requests and linking it to Openfire's MySQL back end. Easier and gives me more control.
Openfire have cache mechanism， Directly operate Mysql table have some issue, User information will delay before openfire cash flush.
I do it by xmpphp, and a new method to add muc room and room member by xmpp protocol, but i need user's password every operation.
If you check again the Plugin site from Openfire you will find out that there is a Plugin for that named "MUC Service". That do exactly what you need.
Here is the documentation: http://www.igniterealtime.org/projects/openfire/plugins/mucservice/readme.html
Google GTalk clients (web, android, windows) have great ability to suck conversation history from server, even though conversations were done an another jabber client.
What jabber (XMPP) functionality (XEP) is used for that or is it some custom thing?
Why no other XMPP client (non Google) has this ability?
P.S. It is programming question, because I am asking about specific XMPP functionality.
It is possible that this is done using message archiving. See XEP-0136: http://xmpp.org/extensions/xep-0136.html
(And with regard to the other answer, this is supported by ejabberd: http://www.ejabberd.im/mod_archive)
Its a property of XMPP server not XMPP/Jabber client. All conversation happens through XMPP Server. So If server wants it can store all the history. As far as I know there is no open source XMPP server which can store history.
Google has it all.
I am not sure, but I think there is no specific XEP for storing history on server.
Server side XEP-0136 (message archiving) can be done with ejabberd + mod_archive (mod_archive_odbc variant with sql backend, for better perfomance) or with openfire server with open archive plugin.
Client side, for XEP-0136 I use vacuum im, http://code.google.com/p/vacuum-im/ , it's open-source and cross platform.
I'm working on a messaging/notification system for our products. Basic requirements are:
Fire and forget
Persistent set of messages, possibly updating, to stay there until the sender says to remove them
The libraries will be written in C#. Spring.NET just released a milestone build with lots of nice messaging abstraction, which is great - I plan on using it extensively. My basic question comes down to the question of message brokers. My architecture will look something like app -> message broker queue -> server app that listens, dispatches all messages to where they need to go, and handles the life cycle of those long-lived messages -> message broker queue or topic -> listening apps.
Finally, the question: Which message broker should I use? I am biased towards ActiveMQ - We used it on our last project and loved it. I can't really think of a single strike against it, except that it's Java, and will require java to be installed on a server somewhere, and that might be a hard sell to some of the people that will be using this service. The other option I've been looking at is MSMQ. I am biased against it for some unknown reason, and it also doesn't seem to have great multicast support.
Has anyone used MSMQ for something like this? Any pros or cons, stuff that might sway the vote one way or the other?
One last thing, we are using .NET 2.0.
I'm kinda biased as I work on ActiveMQ but pretty much all of benefits listed for MSMQ above also apply to ActiveMQ really.
Some more benefits of ActiveMQ include
great support for cross language client access and multi protocol support
excellent support for enterprise integration patterns
a ton of advanced features like exclusive queues and message groups
The main downside you mention is that the ActiveMQ broker is written in Java; but you can run it on IKVM as a .net assembly if you really want - or run it as a windows service, or compile it to a DLL/EXE via GCJ. MSMQ may or may not be written in .NET - but it doesn't really matter much how its implemented right?
Irrespective of whether you choose MSMQ or ActiveMQ I'd recommend at least considering using the NMS API which as you say is integrated great into Spring.NET. There is an MSMQ implementation of this API as well as implementations for TibCo, ActiveMQ and STOMP which will support any other JMS provider via StompConnect.
So by choosing NMS as your API you will avoid lockin to any proprietary technology - and you can then easily switch messaging providers at any point in time; rather than locking your code all into a proprietary API
Pros for MSMQ.
It is built into Windows
It supports transactions, it also supports queues with no transactions
It is really easy to setup
AD Integration
It is fast, but you would need to compare ActiveMQ and MSMQ for your traffic to know which is faster.
.NET supports it nativity
Supports fire and forget
You can peek at the queue, if you have readers that just look. not sure if you can edit a message in the queue.
Cons:
4MB message size limit
2GB Queue size limit
Queue items are held on disk
Not a mainstream MS product, docs are a bit iffy, or were it has been a few years since I used it.
Here is a good blog for MSMQ
Take a look at zeromq. It's one of the fastest message queues around.
I suggest you have a look at TIBCO Enterprise Messaging Service - EMS, which is a high performance messaging product that supports multicasting, routing, supports JMS specification and provides enterprise wide features including your requirements suchas fire-forget and message persistence using file/database using shared state.
As a reference, FEDEX runs on TIBCO EMS
as its messaging infrastructure.
http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp
There are lot other references if i provide, you'd really be surprised.
There are so many options in that arena...
Free: MantaRay a peer to peer fully JMS compliant system. The interesting part of Mantaray is that you only need to define where the message goes and MantaRay routes it anyways that will get your message to it's detination - so it is more resistant to failures of individual nodes in your messaging fabric.
Paid: At my day job I administer an IBM WebSphere MQ messaging system with several hundred nodes and have found it to be very good. We also recently purchased Tibco EMS and it seems that it will be pretty nice to use as well.
Beside the obvious person to person instant message chat, What else have you used a Jabber server's functionality to enable?
Edit: links to working code to really show it off are particularly useful - and will be more likely to be voted up.
There are unlimited uses for XMPP/Jabber.
Take any message/data you want to send somewhere else and you can use jabber. Run a centralised logging service for distributed services? You can jabber the massage.
You want to check if your services/programs are running? XMPP presence will tell you. If you add custom status messages you can see exactly what is going on.
This is why Cisco has got into the game. Picture a server farm where each blade has a built in mini jabber client. On boot up it will register it's presence to the central server as awaiting work. The central server fires off some work in it's direction and it then changes it's status to "Busy". Another blade finished it's work and changes it's status back to "Available"... rinse and repeat.
When you combine the actual jabber messages with it's Out Of Band abilities, these servers can post where the results of the job can be found.
Anything you can think of needing to pass a message can be done with XMPP to some degree. Be this person to person, program to program, or any combination.
You could use a Jabber server to handle/broker messages between a client application and another server application.
It can actually be pretty effective.
Not me but Martin Woodward used jabber to control a "build bunny" that displays the current status of the build server.
http://www.woodwardweb.com/gadgets/000434.html
XMPP is good for sending messages back and forth between computers that don't need to be broken into chunks. They also can't be terribly big. If you use the right library, it can be pretty easy to set up.
Sending messages to a web page. Proof-of-concept: esagila.com
I plan to use it to receive notifications from my system, such as:
Process did not finish
Report was not generated on time
User needs help
I already receive many of these messages as email. But receiving an IM could be much more effective.
You might want to look at Vertebra which is...
a framework for orchestrating complex processes in a Cloud. It is designed with an emphasis on security, fault tolerance, and portability.
From the knowledge base:
Why was XMPP chosen for Vertebra?
XMPP based instant messaging can be a good alternative to search engines for information that is small, complete in itself and required frequently and repeatedly. For example, your daily horoscope - you require it daily and it is not large.
To see an example of this add astro#askme.im to your list of contacts in your jabber client (Gmail Chat/Gtalk/or any other Jabber client) and then initiate chat with this contact by sending the word "help".
Also see www.askme.im for a whole list of chat based solutions.
I've used Jabber in the past to get email notifications. Nowadays I use it for low-priority nagios notifications, it is very useful and way cheaper than SMS:
We use xmpp as both a 'bus' and a real-time API at http://superfeedr.com
Iowa State University Department of Agronomy has created this with Jabber: http://mesonet.agron.iastate.edu/iembot/
If you're a weather freak like I am, this is VERY cool stuff!
Apple implements mobileme's push service using Jabber/XMPP's subscription services to send push notifications. That is the most widespread use of Jabber for non-IM purposes I know of. This article has more details.
My friends have also built a Jabber python bot, which is kinda cute but not all that useful :-)
Edit
The most recent Next Big Thing, Google Wave, uses Jabber under the hood. Further illustrates the power of the protcol.
We have used XMPP and BOSH to enable users to communicate with a webbrowser directly and in realtime from their phone.
For example Code you can view our open source API
The vooices site also has live examples where you can control a map and play a game using your phone via your web browser: http://www.vooices.us/
I've always thought XMPP would be a good way to deliver SNMP data. OIDs are really painful, much of the system is insecure, and the SNMP traps never work quite like you want them to. With an XMPP server in the middle and a smart component to make some choices, you can use it to send out jabber or other notifications, kick off restart jobs, update web pages, or whatever else you need.
The XML data is pretty small in this case, and you can have the one XMPP server both talk to humans in message stanzas, or computers with the same protocol.