Thursday, 3 December 2009

High-Availability Ajax Push Deployments - An Industry First For ICEfaces EE

Anyone that has witnessed the Google Wave demo knows that real-time, collaborative web applications are upon us. Web-based Ajax Push is fundamental to these types of applications, and has also been fundamental to ICEfaces since the very first release of the framework. Google's excellent adventure aside, we see Ajax Push moving out of the early adopter stage and into serious enterprise deployments with stringent scalability and availability requirements.

ICEfaces is keeping pace with these revolutionary deployment requirements by introducing industry-first capabilities in the Enterprise Push Server (EPS), which is now available in the newly-released ICEfaces Enterprise Edition 1.8.2. You can read more about EPS here, or if you are a supported customer a more detailed description is available in the ICEpack wiki here.

There are a few solutions in industry today that deliver Ajax Push capabilities, and most of them, including ICEfaces, relying on the long-polling technique to deliver asynchronous push updates to the browser. This technique requires an open connection to be held in anticipation of push events, which works fine if you only have a single view onto a single web application, as only one push connection is required. A major problem manifests itself though when you open multiple browser views onto the same web application, have multiple push-enabled applications deployed within the same domain, or have multiple push-enabled portlets in the same page. It is not feasible for each view to maintain its own push connection, as this will exceed the browsers connection limit, so it is necessary to share the push connection among the views. ICEfaces solves this problem with the client-side Ajax Bridge performing connection sharing between the browser views, and the Push Server managing a single blocking connection at the server for each browser client. No other Ajax Push technology offering provides a comprehensive and transparent mechanism for connection sharing.

Returning our attention now to enterprise-grade, clustered, high-availability deployments, we see the push connection management problem compound itself, as now we need to support load sharing and fail over of push connections. This is the domain of the Enterprise Push Server, which delivers those precise capabilities, as illustrated in the deployment architecture diagram below.

EPS Deployment Architecture

The architecture leverages standard Java Enterprise clustered deployment capabilities using front-end load sharing with session affinity, and session replication for application fail over support. Standard load sharing techniques are also used to distribute push connections among multiple EPS instances in the cluster, using affinity based on an EPSID instead of a SESSIONID. Enterprise Push Servers track and ensure the delivery of updates to clients and communicate that information amongst themselves, via JMS, so that any EPS node is capable of responding to any client. When a node in the cluster goes down, push connections migrate to other viable nodes, and the EPS instances there take over connection management responsibilities. The failure condition is communicated to the client's Ajax Bridge, which reloads the page to synchronize state between the client and server. Beyond the page reload, the user experience is uninterrupted.

These capabilities are yet another industry first for ICEfaces, and are available exclusively in the ICEfaces Enterprise Edition, including support for the following application servers.


Vendor
 Product
 Version
Apache
 Tomcat (w/ Apache ActiveMQ 5.1)
 6.0
JBoss Inc.
 JBoss Application Server
 4.2.x
IBM
 Websphere Application Server
 6.1
Oracle WebLogic Server 10.3.1

So as collaborative applications become the mainstay of your Enterprise, you can rely on ICEfaces and the Enterprise Push Server to deliver highly-scalable and highly-available deployments of mission-critical applications.

Technorati Tags:

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

Responses (0)

Tuesday, 17 March 2009

Ajax Push - ZK versus ICEfaces

The folks at ZK have made a habit out of borrowing from the ICEfaces messaging related to the benefits of server-centric Ajax, and directly comparing their capabilities with ICEfaces using a seriously slanted bias towards ZK. No real surprise there, but how credible are their claims? Recently, they have claimed that ZK supports Ajax Push, so I thought I would take a look under the hood and see how it compares with ICEfaces Ajax Push.

ZK Matrix

By reviewing the documentation I was able to determine that ZK supports Ajax Push using a long polling technique similar to how ICEfaces does it, but I wanted to understand if they have tackled any of the intricacies associated with this mechanism. I started with their simple chat room demo. The first thing I tested was their handling of the push connection(s) when the application is viewed in multiple browser tabs or windows. I fired it up in multiple windows on IE, and as suspected, ZK does no connection sharing between the 2 windows, so you end up having contention for the availably browser connections (maximum of 2 for IE). As the screen capture below illustrates, the right hand window is attempting to send a message, but is unable to process the entry due to lack of a connection. It just sits there spinning the processing indicator.

ZK Chat Failure

With ICEfaces, the Ajax Bridge handles connection sharing between multiple views onto the same application, so it will never exceed 2 connections, regardless of how many views are open. We can extrapolate from this that the ZK mechanism will not work in portal environments either, as each portlet requires its own push connection.

Next I wanted to understand if ZK had addressed the long-lived connection stability problem by adding some kind of keep alive or heartbeating strategy. I used Wireshark to look at the traffic patterns in the chat demo to determine if any type of heartbeating was running while the application sat idle. While I was not able to detect any type of heartbeating mechanism, I did notice some very strange behavior.

If you leave the application sitting idle for a few minutes, I noticed some sort of condition where a tight loop of failed requests occurs and continues indefinitely. The image below shows a snippet of these messages.

Wireshark

While the client is in this state, it will not receive chat messages from other clients, as illustrated in the screen shot below where you can see it has received only 1 of the 2 chat messages sent.

ZK Chat Failure

The bottom line here is that the ZK push mechanism is not reliable, and there is no indication to the user that the application has failed.

While this anomaly obscured my ability to look for a heartbeating mechanism, my suspicion is that there is not one. Our experience with ICEfaces, however, showed that without one you cannot guarantee a reliable long-lived push connection. Again, ICEfaces has addressed this with a configurable heartbeating mechanism that maintains the health of the connection, and can also determine if the connection has failed. The ICEfaces connection status component keeps the user informed about the health of the connection, and provides for a client-side redirect in the case of a persistent connection problem.

Next I wanted to understand if ZK had addressed any of the scalability issues associated with long polling. We examined the source code to see if any Asynchronous Request Processing (ARP) mechanism was being used to mitigate thread exhaustion in the application server. While Tomcat, Glassfish, and Jetty all provide ARP mechanisms, ZK does not integrate with any of them and does not appear to provide its own, so the ZK solution will not scale. With ICEfaces we have painstakingly addressed the scalability issues with long polling, and provide native ARP integration across application server environments.

With all these serious deficiencies uncovered, it hardly seemed worth continuing, but I wanted to examine the programing model as the final part of my analysis. Both approaches use server-side Java APIs to expose push capabilities. ZK provides a minimalistic API that allows you to configure the desktop for push, and then request a render to that desktop from some triggering thread. It does nothing to coordinate render requests between multiple sources, and it provides no client grouping mechanism to organize what clients get what types of updates. The developer is left to do all this work, but it can become very complex problem without further support from the framework.

With ICEfaces the Render Hub manages all the intricacies associated with processing of updates from multiple sources, coalescing of render requests, and synchronization required to efficiently and reliably control the push mechanism. Additionally, ICEfaces provides RenderGroup APIs that manage groups of clients that receive specific types of updates.

So while ZK claims Ajax Push capabilities, it is pretty clear that ICEfaces offers a far more mature, stable, scalable solution. In summary here is my comparison matrix for Ajax Push - ICEfaces versus ZK:

Ajax Push Comparison Matrix

For reliable, scalable Ajax Push suitable for enterprise-grade deployments there is one credible choice here and that is ICEfaces. Makes you wonder about the credibility of the rest of their claims, doesn't it?

Technorati Tags:

Posted by steve.maryka at 6:55 PM in Entries by Steve Maryka

Responses (0)

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 (1)

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)

Friday, 16 May 2008

Building Collaborative CRUD Applications With ICEfaces and NetBeans

CRUD-style applications remain the mainstay of enterprise application development, but more and more, application developers are looking to add Rich Internet Application (RIA) capabilities into their development process. ICEfaces provides a comprehensive development framework for building RIAs using pure Java techniques based on JavaServer Faces (JSF), but beyond RIA features ICEfaces can truly revolutionize web applications by facilitating real time collaboration using Ajax Push. The latest ICEfaces 1.7 release includes complete integration with NetBeans 6.0.1 making it easy to build collaborative RIA-style applications, and Glassfish combined with the Asynchronous Request Processing (ARP) features of Grizzly provides the scalable deployment infrastructure required for push-style web applications. Note: NetBeans 6.1 integration is underway and will be available soon...

That is the intro to an article that was recently published at netbeans.org. You can read the full article here. You can find the code for the example at our tutorial page under the IDE Tutorials. More on this subject when the NetBeans 6.1 integrations is complete.

Technorati Tags:

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

Responses (0)

Thursday, 10 April 2008

Ajax Push Comes of Age

Ajax Push has always been an integral capability of the ICEfaces framework, but for the longest time it was not a primary consideration of the average technology evaluator. We always found this surprising, because the impact that push can have on a web application is far more profound than Ajax's primary claim to fame - eliminating the full page refresh. In recent months, however, we have seen a marked change in demand for push technology within the ICEfaces community, and we are now involved with a large number of projects where Ajax Push is front and center on the requirements list. So when people are evaluating their options for achieving web-based push, what makes them decide on ICEfaces?

Simply put - ICEfaces provides the most comprehensive open source solution in the industry for lightweight (plugin-free), push for web applications. Now, I will back up that statement with the supporting facts.

To begin with, while there are hundreds of open source Ajax libraries out there, only a small handful offer push capabilities - namely Dojo/Cometd, DWR/Reverse Ajax, and ICEfaces/Ajax Push. All three mechanisms are based on the same fundamental concept of HTTP protocol inversion - holding an open request from the browser, and responding to that request when something is available to be pushed. Normal and inverted HTTP connections are illustrated in the figure below.

Normal HTTP Connection

So if all push mechanisms are based on this low-level protocol inversion, then how can they be fundamentally different from the developer's perspective? With ICEfaces we have strived to provide a natural extension to the JSF programming model in support of push style application development, and have sheltered the developer from the low-level mechanics for Ajax-based push. ICEfaces provides an application-level managed bean, the RenderHub, that orchestrates push events within the JSF lifecycle. Basically, you define groups of client sessions that need to receive the same push events, and register those render groups with the hub. Some trigger point in application logic can then request a render on a given render group, and the hub will make it all happen. The hub is responsible for executing the render phase for each session in the group, coalescing requests and maximizing throughput with multiple parallel render threads. Furthermore, the RenderHub architecture supports clustered deployments. This basic push architecture is illustrated below.

ICEfaces Push Architecture

From the developer's perspective, it is a clean, natural mechanism for implementing push logic using pure Java programming techniques. What is less obvious (and rightly so) are some of the intricacies that the underlying push mechanism handles. The first relates to the browser and connection limits for the same URL. One connection from the browser is required for the push channel, and a second is required to handle user initiated requests, so an application requires 2 connections, which happens to be the maximum allowable in Internet Explorer. The connection usage for a single view onto the application is illustrated in the leftmost schematic in the diagram below.

Now if you attempt to open multiple views onto the same web application you will not have sufficient connections to support it, as each view needs a connection to support its push channel. With ICEfaces, the push mechanism in the Ajax Bridge provides connection sharing that allows multiple views to share a single connection for push updates. It is based on shared cookies where a single view marshals updates for all views, and if the controlling view is closed, another view takes over. The connection sharing for multiple views support is illustrated in the center schematic in the diagram below.

The connection problem is amplified in a portal deployment where you might have multiple portlets from different web applications looking to share the same push connection. In this case, not only do you need connection sharing at the browser, but also at the server. And because the server side connection management needs to communicate with multiple web applications you need some IPC mechanism to support it. With ICEfaces we have adapted the Asynchronous HTTP Server to handle connection management for portlets. The portal deployment support is illustrated in the rightmost schematic in the diagram below.

Normal HTTP Connection

Now if we turn our attention fully to the server-side connection issues related to push we see scalability concerns with multiple open connections at the Servlet level. Each connection requires a dedicated threat to handle it, so thread exhaustion can occur quickly within the application server. Efforts to address the asynchronous communication path within application serves has begun, and will ultimately be standardized under JSR 315. To date we have seen independent solutions emerge for Tomcat 6, Jetty 6, and most recently Glassfish/Grizzly.

 App Servers

All of these application servers support scalable asynchronous communication, and ICEfaces is integrated to work will all of them. Additionally, ICEfaces includes the Asynchronous Http Server, that can be deployed along side any application server and provides scalable handling of the push requests.

Because ICEfaces handles all of the connection related intricacies at the framework level, the developer is free to focus on application development, and to that end, has a straightforward Java API to work with. Without question, ICEfaces is the only solution in the market that provides such a comprehensive feature set and an easy to use programming model. The industry is definitely catching on to the revolutionary value of push, and when enterprises decide they need push, they are flocking to ICEfaces. Ajax Push has definitely come of age in ICEfaces.

Technorati Tags:

Posted by steve.maryka at 9:55 AM in Entries by Steve Maryka

Responses (0)

Thursday, 18 October 2007

ICEfaces And Mobile Ajax

We have been pretty involved with exploring the applicability of ICEfaces in the Mobile Ajax space recently, so wanted to keep everyone in the loop. As it turns out, given our existing support for the mobile Opera and Safari browsers we have a pretty good story around mobile ICEfaces applications today. In fact, we have a customer, C3 Solutions, that has already developed a mobile enterprise system based on ICEfaces. Ted also blogged here about ICEfaces on the iPhone recently, illustrating a number of our demo applications running.

Key to ICEfaces suitability for Mobile Ajax applications is the server-centric nature of the framework. To begin with, the application runs as a pure JSF application, so the server does all the heavy lifting, utilizing only the lightweight Ajax bridge to facilitate the Ajax interactions. Regardless of application complexity, with ICEfaces, the client side of the deployment is a fixed, lightweight piece of JavaScript that is well-suited to resource-constrained mobile devices, provided they support a modern mobile browser.

We also see Ajax Push as a key feature for mobile applications, as it makes it feasible to updated the client in real time without the user needing to interact with the device. Despite improvements in interaction mechanisms you find in devices like the iPhone, they remain awkward to interact with, so reducing the need for interaction is critical to developing effective mobile applications.

I recently did a talk on ICEfaces and Mobile Ajax at AjaxWorld and demonstrated a couple of mobile ICEfaces applications at the show. We went to the painstaking effort to record these demos and they are now available for your viewing pleasure here. You will see the prominence of Ajax Push in both the demos, so make sure you have a look. If you are interested in viewing the slide deck that was presented, you can grab it here. I will also be giving at talk at WEB Builder 2.0 on the same subject in Vegas on Dec 3, so if you are planning on attending you can track me down there.

While the demos are wireless mobile demos, the process of capturing them on video was far from wireless as the photo below illustrates.

Wireless Demo??

Right after AjaxWorld, the OpenAjax Alliance and W3C cosponsored a workshop on Mobile Ajax, and I was lucky enough to be one of the attendees. There was a vast cross-section of the industry represented there and a wide range of discussion topics. While it was a tremendously interesting day, it is unlikely that anything concrete will come from this gathering in the near term. I think that once again Moore's Law will have a bigger impact on penetration of Ajax technologies into the mobile space than standards initiatives ever will. But why wait when you can deliver in the mobile space today with ICEfaces?

I will keep you posted on new developments around ICEfaces and Mobile Ajax as they arise.

Steve

Technorati Tags:

Posted by steve.maryka at 6:57 PM in Entries by Steve Maryka

Responses (0)

Friday, 12 October 2007

Welcome to the ICEfaces Water Cooler

Welcome everyone. You are looking at the new blogging site for the ICEfaces team. As you can see, we are just getting up and going. I am Steve Maryka, CTO at ICEsoft, and will be spearheading our external technical communications initiative, for which this blog site will become one of our primary vehicles.

Until now, Ted Goddard, senior architect for ICEfaces, has been our primary blogger. You may already be following his story here . Ted will be mirroring his posts to both his existing blog and this one, so you can follow his Ajax Adventure at either.

I will start with a few posts related to the history of ICEfaces, our partnering efforts in the community, and our progress in the mobile space. Most importantly, we want to make sure the information we provide is interesting, relevant and useful to the ICEfaces community, so please let us know what you want to hear about.

As we build momentum, I will get other members of the team involved. Over the last 4 years of R&D we have developed such a tremendous breadth and depth of knowledge that no single mind (except maybe Ted's) can contain it all, so as we delve in to more complex subjects, we will make sure the subject matter experts are involved.

Once again, welcome. I trust that you will find the new ICEfaces Water Cooler useful, and I hope to hear from you along the way so that we can consistently present the kind of information that is pertinent to you. Stay tuned for more from myself and the ICEfaces team.

Steve

Posted by steve.maryka at 8:59 AM in Entries by Steve Maryka

Responses (1)