Home

News: ICEfaces Enterprise Edition 1.0, JSF implementation, released

  1. ICEsoft has released ICEfaces Enterprise Edition 1.0, an implementation of JSF that relies heavily on AJAX functionality. ICEfaces has an "AJAX bridge" that allows serverside updates to be delivered immediately to clients for consistent live updates to clients. The enterprise edition adds clustered deployment support, an advanced connection manager, an asynchronous HTTP server, and more support options. The AJAX bridge allows updates to a component to be presented on multiple client sessions with no client code. For example, at JavaOne 2006, a demo was shown of an online auction, where the bids from two separate browser sessions (on different machines) affected each other. The clustered deployment support in ICEfaces Enterprise Edition extends this capability across a cluster, so that the browsers could be using two separate servers as well. The advanced connection support provides heartbeat and recovery functions to the clients, as well as advanced error reporting capabilities. The Asynchronous HTTP Server provides high-scalability support for ICEfaces applications that utilize Server-initiated Rendering ("server push") and must be deployed to high volumes of concurrent users. Server-initiated Rendering depends on a virtual-connection model that can require additional server-side resources to maintain, particularly threads and sockets. When using application servers without the Asynchronous HTTP Server the concurrent-user scalability of the application is highly dependent on the number of sockets and threads that the specific server configuration can support effectively. The Asynchronous HTTP Server supplements the application-server to remove the thread/socket resource dependencies and provide a virtual-connection implementation that is scalable to very high numbers of concurrent users.

    Threaded Messages (20)

  2. Impressive[ Go to top ]

    This is some very impressive stuff to say the least. However, it annoys the crap out of me when people don't put pricing information on the page. So I assume this is a free product then? lol
  3. Re: Impressive[ Go to top ]

    I think we can assume that you will have to pay for it. Remember: if you have to ask the price you probably can't afford it. However, as you will have given the sales weasel you details you might still be convinced.
  4. Re: Impressive[ Go to top ]

    I'm glad you like the demos and as a matter of fact, there is a free version. There are two editions: a Community Edition (CE) and an Enterprise Edition (EE). The CE is free for development and deployment. The EE does have a price (starting at $1500 per CPU) which is referenced in our latest press release (but not yet on our web site). The press release can be found here: http://www.icesoft.com/corporate/press_release_07_06_EE_1.0.html A comparison of the two editions can be found here: http://www.icesoft.com/products/icefaces_comparison.html There is a trial version of the EE that you can get so that you can try before you buy. Deryk Sinotte Senior Developer ICEsoft Technologies, Inc.
  5. Re: Impressive[ Go to top ]

    A comparison of the two editions can be found here:

    http://www.icesoft.com/products/icefaces_comparison.html
    Synchronous & Asynchronous Modes ICEfaces can be configured in either synchronous or asynchronous mode. Synchronous mode is used for web applications that do not require support for ICEfaces' Server-initiated Rendering feature ("server push"). Asynchronous mode must be used when Server-initiated Rendering support is required. Synchronous mode requires less network and server resources than asynchronous mode.
    I think that your notion of synchronous & asynchronous modes may confuse some people who apply these terms to XMLHTTPRequest object. Why have you had to call "server push" an asynchronous mode at the first place?
  6. asynchronous mode[ Go to top ]

    I think that your notion of synchronous & asynchronous modes may confuse some people who apply these terms to XMLHTTPRequest object. Why have you had to call "server push" an asynchronous mode at the first place?
    The terminology for synchronous and asynchronous modes has caused some confusion. We're now advocating the term "Ajax push" for the underlying capability of server-initiated or application-initiated rendering (what we have so far been calling asynchronous mode). The funny thing (and the reason why the terminology becomes confusing) is that normal Ajax applications are actually synchronous in a fairly strong sense (even though they use the asynchronous mode of XMLHttpRequest) -- page updates are strictly driven by user events; i.e. the application is synchronized with those user events. ICEfaces (and potentially other Ajax push or COMET applications) can be truly asynchronous -- page updates can occur without initiation by user events. So, ICEfaces is asynchronous in a strong sense (and goes further towards the goal of Ajax, which is to decouple the user from being an HTTP client), but that may be confusing for people focused on the low-level details of XMLHttpRequest (hence our current advocacy of the term "Ajax push").
  7. What are benefits of ICEFaces comparing to Google Web Toolkit? This is what I could come up with. Granted, I haven't used ICEFaces yet, so something may be wrong in this list. Similar features GWT: J2EE-based, ICEFaces: same. GWT: Ajax only, ICEFaces: can be rendered with Javascript turned off, but will not submit. GWT: has basic set of widgets, ICEFaces: same. GWT: can be easily styled with CSS, ICEFaces: same (?) GWT: does not need knowledge of Javascript, ICEFaces: same (?) GWT: UI elements can be properly resized by browser controls, ICEFaces: same GWT: UI elements can be combined with static HTML, ICEFaces: same GWT benefits GWT: views are developed fully with Java, ICEFaces: requires JSF tags GWT: can be easily debugged, ICEFaces: not so GWT: clean separation of concerns between UI and server, ICEFaces: ? GWT: talks to standard servlet, ICEFaces: requires JSF GWT: widgets are easily extensible, ICEFaces: ? ICEFaces benefits ??? Echo2 Echo2 feels very slow. Maybe it is a flip side of having a lot of features (transparent windows anyone?). I would like to see a lean and mean Echo2 demo instead of a kitchen sink.
  8. This is really a question of GWT development vs JSF development (note that JavaServer Faces is a Java standard, so ICEfaces applications really are "developed fully with Java"). The GWT approach is certainly very interesting. To respond to some of the specific points: ICEfaces components are all styled via CSS and the ICEfaces developer needs no knowledge of JavaScript. JSF (hence ICEfaces) provides very clean separation of application and UI code; in fact, it could be argued that the use of a markup language (JSF tags) for the UI and the use of Java for the application helps to enforce this separation. New ICEfaces components can be developed within the JSF component framework. One of the easiest ways to develop new ICEfaces components would be to make use of the templating mechanisms in Facelets.
  9. GWT benefits
    GWT: views are developed fully with Java, ICEFaces: requires JSF tags
    I haven't looked at GWT but this sounds a lot like using GWT takes me back to coding the view-code in a servlet ? More times than not, projects I have worked on start from static HTML prototype pages and the functionality is added using JSP and/or JSF tags. This preserves the look and feel. Does GWT take me away from that ?
  10. GWT benefits
    GWT: views are developed fully with Java, ICEFaces: requires JSF tags


    I haven't looked at GWT but this sounds a lot like using GWT takes me back to coding the view-code in a servlet ?

    More times than not, projects I have worked on start from static HTML prototype pages and the functionality is added using JSP and/or JSF tags. This preserves the look and feel.

    Does GWT take me away from that ?
    AFAIK, GWT widgets can live happily in HTML page that can be generated with JSP, JSF or other scripting/templating engine. I don't know whether GWT widgets can be previewed as a part of a static HTML page, but I don't see reasons why not. Widgets are just piece of Javascript running in browser. There should be a simple way to provide them with canned data for preview. To me GWT is not return to servlets, it is return to normal desktop programming.
  11. To me GWT is not return to servlets, it is return to normal desktop programming.
    To me GWT is one step further than JSF in that direction (desktop programming). While JSF tries to simulate the desktop programming paradigm for the classic Web, GWT gives your user desktop-like experience.
  12. More times than not, projects I have worked on start from static HTML prototype pages and the functionality is added using JSP and/or JSF tags. This preserves the look and feel.

    Does GWT take me away from that ?
    The question really is, does JSF take you away from that? This is probably one of the reasons JSP + Action MVC will remain as mainstream.
  13. More times than not, projects I have worked on start from static HTML prototype pages and the functionality is added using JSP and/or JSF tags. This preserves the look and feel.

    Does GWT take me away from that ?


    The question really is, does JSF take you away from that?

    This is probably one of the reasons JSP + Action MVC will remain as mainstream.
    How does JSF take me away from that ? I still replace the static html controls with JSF tags and code the server-side functionality. The comment I originally quoted, "views are developed fully with Java, ICEFaces: requires JSF tags", seemed to indicate that there were no more page files and everything was created using server-side Java Code.
  14. How does JSF take me away from that ? I still replace the static html controls with JSF tags and code the server-side functionality.
    Then what's the benefit of using JSF?
  15. Echo2
    Echo2 feels very slow. Maybe it is a flip side of having a lot of features (transparent windows anyone?). I would like to see a lean and mean Echo2 demo instead of a kitchen sink.
    Hi Michael, I wanted to ask what you saw in Echo2 that gave you the impression it was slow? Was there a lag in response time after user input, did the application take too long to load new elements of the user interface, or did the animated effects not render smoothly? If you have time, I'd greatly appreciate an email at tliebeck [SHIFT-2] nextapp [PERIOD] com about what you saw. I can say that the main demo app ( http://demo.nextapp.com ) can be fairly taxing on the client machine. If you have an older computer or are running non-accelerated video drivers, the transition effects (e.g. sliding and fading transitions) won't be as smooth as we'd like. All effects are implemented to render in a specific time, rather than a specific number of frames, so slower machines should only see a notchiness in their rendering, rather than having to wait for X frames to render. My main development machine does not have HW accelerated video drivers since I upgraded to Fedora Core 5 (and I just plain haven't had time to do anything about it) so I get to see this problem first hand. :D One more issue that will slow Echo2 down dramatically is if the "debug pane" is left open. There are a few other demonstration apps available here that are less showy: http://www.nextapp.com/platform/echo2/echo/demo/ Anyway, appreciate any input on what you saw that made Echo2 appear slow. Best regards --Tod Liebeck NextApp, Inc.
  16. A free alternative[ Go to top ]

    Echo2 is a similar framework with the exception of not using JSF and being open source it is distributed under the MPL. It was one of the first Ajax based web frameworks, it is verry mature and has a very swing like API. If you have not checked it out it is worth a look.
  17. Re: A free alternative[ Go to top ]

    Of course, the ICEfaces Community Edition is a free alternative to the ICEfaces Enterprise Edition. As was discussed here http://www.theserverside.com/news/thread.tss?thread_id=40717#210631 besides relying entirely on a proprietary API, Echo2 does not appear to support application-initiated ("Ajax Push" or "COMET"). Is this the case?
  18. Re: A free alternative[ Go to top ]

    Echo2 does not appear to support application-initiated ("Ajax Push" or "COMET"). Is this the case?
    Echo2 does support server push AKA COMET
  19. JSF implementation[ Go to top ]

    Wow, congratualations ICEsoft on the completion of a JSF implementation. Which version of the spec has been implemented? Is the implementation TCK compliant?
  20. Correction[ Go to top ]

    FWIW, ICEfaces is not a JSF implementation; rather, it's a JSF RenderKit. So, you can use ICEfaces with either the JSF reference implementation or Apache MyFaces. You can even use it with some of the Apache MyFaces Tomahawk components. ICEfaces and other frameworks that are coming out (Seam comes to mind) are good examples of how powerful and flexible JSF's architecture is. Kito D. Mann JSF EG Member, Author of JSF in Action http://www.jsfcentral.com
  21. Re: Correction[ Go to top ]

    FWIW, ICEfaces is not a JSF implementation; rather, it's a JSF RenderKit.
    I know :) ... I was just having a little fun. On a serious side, congratulations to the ICEfaces team for producing such a great RenderKit. Are any of these guys on the EG? I'd love to see some of these ideas make it into the next spec.