Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Have you looked at ZeroMQ [zeromq.org/]? I found it's better suited to exchange messages than XMPP since establishing the connection is faster and the protocol is simpler. –  Patrick Forget Sep 10 '13 at 18:52
add comment

1 Answer

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:

  1. using a different language / environment for the connection to openfire can create considerable overhead for maintenance and deploy.
  2. 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
share|improve this answer
    
Well I am now trying to develop the middleware as a REST service with twisted-Python and SleekXMPP. The twisted part will listen for requests and put them in the job queue where as the sleekXMPP part will process that queue accordingly. Planning to deploy them asychronously with multithreading and all. Whats your say on that? –  mlakhara Dec 20 '12 at 6:22
    
if you are not worried about the extra stack (python, twisted, SleekXMPP) then it seems fine. I don't see why REST should be necessary, however, or even http. I would advice json encoded objects over TCP. (or even UDP if are willing to trade some lost messages for speed) –  kr1 Dec 20 '12 at 19:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.