Tuesday, 16 December 2008

ICEfaces Becoming Integral To Sun's RIA Technology Stack

One of the primary considerations with the ICEfaces open source project is to embrace the Java EE ecosystem, with the goal of becoming a pervasive technology across it. We have always viewed Sun Microsystem's technology offerings from Glassfish to NetBeans as a critical part of that ecosystem, and have done extensive integration with both run-time and development technologies.

In the run-time space, ICEfaces has always maintained basic integration with Glassfish, but with the introduction of the Grizzly ARP mechanism we have gone way beyond the basics. ICEfaces is tightly integrated with Grizzly and delivers centralized Ajax Push capabilities to the Glassfish Server, making the deployment of scalable collaborative Web 2.0 applications a snap. And as the pioneers of Ajax Push for JSF, ICEfaces offers the most sophisticated solution available for asynchronous push-style web applications. The combination of ICEfaces and Glassfish/Grizzly is unparalleled in the industry.

On the development side, we have always strived to integrate with the Sun IDE of choice. Our efforts started with Java Studio Creator, and have continued with several releases of NetBeans, up to our current integration with NetBeans 6.5. Because Woodstock has been a primary consideration in the NetBeans JSF strategy, integrating ICEfaces into this model has been a major challenge, but we have succeeded in delivering both Visual JSF and Facelet support for ICEfaces in NetBeans.

With Sun's acknowledgment that they are discontinuing development of Woodstock, we are about the enter a new era of integration, with ICEfaces becoming a first-class citizen of the Sun stack. ICEfaces is the most natural replacement for Woodstock, and to that end we have begun to piece together a comprehensive migration strategy for Woodstock developers to move to ICEfaces. It starts with support for the coexistence of ICEfaces and Woodstock in the same web application, and will culminate with a variety of porting utilities that will partially automate the porting process. You can read all the details about what is available now and what you can expect to see in subsequent releases here.

With ICEfaces becoming integral to the Sun RIA solution, we are excited about the future integration that is possible. We envision an end-to-end solution for the development of rich collaborative web applications that are completely secure and scalable. Across the spectrum from run-time support to development tools, developer productivity will be enhanced and time to market for next-generation collaborative applications will be reduced. A good deal of this vision has already been realized, but given a tighter relationship with Sun we are in a position to accelerate our integration effort and get to the next level sooner. We are poised to deliver a solution that will be unrivaled in the industry, and that is pretty exciting to me. I will keep everyone posted as we progress.

Steve

Technorati Tags:

Posted by steve.maryka at 7:05 PM in Entries by Steve Maryka

Responses (0)

Friday, 12 December 2008

Woodstock To ICEface Migration Support Now Available

As mentioned in my previous posting, we have been working on support for Woodstock migration to ICEfaces. This is all now available here.

Steve

Technorati Tags:

Posted by steve.maryka at 3:23 PM in Entries by Steve Maryka

Responses (0)

Thursday, 4 December 2008

ICEfaces Surpasses 1 Million Downloads!!

In the ICEfaces Newsletter today we announced that we have surpassed 1 million downloads. That goes hand in hand with over 55,000 registered users from all over the globe. Recent statistics on www.icefaces.org illustrate highly activity projects in Denmark, India, Poland, Canada, USA, Germany, Italy, Chile, Czech Republic, Egypt, Taiwan, Mexico, Colombia, Belgium, Russian Federation, United Kingdom, Switzerland, Australia, Turkey, Spain, Norway, Brazil, China, Austria, Croatia and Sweden. So you can see momentum in the ICEfaces community is very strong.

We are not letting up though, with big plans for the coming releases. With 1.7.2SP1 we are poised to introduce significant capabilities that will help the Woodstock community migrate to ICEfaces with the least amount of pain possible. We will have more details on this coming out the week of Dec 8-12, so stay tuned. In advance of that, we welcome all you Woodstock users out there to the ICEfaces community.

ICEfaces 1.8 is currently at DR2, with plans for final release in Jan/09. With this release we have focused on performance and failover. We have made large strides in reducing both memory and computational requirements within the framework. We are also introducing failover capabilities for clustered deployments, including seamless failover for push-style applications. All of this positions ICEfaces well for large-scale enterprise critical applications.

Finally, planning has begun for ICEfaces 2.0, which will include a host of new exciting capabilities including support for JSF 2.0. You can look forward to seeing that release in Q2 of 2009.

So, we will celebrate our 1 millionth download briefly, and then get back to work.

Steve

Technorati Tags:

Posted by steve.maryka at 10:47 AM in Entries by Steve Maryka

Responses (0)

Wednesday, 5 November 2008

Lazy Loading a JSF DataModel for an ICEfaces ice:dataTable

Iterator components like the ICEfaces ice:dataTable have two special attributes: value and var. The value attribute is typically bound to a JSF model-managed-bean, and the var attribute introduces a new variable into the JSF Expression Language (EL) like this:

<ice:dataTable value="#{modelBean.rows}" var="row">
    <ice:column>
        <f:facet name="header">
            <ice:outputText value="#{msgs.firstName}" />
        </f:facet>
        <ice:outputText value=#{row.firstName}" />
    </ice:column>
    ...
</ice:dataTable>

The ModelBean.getRows() method can return a variety of types, but in my experience the most typical one is a generic java.util.List like this:

public List<Row> getRows() {...}

Under the hood, JSF is expecting the value attribute to contain an instance of a JSF DataModel object. In fact, if you don't return a DataModel, JSF will implicitly wrap your return value with a wrapper class, such as the ListDataModel for values of type java.util.List.

Typically, the model bean that contains the data is kept in JSF session scope or ICEfaces extended-request scope. This is fine if you only have 10 or 20 rows in the result set, but what if you have 1,000,000 rows? Obviously there is a scalability concern in such a case, especially since the user is only going to be viewing 10 or 20 rows at a time in the browser.

Unfortunately, the JSF spec does not provide a way of loading data on demand (popularly known as "lazy loading" ). I've seen several posts on how to do this, but I thought it would be nice to develop a persistence-technology-independent solution.

To this end, I wrote an abstract class named LazyDataModel.java that is meant to be subclassed into a concrete implementation. Feel free to download the LazyDataModel.java (zipped) source code.

Here are the three methods you will need to supply in your concrete implementation:

public abstract int getRowsPerPage();

public abstract int countRows();

public abstract List<DTO> findRows(int startRow, int finishRow);

The DTO marker implies that this class is meant to be used at the JSF UI layer of a webapp/portlet, and that it is meant to be used in conjunction with the Data Transfer Object design pattern (formerly known as the Value Object / VO design pattern).

BTW, in order for this to be of benefit to the end user, you'll need to connect an ICEfaces ice:dataPaginator component to the ice:dataTable iterator. That will provide icons for navigation such as first-page, previous-page, next-page, and last-page.

 

Posted by neil.griffin at 3:20 PM in Entries by Neil Griffin

Responses (0)

Friday, 3 October 2008

Webinar: Filthy Rich Portlets with ICEfaces and Liferay

Update! An archive of the webinar is now available on ICEfaces .org in both .wmv and quicktime: http://www.icefaces.org/main/resources/webinars.iface (3rd item in the Archive Webinar list)

Also, here is a video+transcript of a similar presentation given at the JSFOne conference: http://java.dzone.com/videos/filthy-rich-portlets

If you missed out on JSFOne 2008, then please attend the webinar that I'll be hosting:

Webinar Title: Filthy Rich Portlets with ICEfaces and Liferay

Webinar Date/Time: Tuesday, October 14, 2008 1:00 PM - 2:00 PM EDT

Webinar Link: https://www1.gotomeeting.com/ojoin/451479046/1859554

Webinar Slides and Demo Downloads:

The sources are meant to be extracted into the "plugins" folder of the Liferay Plugins SDK. Fore more info, download the the Liferay Plugins SDK documentation.

Webinar Overview:

  • Portals and Portlets
  • Liferay Portal
  • JSF Portlets
  • ICEfaces Portlets
  • Standard Inter-Portlet Communication
  • Ajax Push Inter-Portlet Communication
     

Posted by neil.griffin at 4:02 PM in Entries by Neil Griffin

Responses (0)

Thursday, 25 September 2008

Ajax Push via WebSocket for ICEfaces?


ICEfaces currently uses XMLHttpRequest to implement Ajax Push, but will better networking capabilities be available in the future, such as WebSocket? Join us to discuss WebSocket, Ajax Push, and Comet at the Silicon Valley WebBuilder Panel on October 29, 2008.

The panel has a great lineup of people who don't always agree (this is a good thing for a panel):

ICEfaces and cometd take fairly different approaches to solving "push" on the web.

The cometd approach is to generalize messaging between JavaScript objects so that they can exchange arbitrary messages with each other (even if they're in different browsers). The server may act only as a reflector. In other words, JavaScript is regarded as first-class and messaging between distributed objects characterizes the application architecture.

The ICEfaces approach is to make Ajax fully asynchronous: with Ajax we can update the page incrementally (without a full page refresh); Ajax Push allows the application to issue incremental updates at any time, independently of user events. The result here is that the server is primary and JavaScript is used only to implement the page update mechanism. The standard Java web application architecture remains in force.

Will WebSocket help us implement such things? What about HTTP 1.1 pipelining for XMLHttpRequest? Please join us to find out.


Technorati Tags:

Posted by ted.goddard at 6:19 PM in Entries by Ted Goddard

Responses (0)

Monday, 15 September 2008

Ajax Push TV


We'll be bringing out more extensive video sessions on ICEfaces, Ajax Push, and Portlets recorded at JSFOne, but in the meantime, here are some short interviews that you may find of interest:

  • Jeremy Geelan with SYS-CON TV (focusing on Ajax Push as a necessary part of Ajax and how it can allow you to make better business decisions through timely information)
  • Andrew Glover with JavaWorld (a brief, but technical introduction to how ICEfaces is used and how it works)

Technorati Tags:

Posted by ted.goddard at 6:25 PM in Entries by Ted Goddard

Responses (0)

Wednesday, 10 September 2008

ICEfaces on Blackberry Bold


ICEfaces applications are reported to work on the BlackBerry Simulator JDE v4.6.0; the question is whether they work on a real device. Has anyone had a chance to test the ICEfaces demos on a BlackBerry Bold?

Technorati Tags:

Posted by ted.goddard at 6:30 PM in Entries by Ted Goddard

Responses (0)

Seam in Action


Seam in Action is now available:

Seam is very powerful, but there's a lot to learn, so picking up a book like this really is essential. After using JavaServer Faces in a complex application, you will quickly find that the navigation and dependency injection capabilities in faces-config.xml just aren't sufficient. Seam is what you need.

The best chapter is, of course, Chapter 12 on Ajax. We really appreciate the time that Dan spent working with people at ICEfaces.org to enhance this chapter. In particular, Judy worked to port the Open18 application to ICEfaces. There is no question that the best information in print for ICEfaces is now found in Seam in Action.

I really only planned to mention Dan's book, but then this three legged dog showed up on our roof, and that's strange enough that I had to include it:


Technorati Tags:

Posted by ted.goddard at 6:17 PM in Entries by Ted Goddard

Responses (0)

Friday, 1 August 2008

JSFOne


JSFOne is rapidly (if you account for summer vacation) approaching: September 4th - 6th, near Washington D.C. It looks to be the most comprehensive JavaServer Faces event yet and will be a good opportunity to learn about and discuss JSF 2.0. As an ICEfaces community member you are eligible for a substantial discount if you register before August 15th (let us know if you missed the email with the registration code). Here are some of the sessions on ICEfaces:

We hope to see you there. Also, don't forget to check out Dan's new book, Seam in Action (especially the Ajax chapter).

Posted by ted.goddard at 3:04 PM in Entries by Ted Goddard

Responses (0)

Monday, 28 July 2008

Snappy Calendar and Table components for ICEfaces


There are many dimensions to Ajax, yielding many different possible approaches. One particularly interesting dimension is the division of labour between client and server. Generally, ICEfaces assigns the most work to the server, treating the browser as a remote display. There are a number of reasons for this:

  • The data is on the server.
  • Server-side logic is not open to inspection by attackers.
  • MVC is preserved.
  • Only server-side events can trigger Ajax Push.
  • Java code is far easier to write and maintain: client-side code requires custom JavaScript.

So how do you implement a date picker? As a custom JSF component, of course. Clicking on an arrow to the right of "July" updates the page with a new calendar for "August", containing an <h:commanLink> for each day of the month. It can handle a wide range of locales and can account for varied daylight savings time legislation throughout history. But if we ignore the chaos introduced by daylight savings time, is this ultimately the right solution from a distributed computing point of view? Wouldn't it be more efficient to page through calendars in the browser, and only submit data to the server when the user had actually picked a date?

Of course, a client-side date picker is more efficient at runtime; the reasons that ICEfaces took a server-side approach with this particular component were because, at the time, we didn't want to write the JavaScript and we wanted to experiment with a component as complex as a date picker.

As an alternative, the Snappy Calendar is a purely client-side date picker for ICEfaces. You will also find a Snappy Table that provides a client-side table with sorting and row selection. There are two particularly interesting things about these components: one, that they are client-side implementations; and two, that they are developed outside ICEfaces.org. Please try them out and provide your comments directly to the author or on the ICEfaces forums.

Technorati Tags:

Posted by ted.goddard at 5:02 PM in Entries by Ted Goddard

Responses (0)

Thursday, 12 June 2008

ICEfaces at Jazoon


Jazoon 2008 will be starting shortly (June 23 - June 26), and you'll have several opportunities to learn about Ajax Push at the conference:

mimacom ag has a great deal of experience building enterprise applications, and is now a strategic ICEsoft partner. The beginning of this partnership can be seen in an interactive locking demo that we have put together for Jazoon. The essential idea is to build collaboration features through the mimacom edoras lock manager and ICEfaces Ajax Push. The demo allows multiple users to edit and lock records in a common data set. Besides being able to see changes to the data in real time they can also negotiate locks through chat and lock operations right within the application.

The locking demo will be featured in the Jazoon talk and at the mimacom exhibition stand (where you can learn how to apply edoras and ICEfaces to build a complete application). For GlassFish Community Day, I plan to demonstrate WebMC and possibly the new SIP telephony demo.

Posted by ted.goddard at 6:07 PM in Entries by Ted Goddard

Responses (0)

Wednesday, 11 June 2008

Ajax Push and the Telephone


The telephone is an excellent source of asynchronous events — you never know when it is going to ring. This means that web-based views of the telephony space make for interesting applications of Ajax Push.

Using SailFin and ICEfaces we've put together a very simple call setup demo. It shows when your phone is online and allows you to initiate a call between any two phones just by selecting them and pressing "call".

To run the demo:

  1. Download a recent build of SailFin.
  2. Download the demo binary callsetup.sar. 
  3. java -Xmx512m -jar sailfin-installer-v1-b36-darwin.jar
cd sailfin
ant -f setup.xml
bin/asadmin start-domain domain1
bin/asadmin start-database
cp callsetup.sar domains/domain1/autodeploy/
  4. Point your SIP phone (such as X-Lite Demo) at a localhost Proxy.
  5. Point your browser at http://localhost:8080/CallSetup/registrations.iface

As phones connect and disconnect, the list in the registrations page will be dynamically updated, showing user presence.

The full source code is available at http://anonsvn.icefaces.org/repo/projects/CallSetup/

Technorati Tags:

Posted by ted.goddard at 4:43 PM in Entries by Ted Goddard

Responses (0)

Monday, 2 June 2008

Ajax Push in Real Time?


One popular question on our road trip has been "How do I ensure that each Ajax Push is delivered to all clients at the same time?" (By the way, if you don't happen to be a resident of Vancouver, Montreal, or Toronto, you can still catch the talk as a one hour webinar on Monday, June 2, 2008. Be sure to check out the other ICEfaces webinars that same week. If the webinar isn't convenient, Jeanfrancois has a copy of the slides available.)

Of course, it's not actually necessary that the page updates arrive at each client at exactly the same time, just that they arrive within some short interval. In the past, I have objected to applying the term "real time" to Ajax Push on the web. Real time systems typically are used to control physical processes and often have tolerances of a few milliseconds (using Java for real time applications is challenging enough, let alone using Java over the internet). Web2.0 is not yet ready to run your car's antilock breaking system from a central server (I'm sure Web3.0 will easily handle this, though).

But when we define a real time system as one where success is determined not just by the results of the computation but also by having the response within a certain deadline; and further, that a soft real time system is simply considered to provide a lower quality of service when deadlines are missed, it becomes possible to consider Ajax Push from a soft real time perspective. (We have removed the expectations that system responsiveness must be within a few milliseconds, or be "instantaneous", and that the system must be used to control a "real" physical process; instead, we focus only on the timeliness guarantee.)

We can now measure the quality of an Ajax Push system in soft real time terms: assign a time interval based on the application (say, "all bid notifications should be received within 3 seconds of the bid"), and measure the proportion of page updates delivered within the time interval (the more updates that lie outside the interval, the lower the quality of the system). Then, we can work on producing a system capable of operating at the desired quality. The good thing is that the problem is easily parallelized -- each node in a cluster can independently determine the page updates for its sessions (database and network infrastructure may not be so easily parallelized).

In other words, to ensure that updates are delivered in a timely fashion (that is, to satisfy our soft real time requirement) it's important to exploit parallelism within the cluster and to measure the running time of the Ajax Push updates under realistic application conditions. Producing the page updates for each user takes an application-dependent amount of time; this must be measured for the application and hardware planned accordingly.

Technorati Tags:

Posted by ted.goddard at 2:35 PM in Entries by Ted Goddard

Responses (2)

Tuesday, 20 May 2008

Ajax Push Across Canada


Jeanfrancois and I will be on the road next week (ok, we're mostly flying) to explain how to use Ajax Push and non-blocking I/O in Web2.0 applications. The sessions are free, but please register to reserve your spot and have a chance to win an iPod touch:

The new ICEfaces technology behind these talks lies in two areas: Grizzly auto-detection, and a new Ajax Push API (SessionRenderer). Grizzly auto-detection helps you know when a grizzly is around. It's important for safety reasons, but it also makes application deployment easier -- ICEfaces automatically takes advantage of the threading scalability provided by Glassfish (you no longer need to configure GrizzlyPushServlet yourself).

The SessionRenderer is important because it considerably simplifies the development of Ajax Push applications (we're looking for community feedback on this API -- by introducing it in the org.icefaces package we won't freeze it until ICEfaces 2.0). One feature is that sessions are rendered rather than views (in other words, all views in a session are rendered) considerably simplifying the bookkeeping required by the application. The other feature is that the groups of sessions are maintained by the SessionRenderer and automatically cleaned up as sessions expire. This allows the application to refer to the groups by name, again eliminating bookkeeping in the application.

Technorati Tags:

Posted by ted.goddard at 4:45 PM in Entries by Ted Goddard

Responses (0)