Technological Changes Required to Foster a Community Platform

Posted by Matt Rajkowski on February 25, 2009, 11:10 AM EST

This is the final post in a four (4) part series exploring ConcourseConnect.  The first three parts can be read here: Introducing ConcourseConnect to Team Elements Users, Major Functional Changes to Team Elements in making ConcourseConnect, and ConcourseConnect: Improving Upon the Team Elements Core Modules.

Now for the technical overview...

Team Elements is a web application, based on the Enterprise Edition of the Java Platform, and is designed to be portable and scalable.  Early Team Elements work introduced an MVC framework for separating the visual appearance of the application and the underlying business rules.  The MVC implementation allows for security constraints for all web requests, and over the years various components have been added to share database resources, integrate a rules engine, and perform background scheduling.  Those are all great things for modern web applications.

So what could be better?  Well, it depends on who you ask.  At Concursive, we evaluated many options, but in the end, the need to drastically increase flexibility of the application, without sacrificing simplicity, performance and scalability, won hands down.  We also wanted a better user experience.

So how did we do that?

We chose to use portals and the Java Portlet Specification.  More specifically, we embedded Apache Pluto to create separate portals for landing pages, search results, and application modules.

All of the pages and modules are now constructed using portlets -- this provides for custom page layouts in which portlets can be moved around the page, for modules to be easily expanded with new features and settings, and for external services to be seamlessly integrated.  Standardizing on JSR-168 portlets has proven to be a very flexible improvement to the existing MVC architecture.  Since Java IDEs already have support for JSR-168 portlets, it was a no-brainer to go this route since we want developers to use their portlets in ConcourseConnect.  The portal framework includes caching, AJAX and other optimizations that portlet developers can choose to use.

Using portlets also enabled a new services platform for ConcourseConnect.  Portlets can be remotely deployed or upgraded in a separate portlet server without changing any code in the running ConcourseConnect application or bringing it down at all for true "plug-n-play" development. This is done by using WSRP.  In fact, hundreds of ConcourseConnect systems can simultaneously access the same remote services.  Today there are basic services for weather and ads, and an advanced telephony service which allows users to click a button to make calls.  Concursive is looking for partners and enthusiasts to deploy more.

The ConcourseConnect team also modernized on XHTML and implemented lightweight CSS and web pages.  The HTML has been simplified and restyled so that others can control the look-and-feel completely through CSS and web pages load much quicker.

We also focused on search engine optimization.  The basics are that the pages adapt themselves to the content, page titles are clear, "clean" URLs are used, and the application gracefully degrades when javascript is not available.

True to the original platform, ConcourseConnect is written in Java, leverages over 45 open source licensed libraries, runs on the PostgreSQL database, makes use of high-performing caches and distributed services for scalability, and runs on a load-balanced portal framework.

Leveraging all of these technical improvements forms the basis for growing your own communities.  Please check out ConcourseConnect and if you have any thoughts on improving it or need support for deploying a community, feel free to use this site.