I am planning to integrate real time notifications into a web application that I am currently working on. I have decided to go with XMPP for this and selected openfire server which I thought to be suitable for my needs.
The front end uses the strophe library to fetch the notifications using BOSH from my openfire server. However the notices are the notifications and other messages are to be posted by my application and hence I think this code needs to reside at the backend. Initially I thougt of going with PHP XMPP libraries like XMPHP and JAXL but then I think that this would cause much overhead as each script will have to do the same steps like connection, authentication etc. and I think this would make the PHP end a little slow and unresponsive.
Now I am thinking of creating a middle-ware application acting as a web service that PHP will call and this application will handle the XMPP service. The benefit with this is that this app (a server if you will) will have to connect just once and it will sit there listening on a port. I am also planning to build it in a asynchronous way such that it will first take all the requests from my PHP app and then when there are no more requests; go about doing the notification publishing stuff. I am planninng to create this service in Python using SleekXMPP.
This is just what I planned. I am new to XMPP and this whole web service stuff and would like to take your comments on this regarding issues like memory and CPU usage, advantages, disadvantages, scalability issues, security etc.
PS:– also if something like this already exists (although I didn’t find after a lot of Googling) Please direct me there.
EDIT — The middle-level service should be doing the following (but not limited to):
1. Publishing notifications for different level of groups and community pages.
2. Notification for single user on some event.
3. User registration (can be done using user service plugin though).
EDIT — Also it would need to create pub-sub nodes and subscribe and unsubscribe users from these pub-sub nodes.
EDIT — Working with Twisted-Python to develop the REST API part now(had to chose between XML_RPC and REST) will keep updating this question as I go along.
Also I want to store the notifications and messages in a database (openfire doesn’t). Would that be a good choice?
1
while I like the idea of a server acting as a middleman between your web-app and openfire, because:
- it separates the web-app from the notifications.
- it makes it possible to scale separately from the web-app.
- remaining connected it uses less resources.
there are 2 things I would consider:
- using a different language / environment for the connection to openfire can create considerable overhead for maintenance and deploy.
- the possibility to use background tasks to push the notifications to openfire (will not slow down your app’s response time):
see for example: this php library for a background job-queue
see a related stack overflow discussion here
2