Usage of ICEFaces push technology

Question

We are looking at/investigating the possible usage of ICEFaces AJAX push technology. Wondering if anyone has used this? What issues they faced? And overall impression of it.

We are using Websphere 6.1 application server - has any one who has implemented this implemented it on Websphere.

We are trying to address an issue on our site in which we want the users have the ability to bid on products and get bid prices in real time.

We are currently using MyFaces + Tomahawk + Richfaces + some of our own components but we are at a point in which we can move away from Richfaces if needed.

Answer 1

I've briefly worked through a prototype. It works as advertised. The important thing to consider when using AJAX push with this or any other framework is the impact on your webserver. To accomplish AJAX push the client either holds a persistent connection to the server or uses polling, both which have implications on high demand web applications. I'm not experienced with Websphere but you'll want to research what is specifically recommended given your application container (Websphere) and the load on the pages where you'll use Ajax push.

I think it is worth noting too that there are other frameworks that do a really good and flexible job of AJAX push - as I always lean toward open source solutions (we run an extremely effective Apache/Tomcat/Spring/DWR stack) I'd suggest checking out DWR

http://directwebremoting.org/

Answer 2

As far as I know DWR is using the JavaScript programming model. With ICEfaces you don't need JavaScript at all. From the maintenance perspective far more interesting than AJAX push itself. Although, with release 1.8 it became so easy to use AJAX push that everybody should evaluate it.

I will discuss some details in my forthcoming ICEfaces book ;-).

Answer 3

Works as advertised, use it a lot at home and office.

If you use springsecurity than don't use an ondemandrender with a request scoped bean, you lose the security context between renders.

Sessionrender does not seem to have that problem.

Recently I saw a nice example (although some of mine are better:-) ) in the book seam in action, they have a little section about icefaces.

The sessionrenderer is considerably easier to use than the ondemandrenderer or intervalrenderer but doesn't have as many features.

heres a very basic example. Also uses some other technology, Our little project is known for integrating different technologies. http://web.me.com/cannonwc/Site/Blog/Entries/2008/11/7_An_example_of_ajax_Push.html

There's actually more stuff on the main site

www.mooncatventures.com and the blogs site www.mooncatventures.com/blogs

Answer 4

I think it makes no sense to mix ICEfaces with RichFaces. The AJAX parts are not compatible. ICEfaces on MyFaces is no problem.

Tiles? You want to keep Tiles? This makes no sense when using Facelets that's pretty tight integrated with ICEfaces. As Facelets becomes standard with JSF 2.0 it is a good idea to think about changing from Tiles to Facelets anyway.

Answer 5

We're using it on a conversion project right now (porting a JSF application away from IBM's Portlet JSF implementation to IceFaces on Tomcat) and as everyone else states, it works as advertised. We've made very few modifications to accommodate for the implementation change. So far, I'm impressed.

Answer 6

First let me say that Icefaces is a pretty solid product and it's saved us a ton of development time in terms of getting a good, modern feeling web app without a lot of JavaScript knowledge on the team.

That said Icefaces does have it's warts. A lot of the cool features like partial submit cause lots of chatter back and forth between the client and the server. State is held on the server and reflected in the client which makes for a lot of back and forth traffic between the client and the server. In order to achieve optimal performance you're going to have to dig under the covers and use some JavaScript which is the very thing you were trying to avoid in the first place. Even validation needs to be done on the server side, however I believe this is a JSF limitation more than an Icefaces limitation.

I also don't appreciate how Icefaces changes component APIs between what seems to be minor releases. The whole tree component changed between 1.7.2 and 1.8. The tree component was ugly and limited so it was a welcome change but still. We felt like 1.8 was forced on us which leads me to my next point.

Icefaces treats it's non support contract paying users as second class citizens. Between Icefaces 1.7.2 and 1.7.2 SP1 there was a major regression in the push mechanism that caused it to fail completely in our app. The only fixes available were to move to 1.8(which had API changes) or use 1.7.2-SP2 which is only available to customers on a support contract. Don't forget for a minute that the purpose of IceFaces is to sell you support. The only fix for 1.7.1 was to patch the source for the release manually, not horrible, but I'd expect better.

That said I found IceFaces to be a useful product and much better than RichFaces, especially in terms of the quality of the documentation. However if I were starting now I'd also take a look at GWT if you want a real open source product or Flex if you want something very rich and thick client-esque. Event with all it's problems I'd still recommend Icefaces but it could definitely be better

Answer 7

We are using ICEFaces and is very easy to develop a rich Application. The major feature is the scalable Ajax Push server.

ICEFaces use a persistent client connection from the client and if you server doesn’t use asynchronous socket then it will need to create a thread per connection. As the number of users goes up, thread context switching can adversely affect performance. The good news is that ICEFaces already support ARP (Asynchronous Request Processing) from (Glassfich, Jetty, Tomcat, JBoss). In addition to that the implementation comes with an Asynchronous HTTP Server that you can use with your currently environment (e.g. Websphere).

“With ICEFaces you don’t need java script at all”. This is great in many scenario, but sometimes you don’t want to make an ajax call to just check a checkbox or activate a textfield. Adding javascript to do that is not rocket science but it leave your code a bit uggly.

Is true that ICEFaces treats its contract paying users as first class citizens (that is what I would expect after paying support :D ), but you always have access to the code. Is very easy to download a tag version and compile it with ant.

Answer 8

For those interested in the book:

http://www.slideshare.net/rainwebs/the-icefaces-book-an-introduction-2454368