The Server-Side Pad

by Fabien Tiburce, Best practices and personal experiences with enterprise software

Archive for October 2006

Server-Side Charting

with one comment

Businesses have long relied on charts to expose key metrics. Pie and bar charts need no introductions and for this reason, they will continue to be popular in reports and data mining interfaces. Thankfully, including real-time charts in a Java based web application has become easy. JFreeChart and its companion product Cewolf are powerful free and open source libraries for generating real time charts server-side. JFreeChart is the core graphing library while Cewolf is a Java Server Page (JSP) wrapper for it. Together they allow a developer to build and serve complex pie, bar, line, stacked, candlestick, area and scatter plot charts.
The chart library has a built-in cache for optimum performance. Charts can be generated and saved in several formats including .jpg or .png. Building and serving a chart for the web requires two classes. A processor class accepts arguments and specifies what graph to build, its scale, legend and colours. A producer class is a data container containing arbitrary JDBC or object calls.

Written by Compliant IA

October 31, 2006 at 11:09 pm

Use Cases: Too Much or Not Enough?

leave a comment »

Use cases are an effective way of capturing business and functional specifications. In fact, coupled with user interface mock-ups and wireframes, use cases are typically the key constituents of a business and functional specifications document. Use cases often expose dependencies and workflow paths that may not otherwise surface. For all their worth, use cases are time consuming to write. They tend to be bulky and can be repetitive. In fact, we have found there are diminishing returns with producing ever more use cases for a given system. The question is when is not enough and how much is too much? We generally produce detailed use cases around key subsystems such as authentication/authorization and wherever one application interfaces with another (such as when web services are used for example). In such critical or complex areas, there is value in investing and writing detailed use cases. Elsewhere, we have found that it is often more effective to focus on written documentation and mock-ups.

Written by Compliant IA

October 27, 2006 at 9:20 pm

Life in the 99th Percentile

leave a comment »

In everyday life, 99% of something is often just as good as the whole thing. 99% of a hot dog will fill you up. Not so in systems. An application with 99% availability means it will be unavailable on average 1% of the time or 87 hours a year. Downtime is typically not evenly distributed. In fact is is more likely to occur when your systems are stressed, during peak time. For this reason, availability is generally stated in degrees of the 99th percentile, typically from 99.99% to 99.999%. A business should consider how many 9’s it needs and how many it can afford. How many 9’s are needed is usually dictated by the cost and the effect of down time on the business. Will down-time cause damage deemed a) catastrophic and irreparable (eg: loss of life for a medical application), significant (eg: loss of income for an e-commerce site) or merely inconvenient (loss of productivity and frustrated customers for a call center)? While no business wants downtime, 99.999% availability is exponentially more expensive than 99.99% availability. Additional uptime requires expensive investments in software, hardware and networking infrastructure, including load balancers and session replicators. Lastly, any site or application that claims 100% uptime should be treated with extreme caution. No system is perfect. No operator or system administrator is perfect. Even with hot deployments enabled, you sometimes need software updates and planned maintenance windows. A business is often better off expecting “only” 99.999% availability and having contingency measures in place than expecting, paying for and never getting to the ellusive 100% mark.

Written by Compliant IA

October 26, 2006 at 10:44 pm

Technology Stack

leave a comment »

The first decision an architect must make when starting a new project is selecting a technology stack. A technology stack is a combination of programs and core-technologies that work together to create an application platform, in this case a Web Application Platform. In most organizations, this is often driven by legacy systems, enterprise standards as well as integration and support issues. For this reason, a developer may not have complete control over the stack.

The objectives of a technology stack are:

  1. Use modular, well documented and widely used enterprise grade technologies
  2. Reuse best practices already in use or under review in client’s specific industry
  3. Use technologies with a proven track record for performance and scalability
  4. Use open source wherever possible

Typical go-forward technology stack for Betterdot projects:




Relational Database


Greenplum Bizgres

Open source relational database engine. Supports relational integrity, views and stored procedures.

Greenplum is massively parallel architecture built around PostgreSQL

Application Server

Apache Tomcat

Reference servlet container for server-side Java applications

Operating System

Red Hat Linux

Linux distribution

Programming Language


Widely used programming language for large-scale server-side applications. Not open source but free. Governed by a community review process.

Search Engine


Java based search engine

MVC Framework


Java based MVC framework for building web applications

Object Relational Persistence


Facilitates the interaction of the object model with the data model

Application Configuration


Automated configuration and wiring of application objects

Template Engine


Java based template engine. Used for user notifications.

Integrated Development Environment


Widely used open source integrated development environments. Many plug-ins available.

Deployment and Build


Java and XML based build tool for deployment automation

Written by Compliant IA

October 26, 2006 at 4:10 pm

Why I love Lucene

leave a comment »

What is both more powerful and faster than a database search? Well a text search of course. Content-rich web properties (and search engines) rely on text searching tool to index and search content.
I find the most effective way to work with a search tool like Lucene is to engineer XML representations of the content you need to index to the file system. This is typically done using cron jobs or everytime the content “bean” is modified. Then Lucene is used to index and search specific nodes in the XML document. Lucene is document agnostic. It can index any type of document, as long as it can parse it (parsers are easy to implement). Lucene supports boolean searches, proximity, stemming, stop word processing and faceted searches. Lucene is widely supported and actively developed. Two thumbs up!

Built on top of Lucene, Solr has all its featurers plus a web based interface, the ability to load balance using existing web technologies and index replication.

Written by Compliant IA

October 26, 2006 at 4:00 pm

Syndicating Content Using Widgets

leave a comment »

Content widgets are self-contained bits of HTML that consist of HTML, Javascript and AJAX code required to fetch and display content from a remote site. These widgets typically have a fixed footprint and are implemented by including the html code for the widget in the html of the host page. This is simply a copy and paste operation, no further setup or integration are required.

For this example, we will use the Toronto Star’s sample code for including the Star’s headlines into a personal website or blog. The sample code for this example is available at:

Copying and pasting this nugget of HTML into a web page, displays a self-contained widget, 125 pixels wide that displays the Toronto Star headlines. The HTML relies on a remote script,, located on the Toronto Star web server.

Written by Compliant IA

October 26, 2006 at 3:56 pm

AJAX Libraries

leave a comment »

AJAX is in many respects a technology that is still emerging and maturing. Yet it is already widely adopted and a key component of the web2 architecture. Unfortunately, it is not a standard as much as a set of practices and behaviours supported by modern browsers. While useful to end users, AJAX can be time consuming to implement. Using an AJAX library is recommended. Most libraries consist of of a series of customizable widgets. Here is a list of AJAX libraries we find useful:

AJAX JSP Tag Library:
Google Web Toolkit:

Written by Compliant IA

October 26, 2006 at 3:41 pm