JSF Central - Inside ICEfaces with Ted Goddard
JSF Central

 Articles & Books 
Community Chat
Inside ICEfaces with Ted Goddard
by Kito Mann
01 Jul 2008 02:00 EDT

This podcast is an interview between JSFCentral editor-in-chief Kito D. Mann and ICEsoft senior architect Ted Goddard. It was recorded in May of 2007 at the JavaOne conference in San Francisco, CA. You can catch Ted Goddard and other JSF speakers at the September 2008 JSFOne conference.

Podcast (MP3)
Welcome to the JSFCentral podcast #3 for the week of June 30th, 2008. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
We' re proud to announce JSFOne, the one event exclusively focused on the JSF ecosystem, taking place September 4th through the 6th in the Washington, DC area. JSFOne is a conference for application developers, solution architects, and project managers who develop applications with JavaServer Faces, Seam, and related technologies. Our speakers are deeply involved in every aspect of the JavaServer Faces ecosystem, from developing core technologies to building real-world applications. JSFOne is hosted by JSFCentral and the No Fluff Just Stuff Symposiums.
Kito Hello I am here with Ted Goddard from ICEfaces. We are at JavaOne 2007 on the last day. I think everyone is a little tired, just a few more things to do. We are going to talk a little bit about ICEfaces and JSF. Ted, to start out with just tell us who you are and what you do.
Ted I am the senior architect for ICEfaces and I was instrumental in developing the original prototype of ICEfaces, and now it' s really exciting to have it in its current form where it is a widely used Ajax framework.
Kito What else does ICEsoft do? Obviously there is ICEfaces, which we will talk about in great detail, but what else does the company do and how long have you been with the company?
Ted I have been with the company about three years. ICEsoft has ICEpdf and ICEbrowser. These products predate ICEfaces considerably. ICEbrowser comes out of a university project in Norway, and ICEpdf is a more recent project. All of our products are pure Java, and have been throughout.
Kito Okay, so moving back to ICEfaces, tell us a little bit more about it. You said Ajax, we know it' s JSF, what else can you say?
Ted ICEfaces is an Ajax framework for JavaServer Faces. What we really focus on is Ajax Push capability, which is unique to ICEfaces as a framework right now, and also the clean separation of designer and developer roles, which works very well with ICEfaces.
Kito Okay, so you talk about Ajax Framework and Ajax Push, let' s talk about the Ajax Framework part. Is ICEfaces a component suite or framework or both?
Ted It' s both really. ICEfaces starts off with an architecture for updating the page. Once you have the ability to generally update the page, you start using a technique we call Direct-to-DOM rendering. Then you can build a bunch of interesting components around that. We also make use of some JavaScript libraries like Prototype and Script.aculo.us so that we can expose the capabilities of Script.aculo.us to the developer. Script.aculo.us is a really nice JavaScript API but what if you are not a JavaScript developer? Then you need a nice Java API for working with Script.aculo.us, so what we do is provide Script.aculo.us effects modeled in JSF so that the JSF developer can have drag and drop and effects capabilities.
Kito For those who aren' t familiar with Script.aculo.us, what other types of -- when you say effects what does that mean?
Ted The ability to highlight something, or grow or shrink, or fade-in or fade-out. All of the fancy dynamic HTML capabilities that people associate with Ajax, although they aren' t strictly speaking Ajax, they are just modern dynamic HTML techniques.
Kito You mentioned Direct-to-DOM techniques, what is that?
Ted Direct-to-DOM is the technique that ICEfaces uses to render the JSF components. The way it works is, instead of rendering to a stream as JSF normally would, ICEfaces components render into a document object model on the server. That allows us to efficiently detect just the changes to that DOM and send just the changes down to the browser. The ability to send just the changes to a browser page is one of the key user interface features of Ajax. When you interact with an Ajax application, you don' t want a full page refresh, you just want the page to be updated in place. This change detection through the Document Object Model on the server is a very effective way to do that.
Kito So basically the idea is that since you have a Document Object Model on the server, you can basically replicate the same Document Object that is running the browser on the client, right?
Ted That' s right. It' s not an exact replica and it doesn' t need to be because there are browser differences in how their DOMs behave. The replica is completely sufficient for reconstructing the effect on the client.
Kito Okay, so given the fact that you have this specific way of doing rendering, how well does ICEfaces work with other JSF components?
Ted Component interoperability is always a challenge with JSF. Even though we talk with them as components, it' s difficult to mix and match components. Having said that, the Direct-to-DOM rendering is not really the difficult part of component interoperability for ICEfaces. The way that Direct-to-DOM rendering works is that – if you are familiar with some of the internals of JSF, there' s a response writer. The response writer is what components invoke to do the rendering. We provide a response writer that takes the response writer calls and converts them into DOM construction methods. That means that existing components can call into the response writer and manipulate the DOM. That way the existing JSF components or the third party JSF components do render correctly. The problem comes with interoperability typically in JavaScript, because many different components from different developers take different JavaScript strategies and the JavaScript can interfere with each other. For JSF 2.0, that is one thing we are really looking forward to, a bit of standardization around how components should interact with each other through JavaScript.
Kito Hopefully we can make some progress in that area. Tell us a little bit more about the Ajax Push feature.
Ted I think Ajax Push is really exciting. When you ask yourself “is Ajax an evolution or a revolution?” -- I think if the only change with Ajax is that it' s not a full-page refresh when you click on something, that' s really an evolutionary change. You can' t create applications with that technique that you could not create before. They are just a little bit more pleasant, but they really do the same kind of thing. With Ajax Push you can actually create applications that are different in a much more dramatic way than the applications that just use regular Ajax, that is driven by user events. I think there are two classes of behavior that you get with Ajax Push. I should maybe say what Ajax Push is to begin with. Ajax Push is the ability for the server to update the page, as initiated by the application. Normally with Ajax you still initiate changes to the page from the user, it is like a regular web request. The user clicks on a button and submits the request to the server, the server processes it and then returns some sort of page that enters data for the component. With Ajax Push, at any time the server can edit the page. That means that the server can notify the user of interesting application level events, or in particular, if you have multiple users in the same application, then information from one user can be relayed to another through the server. Then the server becomes this channel for mediating communication between users. When you look at this from a Web 2.0 point of view – Web 2.0 is all about how the users of the web are a greater part of what makes the web. People are blogging and posting things on the web and the web is created by the people that use it. Yet the web pages themselves aren' t truly interactive. In order to bring a new level of interaction and participation to the web you need something like Ajax Push to actually convey messages from one user to another so that when multiple users are within the same application they can interact directly with each other through this technique.
Kito How is Ajax Push different from Comet?
Ted Comet is a specific implementation of push techniques. I would say that Ajax Push is being used as a general phrase for referring to Push technologies with Ajax. The underlying mechanism is often – and this is the one that we use with ICEfaces and that we refer to as Ajax Push – is that the browser makes a request to the server and the server simply waits on that request until it has a message to send to the client such as a page update. It is a blocking HTTP connection, some people also call this long polling. When the server has a page update it sends a message to the browser and the browser asks the server to obtain more page updates. This essentially inverts the message flow of HTTP, giving you the ability to send messages from the server to the client.
Kito So if you have a blocking HTTP request. Isn' t there like a limitation of two connections open from the browser?
Ted That' s true and that is unfortunate. What you have in the multi-window case is these multiple windows which are sandboxed from the JavaScript point of view and yet they are sharing this scarce two-connection resource. What we do in ICEfaces is we use a shared cookie mechanism for the multiple windows to coordinate their behavior over this shared channel. What we would really like to see is the browser vendors to simply adjust their policy that it is a two connection limit per frame. The JavaScript sandboxing should be reflected in the communication sandboxing as well. That would be a very simple change to most browsers to change the policy on the two connection limit. Beyond that, it would be interesting to have control of HTTP pipelining from JavaScript, to extend the XMLHttpRequest API to actually support HTTP 1.1.
Kito Has anyone actually talked about doing that?
Ted There is discussion about these things in the Open Ajax.
Kito And you guys are a part of that, right?
Ted Yeah.
Kito What else is Open Ajax talking about?
Ted Open Ajax is working on interoperability within the page of JavaScript, so those are some of the collision problems that I had mentioned before. There is the communications hub, which is intended to allow multiple Ajax frameworks within the browser to share these scarce two connections.
Kito To take a step back to Ajax Push and everything, what do you have to do in terms of ICEfaces? Let' s say I am running an ICEfaces application, I know I could use some components like any JSF components, but obviously there is no JSF API for Ajax Push so what do you have to do from a programmer' s perspective to do Ajax Push in ICEfaces?
Ted We have made that as simple as we believe is possible. What we allow you to do in ICEfaces is to keep a reference to what we call the PersistentFacesState. When a page is rendered, you can get a handle on it – in some ways this is like a FacesContext that can last outside of the current request. You then have this object that represents the FacesContext of view that the user currently has. All you have to do is invoke render() on that view. ICEfaces will figure out through the Direct-to-DOM technique, the minimal page update and push it down to the browser. Really you can take an existing JSF application – how do you develop and Ajax Push application? Well, you should first regard it as a non-Push application, just as a simple JSF application where the user would interact with it, and then you look at “what are the triggers in this application that should cause the page to be updated from the server?” Those triggers may come to your application in a variety of ways. They may be from one user performing an action, they may be from a JMS queue or it could be a callback from some other part. All that you have to do is look up which is the PersistentFacesState associated with that view, and call render() on it. You don' t have to figure out exactly what on the page had changed or anything like that at all.
Kito Let' s say you want to update all the views and just iterate through…
Ted You could iterate through them and if there is no change in the view, ICEfaces won' t push anything down. So it is actually an inexpensive operation really to add Push to your application -- there is one API method to learn and it can often be done in four or five lines of code.
Kito So you have the Ajax functionality -- Ajax Push. You have the connection open. What happens if something happens like you are in a wireless network and the network drops and comes back. What happens to your ICEfaces application?
Ted That' s configurable. We provide a heartbeat facility that lets you monitor the health of the connection, so it looks at how many heartbeat messages have been lost and it can tell that perhaps the connection is marginal. It can display that to the user. Or the connection could actually be lost and it could explain that to the user. If the connection truly is lost, then you can re-load the page. Provided you are within your session timeouts, that will simply render the page again, redisplay it, and reestablish the Push connection. There is a user-interface mechanism for the user to be able to work with a faulty connection.
Kito How does ICEfaces work inside of a portal environment?
Ted Portals are challenging as well. We are just beginning to do some integration withLiferay portal and we in the past have done a bit of prototype work with portals. The prototype capabilities were present in an earlier ICEfaces release and people picked up on them really quickly and were actually using them. In our upcoming 1.6 release we intend to have officially supported portal capabilities. The challenges there are – first of all the resource loading aspect. Multiple portlets may use ICEfaces, so you would like the JavaScript for all of those portlets to be common. Especially since ICEfaces applications are typically built from the same components, there are a lot of re-used things like images from themes and that sort of thing, so you would like to have those images re-used. We found that it is a portlet-dependant way to commonly use resources across multiple portals. That' s a challenge. The other challenges for us are purely in the implementation and that is that – as you mentioned – we have this two connection limit from the browser. You don' t want two different ICEfaces portlets to fight over that two connection limit. There we simply have to insure that the JavaScript that we have for ICEfaces is able to properly detect if there is another copy of ICEfaces running in the same page and they will cooperate with each other and share those two connections.
Kito We talked about the most obvious features of ICEfaces, right? Basically that you do get Ajax support, effects from Script.aculo.us, Ajax Push, etc. What else is included?
Ted Some recent things we have been working on – of course portlets, as we had been discussing – and Seam integration has been a big effort for us. Seam has some interesting capabilities for the Ajax developer. In particular are the scopes that have been enhanced in Seam that lie beyond the normal web application scopes. Typically in a web application you have application, session, and request scopes, but for an Ajax application you need a scope that sits between session and request, because you could have multiple windows open and they are all in the same session, but the windows are distinct, yet the request is not sufficient to distinguish between them because the request only lasts – in the normal definition – for a single user interaction. In ICEfaces, to get around this we created a modification of the request scope, where we defined the request as lasting from one full-page refresh to the next. In that way, a series of user events would actually be within the same request, but because they were in a single full-page request, that allowed the developer to separate one window from another as being in these distinct full-page requests. But we would like to see this formalized. It is formalized nicely in Seam with the Seam conversation scope and some others.
Kito Also just to note there is the WebBeans JSR, which will actually formalize it as part of Java EE or some part of the Java platform. Let' s go back to the components. Let' s say someone gets ICEfaces and all these great features, what kind of components can be used?
Ted First I would like to mention that really interesting ICEfaces applications can be built from the primitive components -- simply, input text, output text, and buttons -- because when you add the Ajax capability of Direct-to-Dom, those primitive components turn what is essentially… because the primitive JSF components allow you to describe an HTML page, and then you can make that HTML page dynamic by binding all of that into the backing beans. You [can] imagine that what it gives you is a language for dynamic pages that are updated via Ajax. ICEfaces has that effect. Not all developers want it to work that way. Of course it is really important to re-use advance capabilities that other people have packaged together, even though this primitive capability is actually very expressive. What we provide with ICEfaces is we have tree and menu and tabs and data tables and charting. Drag and drop is one of the more fun components to use. What we do there is we expose drag and drop in a nice object oriented way to the JSF developer. We allow you to take a panelGroup and simply make it draggable. You set draggable=true on a panelGroup and that means that anything that you put into that panelGroup can be dragged around and then dropped on to another panelGroup that has a drop region set on it that is true. Then when a drag or drop event occurs, you get that as a JSF event and you are passed in the components and objects associated with that event. For the JSF developer, you will find that this is as natural as using a commandButton or any other component. What' s interesting about it, in the case of drag and drop, is that there are two participating components in the event, which is a little bit unusual for JSF events, but still well within what you can express comfortably in the tag library.
Kito One of the things I have always wondered with Direct-to-DOM, and I think I mentioned this when I first met you, is the idea that you have this DOM tree that you are maintaining on the server, but JSF also maintains a component tree. For each view it seems like you have a component tree and an actual DOM tree that must be maintained on the server. I guess my question is how does that work out in high volume environments? What is the story there?
Ted I would say that it' s true, that there is a cost associated with maintaining these DOMs, although it is not significantly different from the cost associated with the component trees or the other state associated with JSF applications. In the current implementation, ICEfaces renders into an empty DOM for each component tree passed. In the past we would attempt to maintain a direct correspondence between the components and the DOM. That had some interesting properties to it. In that case it gave the components random access if they wanted. Components still have random access to the DOM if they choose to use that capability, but in the past we really emphasized the random access into the DOM and we thought perhaps that would be a more powerful API, and it is, but it is also more confusing for application developers. It is easier to write components in the stream fashion that they simply generate their markup. There are cases where having random access to the output is desirable. For instance being able to insert a .doc type at the beginning, or in general to be able to insert things into the head. You will see a lot of other JSF libraries go through fairly complicated gymnastics to get something into the head of the document. With ICEfaces, it' s trivial because you have the DOM and you can simply insert something in the DOM.
Kito I do think that whole head issue needs to be fixed in JSF 2. Okay, so ICEfaces itself is open-source right?
Ted That' s right, under the Mozilla public license.
Kito Okay, now you have another product based on that which is called ICEfaces Enterprise?
Ted Yes, we have the enterprise edition. Enterprise contains an Async server which scales in its ability to handle incoming Push connections. It is likely that the Enterprise server will be open-source in the future too -- we are looking at that.
Editor' s Note: In July 2007, ICEsoft withdrew the commercially licensed Enterprise Production Suite from the market, and contributed the key features it provided to the open-source ICEfaces project.
Kito Okay, so basically you are modeled more around service and support for ICEfaces?
Ted That' s exactly right. Switching to open-source has been absolutely tremendous for ICEfaces. Originally we had a free product and you would think that free should be very appealing to people, but the difference between free and open-source is tenfold. Our downloads increased tenfold instantly simply by going open-source.
Kito Okay, do you have anything else you would like to add?
Ted No, I think that is all I had to cover.
Kito How was JavaOne for you?
Ted This was an excellent show, including CommunityOne, which we had on the day before JavaOne. We had a good session on Web 2.0 and Ajax Push, the attendance to the pavilion was excellent this year, as well as the session on using ICEfaces, jMaki and DynaFaces with NetBeans. I would say it was our most successful JavaOne yet.
Kito I missed that one, interesting. Thank you very much Ted.
Ted Thanks a lot.

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.