Tuesday, 11 December 2007
ICEfaces: Solving the Ajax Matrix of Pain for JavaEE
ICEfaces:
Solving the Ajax the Matrix of Pain for JavaEE
One of the underlying objectives we had when we started the ICEfaces open source project was to create the most interoperable enterprise Ajax solution on the market. The matrix of pain that we are discussing here refers to the many configurations that we endeavor to test ICEfaces against.
As of our 1.6.2 release, ICEfaces is supported across nine different application servers, five integrated development environments (IDEs), five different browser platforms and five third party Java EE frameworks and portals. As far as we can tell the interoperability of ICEfaces far exceeds that of any other enterprise Ajax offering on the market today. Such interoperability however has come at a cost.
Supporting all of these platforms results in over 1,100 different permutations and combinations of technologies and tools that ICEfaces must be supported and tested against. Granted some of these combinations are more or less likely to occur in actual practice, but for all practical purposes, our test matrix is quite substantial and growing with every new release.
For every third party technology or tool we integrate with ICEfaces we have to plan on allocating the equivalent of a full or half-time engineer for the life of the integration. Beyond the up front integration efforts, we need to provision support to the user community and forums with respect to the integration and we need to continue that support through any future releases of both ICEfaces and the third party technology or tool. Every time a third party tool or technology releases a new version we have to retest and often re-integrate ICEfaces.
Every time we undertake a new technology or tool integration, the number of possible configurations we need to test ICEfaces against can expand by 2-300 new configurations. In order to accommodate this level of complexity we invest heavily in our own test infrastructure. With every release we are adding hundreds of new test cases to our automatic regression test suites, and new dedicated hardware to duplicate the most commonly deployed combinations of tools and technologies.
A practical consequence of this support cost is that we have to be very prudent and careful whenever we decide to take on the support obligations associated with integrating a new tool or technology. Inherent with each adoption of a new technology or tool is an obligation to provide the ongoing support for it. Inconsistent and intermittent support for previously integrated platforms is detrimental to the community and can easily damage company credibility and impact the adoption of the platform. Users often commit considerable investment in time and energy to learn a particular technology and develop applications around the ecosystem it reportedly supports. Enterprises looking to make this kind of investment must have confidence that the company behind a particular open source solution has the wherewithal, the intent, and the required infrastructure needed to support third party tools and technologies. They need to know that the ecosystem they are investing in is going to be around for a while and continue to grow.
I believe we have achieved our objective of delivering the best and most interoperable enterprise Ajax solution to the market, and remain committed to keeping it that way. Over the upcoming weeks we will be soliciting input from our community with respect to our future 2.0 release of ICEfaces. Of particular interest will be feedback with respect to which tools, applications, and technologies we need to consider for future integrations. I encourage you to let us know your thoughts so that ICEfaces is better positioned to meet the evolving needs of its growing community.
Brian McKinney
Posted by at 12:13 PM in Entries by Brian McKinney