• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Messaging System

 
Rajit kumar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need help in design Message Center that resemble of LinkedIn on Spring Framework. I have situation like this where The Messages can be accessed on web ,Android and iOS platform. I have some initial thoughts of design above scenario by using Restful to access services to iOS and Android over push notifications. The core components of MC will be placed on Web Server so same should be used by web too.

Message Center should support broadcast and point-to-point message system. It should also help in real time messaging. The design should also scale for 30-50 users load.
My questions are as follow

1) Shall i use JMS Queue and Topics for above scenario?
2) Shall i implement Public - subscribe ?
3) would Poll based messaging help to resolve ?

I will appreciate your help with this situation and thanks in advance.

Kumar R
 
Henry Wong
author
Marshal
Pie
Posts: 22086
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rajit kumar wrote:
1) Shall i use JMS Queue and Topics for above scenario?


First of all, do you know the difference between a Topic and a Queue? These are two different quality of services -- and if you know the difference, it is pretty clear on when you need one, and when you need the other.

There is probably only one case when it doesn't make a difference which you use -- and that is the case of when you only have one publisher (or producer), and only have one subscriber (or consumer). In that case, either a topic or queue is okay ... but personally, I prefer to use a topic.

Rajit kumar wrote:
2) Shall i implement Public - subscribe ?


I am assuming you mean publish/subscribe? Or pub/sub, for short? Or in JMS speak, using a Topic?

Rajit kumar wrote:
3) would Poll based messaging help to resolve ?


Please provide more detail. Are you referring to a particular implementation?

Rajit kumar wrote:I need help in design Message Center that resemble of LinkedIn on Spring Framework. I have situation like this where The Messages can be accessed on web ,Android and iOS platform. I have some initial thoughts of design above scenario by using Restful to access services to iOS and Android over push notifications. The core components of MC will be placed on Web Server so same should be used by web too.

Message Center should support broadcast and point-to-point message system. It should also help in real time messaging. The design should also scale for 30-50 users load.


Also, as a side note. Messaging, IMO, is more targeted towards a "backbone" technology. ie. server to server communication. Granted, it has been used very well in client-server too, such as publishing to slow desktops. There are even some good "last mile" technologies that extend the JMS bus to browsers, Androids, IPhones, etc. but these are not the norm that JMS was designed for.

IMO, if you are concerned with these "last mile" technologies, and you have JMS applications that you want ported to them, then by all means use JMS (with the support of these "last mile" services). However, if you are writing new code, then it would probably be a good idea to not choose JMS, as browsers, and phone devices are not the primary target for messaging environments.

Henry
 
Rajit kumar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for clarifications.. i understand by reading your statements so JMS may not be suited for current environment as App would be totally new and need to develop app from scratch.

I mean Poll based messaging is pull based where client polls for queue messages at regular intervals so would pull based recommended over push based ?if i want to start new app.

what i understand from push-based model - A listener subscribes to an event that is triggered whenever a message arrives on a queue. The listener in turn can initiate message processing thus not having to poll the queue in order to determine whether or not any new work is available.


What I want to implement pull based messaging where listener(poll regular intervals) listens to queue whenever a message arrives on a queue from subscriber then message will be updated queue and database as well.

Is it recommend for messaging center if so, are there any implications like load factors if i choose pull based over push.

Please suggest..
 
Henry Wong
author
Marshal
Pie
Posts: 22086
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajit kumar wrote:
I mean Poll based messaging is pull based where client polls for queue messages at regular intervals so would pull based recommended over push based ?if i want to start new app.

what i understand from push-based model - A listener subscribes to an event that is triggered whenever a message arrives on a queue. The listener in turn can initiate message processing thus not having to poll the queue in order to determine whether or not any new work is available.


What I want to implement pull based messaging where listener(poll regular intervals) listens to queue whenever a message arrives on a queue from subscriber then message will be updated queue and database as well.

Is it recommend for messaging center if so, are there any implications like load factors if i choose pull based over push.


JMS Topics does imply push. And JMS Queues does imply pull (although arguably, there seems to be a push notification for it). Regardless, there seems to be ways to configure it to do either... but I digress....

JMS is only an API, and if you are going into production with it, it is highly unlikely that you will be using the reference implementation. You will likely use a product like Apache ActiveMQ, Tibco EMS, IBM MQ, or even INFA UM. Etc. With these implementations, it is what it is. Yes, the API for queue does seem like it is pull, but if the underlying implementation doesn't support it, then it will be simulated (ie. it is really push, but it is pushed to an internal data structure in the application, that the application will pull from).

So... to answer your question regarding "load factors", I guess it depends on the messaging implementation that you choose. Does it naturally support that mode? Or does it have to be simulated? And even so, perhaps the simulation is good enough?


One other point regarding the "last mile". Browsers tend to favor Javascript (and not Java). IOS is done in Objective C. And with Android, it's Java, but its different. So, yeah, you can get products that will provide JMS functionality to these devices, but obviously, it will be a JMS-like API, as most of these devices are not Java.

Henry
 
Rajit kumar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That sound good...I have done few implementations in past based on JMS specs using brokers like IBM MQ and weblogic message bus on EJB 2.1 and EJB 1.1 but tricky part in new specs says integrate different devices i.e.. iOS , Android and Web app.The app should be flexible enough to integrate with windows phones in future.The key thing maintainability of components. The app would need some integration architecture like ESB to integrate rest and JMS or DOES it really require ESB just for pub/sub and restful (webservices to android/iOS) or just JMS and restful will do. If i use JMS , how can i post messages to Android/iOS Push Notification server.

I appreciate your patients.

Rajit
 
Rajit kumar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry for previous post..
That sounds good...I have done few implementations in past based on JMS specs using brokers like IBM MQ and weblogic message bus on EJB 2.1 and EJB 1.1 but tricky part in new specs says integrate different devices i.e.. iOS , Android and Web app.The app should be flexible enough to integrate with windows phones in future.The key thing maintainability of components. The app would need some integration architecture like ESB to integrate rest and JMS or DOES it really require ESB just for pub/sub and restful (webservices to android/iOS) or just JMS and restful will do. If i use JMS , how can i post messages to Android/iOS Push Notification server.

I appreciate your patience.

Rajit
 
Henry Wong
author
Marshal
Pie
Posts: 22086
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajit kumar wrote:
That sounds good...I have done few implementations in past based on JMS specs using brokers like IBM MQ and weblogic message bus on EJB 2.1 and EJB 1.1 but tricky part in new specs says integrate different devices i.e.. iOS , Android and Web app.The app should be flexible enough to integrate with windows phones in future.The key thing maintainability of components. The app would need some integration architecture like ESB to integrate rest and JMS or DOES it really require ESB just for pub/sub and restful (webservices to android/iOS) or just JMS and restful will do. If i use JMS , how can i post messages to Android/iOS Push Notification server.


Not completely sure, as it has been a while since I checked. As already mentioned, I don't think JMS can go to those "last-mile" endpoints. The best that I have seen is JMS like APIs -- as those platforms don't really run fully compliant Java.

Heck, web-services don't really go there well either. It is probably best to look at some commercial stuff that can get you there -- such as products from Push Technology, Lightstreamer, Kaazing, etc.

Henry
 
Rajit kumar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I quite agree your point of view . I did not arrive at right conclusion still but best time to start project with above inputs and thanks for bringing all these in discussion.

Rajit
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic