[lvdberg]

Hi Nikolay,

The thing I do is using a ajax-push in every page.

Its PushEventListener is managed by a Application Scoped bean which observes specific events. The JMS MDB, sends an eventz, which is received by the bean and triggers the onEvent method of each PushEventListener. The only thing was that you need to relate the Session(user) to the PushEventListener, so I create a Map which has the username as key and the PushEventListener as value.

The reaspon to do that is because the interaction between Ajax-request and server is statlesss. When you (for wahatever reason) log in again, of reload due to an error, you add an additional PusEventistener, Using a Map prevents that (it just overwrites the current entry.).

For my application I am using diffenerent beans for different views. which works very neat. I tried it with the Ajax-JMS bridge, but it basically downgrades JMS to an unreliable push.

The following is basically what I am doing. Be aware that this is still under test, it must be a fail-proof mechanism and I need to sure that every Synchronization is in place.

@Name("incidentPushBean")
@Scope(ScopeType.APPLICATION)
@Startup
@Synchronized
public class IncidentPushBean implements Serializable{

     private static final long serialVersionUID = 1669717034696099170L;

     @Logger
     Log log;
     
     protected HashMap<String,PushEventListener> listeners = new HashMap<String, PushEventListener>();

     @In(required=false)
     protected User currentUser;
     
     public void addListener(EventListener l) {
          synchronized(this){
               listeners.put(currentUser.getUserName(), (PushEventListener) l);
          }
          log.info("Added a listener for user " + currentUser.getUserName() + " we now have " + listeners.size() + " listeners." );
     }

     /** This method catsches all the defined events and sends an update 
      * request to all the views.
      */
     @Observer( value="here.you.havae.your.JMS.event")
     public synchronized void processEvent(){
          for (PushEventListener l: listeners.values()){
               if (l != null) {
                    l.onEvent(new EventObject(this));
               }
          }
     }

}
 

Leo

P.S. I think we really, really need better POJO-JMS, hopefully the JSR's get voted suffienciently...

[kapitanpetko]

Leo van den Berg wrote on Nov 10, 2009 11:40:


Its PushEventListener is managed by a Application Scoped bean which observes specific events. The JMS MDB, sends an eventz, which is received by the bean and triggers the onEvent method of each PushEventListener. The only thing was that you need to relate the Session(user) to the PushEventListener, so I create a Map which has the username as key and the PushEventListener as value.

Thanks. So the missing part is the PushEventListener. I haven't used that, but I'm assuming it uses some kind of Comet-like (long-poll) approach. Each listener then should correspond to an open HTTP connection. Have to give it a try.

For my application I am using diffenerent beans for different views. which works very neat. I tried it with the Ajax-JMS bridge, but it basically downgrades JMS to an unreliable push.

By the 'Ajax-JMS bridge' do you mean the one in Seam remoting? ActiveMQ also has Ajax support, using long-polling, but I haven't used it and don't know how reliable it is.

The following is basically what I am doing. Be aware that this is still under test, it must be a fail-proof mechanism and I need to sure that every Synchronization is in place.

[lvdberg]

Nikolay,

I am referrring to the seam-remote one. It's a nice piece of software, if you don't have direct access to JMS and you're just listening to incoming events. I think that JMS support in Seam is already awesome, but it just that tiny bit extra to make Seam work in a more ESB approach.

Leo

[lopsch]

Hi,
I finally found an easy solution. Maybe someone is interested.

I kept the MDB for collecting messages and then raising an event with the message as parameter.
Then I use application scoped bean that observes this event and acts as a listener store. I defined a listener interface that all session beans should implement when they want to receive a message. The session beans register themselves as listener at the listener store. The store then calls the onSelfDefinedNotification method of the self definded listener. So you can use the mdb infrastructure and don't have to use polling or lifecycle methods.

Greetings
Daniel

[lopsch]

Sorry seems it is like Leo's solution ;). I only use a List for the Listener.

[kapitanpetko]

Daniel Lopes wrote on Nov 12, 2009 01:14:


I finally found an easy solution. Maybe someone is interested.

Nice. Just be aware that application scope will not work in a cluster. But as long as you are running on a single node, you should be OK.

[kapitanpetko]

Nikolay Elenkov wrote on Nov 10, 2009 12:31:


Thanks. So the missing part is the PushEventListener. I haven't used that, but I'm assuming it uses some kind of Comet-like (long-poll) approach. Each listener then should correspond to an open HTTP connection. Have to give it a try.

I did try RF's ajax:push and it works :) However, it doesn't use long poll, but a variation of polling. What this means for the application is that updates are not real time, it might take a second or so (specified in the 'interval' parameter) for the view to get updated. More details here: Ajax-On-Demand. The good part is that it works through proxies (most tend to close idle connection after some time). Another potential problem is that it uses application-scoped components, so it won't work properly in a cluster.

Icefaces' push, however, does use long polling and should offer almost immediate updates. Also seems easier to use (haven't actually tried it yet). More details: Ajax Push. It too uses application-scoped components for the implementation, so it won't work in a cluster. However, they have something called 'Enterprise Push Server', which is designed with clusters in mind and should work properly in a cluster. I haven't found more details yet though. Has anyone used it?

[lvdberg]

Hi Nikolay,

As stated by you, the push-mechanism has a number of problems of which the server-polling time is the most important one. However you can set the polling time to one second and it works perfect. Problem rises when you have a high number of users which should require a cluster to solve that problem. Whatever we try to invent, the restrictions of HTTP degrades it to a traditional polling inside a pushing mechanism.

What you basically need is a way to have a real push from the server working with a web-client receiver. Whitout additional logic I think that's impossible with our present browser based viewing technology. At the moment our requirements are just the near-real-time one second. if faster updates are needed I would definitely go for some plug-in technology such as an applet or a full java client  (for instance a local embedded jetty-server which handles the seam-viewing part). I hope someday somebody improves the web-architecture a bit allowing also real-time messaging. 

Leo

[lvdberg]

Additional note:

I saw Swing mentioned as view layer for WELD, but can't find more information. That's somethinh that would make me very, very happy...

Leo

[kapitanpetko]

Leo van den Berg wrote on Nov 13, 2009 11:40:


What you basically need is a way to have a real push from the server working with a web-client receiver. Whitout additional logic I think that's impossible with our present browser based viewing technology. At the moment our requirements are just the near-real-time one second. if faster updates are needed I would definitely go for some plug-in technology such as an applet or a full java client  (for instance a local embedded jetty-server which handles the seam-viewing part). I hope someday somebody improves the web-architecture a bit allowing also real-time messaging. 

Well, Commet is basically real push, and works instantaneously. We are using to deliver updates to browser clients. This is using Jetty and JS, so nothing to do with Seam, though. The tricky part is integrating this with JSF/Seam. The Icefaces components should do this, but still haven't tried it (no clustering for free though). As for clustering, Asmosphere provides easy clustering support. AFAIK, PrimeFaces uses is for their push support. So we are almost there, just need to hook up the components :)

Still, this might be easier done with Flex and the like, but that's a whole new world to me :)

Will play with this a bit more, if I get the time.

[tedgoddard]

Nikolay Elenkov wrote on Nov 16, 2009 04:35:


Well, Commet is basically real push, and works instantaneously. We are using to deliver updates to browser clients. This is using Jetty and JS, so nothing to do with Seam, though. The tricky part is integrating this with JSF/Seam. The Icefaces components should do this, but still haven't tried it (no clustering for free though). As for clustering, Asmosphere provides easy clustering support. AFAIK, PrimeFaces uses is for their push support. So we are almost there, just need to hook up the components :)

ICEfaces will certainly provide the Ajax Push features that you need.

You are correct that the clustering support is a commercial feature.  This is a commercial feature for two reasons (please let us know if you disagree): clustered environments are usually not pure open source environments and already have multiple commercial products in use, mainly because the cluster is needed to achieve a specific business goal rather than a technology goal; cluster support requires specific integration with commercial JMS and application servers, where the effort is typically in the configuration of these proprietary technologies rather than ICEfaces itself (hence it is a commercial activity from the ICEfaces point of view, since we are mainly solving problems that have little to do with ICEfaces).  In any case, we're happy to help you get your Ajax Push application running well on any cluster.

[kapitanpetko]

Ted Goddard wrote on Nov 18, 2009 21:58:


ICEfaces will certainly provide the Ajax Push features that you need.

Well, I am still just exploring technologies. But nice to hear :)

You are correct that the clustering support is a commercial feature.  This is a commercial feature for two reasons (please let us know if you disagree): clustered environments are usually not pure open source environments and already have multiple commercial products in use

You can have a cluster with JBoss/Tomcat/Glassfish, all opensource. No commercial products needed. Not to mention that your website states (emphasis mine):

Fully-tested and documented deployment configurations are included for all major *open source* and commercial application servers...

...cluster support requires specific integration with commercial JMS and application servers...

JMS is a standard, how it is implemented is not really relevant, I think. There are many free/open JMS implementations, see above. Plus, JMS is only one way to get cluster-wide notifications (the one you are using, yes).

... where the effort is typically in the configuration of these proprietary technologies rather than ICEfaces itself (hence it is a commercial activity from the ICEfaces point of view, since we are mainly solving problems that have little to do with ICEfaces).  In any case, we're happy to help you get your Ajax Push application running well on any cluster.

Configuration of proprietary technologies sounds like support to me, it is not really related to a particular product. But I see you point (business model): enterprises need stuff that is reliable and supported, so you provide that support. The underlying technology being open source shouldn't interfere with this, IMHO, but that is another matter.

In any case, probably a good idea to have more information about your Enterprise Push Server publicly available. What I found is a bit abstract and lacking in details. For example, it is not at all clear, what the push server is: is it a set of webapps you deploy next to your application?; is it a plugin(s) for the application server?; is it Java-only or with native parts?, etc.

[tedgoddard]

Nikolay Elenkov wrote on Nov 19, 2009 03:22:

You can have a cluster with JBoss/Tomcat/Glassfish, all opensource. No commercial products needed. Not to mention that your website states (emphasis mine):

Fully-tested and documented deployment configurations are included for all major *open source* and commercial application servers...

...cluster support requires specific integration with commercial JMS and application servers...

JMS is a standard, how it is implemented is not really relevant, I think. There are many free/open JMS implementations, see above. Plus, JMS is only one way to get cluster-wide notifications (the one you are using, yes).

This is what we were expecting as well, but it turns out that each JMS/server combination requires specific attention (different ways of registering topics, different ways of handling fail over).  It's also not always feasible to swap out the JMS implementation for a given server -- fault tolerant capabilities are tightly integrated.

... where the effort is typically in the configuration of these proprietary technologies rather than ICEfaces itself (hence it is a commercial activity from the ICEfaces point of view, since we are mainly solving problems that have little to do with ICEfaces).  In any case, we're happy to help you get your Ajax Push application running well on any cluster.

Configuration of proprietary technologies sounds like support to me, it is not really related to a particular product. But I see you point (business model): enterprises need stuff that is reliable and supported, so you provide that support. The underlying technology being open source shouldn't interfere with this, IMHO, but that is another matter.

In order to develop the underlying technology, it was unfortunately necessary to wade through all of the proprietary aspects, so the business model and the technology are intertwined.

In any case, probably a good idea to have more information about your Enterprise Push Server publicly available. What I found is a bit abstract and lacking in details. For example, it is not at all clear, what the push server is: is it a set of webapps you deploy next to your application?; is it a plugin(s) for the application server?; is it Java-only or with native parts?, etc.

More information in a less abstract form is always good.  Essentially, the Enterprise Push Server is a Java web application that you can deploy to some subset of your cluster nodes (typically all of them, but different fail-over strategies are possible).  Push notifications are broadcast to the Push Server webapps so that the Ajax Push capability can be shared between all applications in the cluster in a fault-tolerant way (sharing is important, since older browsers only allow two connections per host).  Some apache httpd configuration may be required.  All of this is transparent to the application.

[sathishavunoori]

hi Daniel Lopes,
can you please send the complete code of MDB and Application scoped bean for reference.because i am trying to implement JMS in session bean. can i expect some support   from you?

thanks with regards .