The Server-Side Pad

The Future is Cloudy

2008-04-16T09:13:00.000-04:00

According to Google and Amazon, cloud computing is the next killer app of the web landscape. Could computing refers to running web applications in a vendor's computing cloud, free from the worries and expenses of maintaining and scaling your own servers and applications. Sounds amazing? It is. Most applications do not fully take advantage of their available hardware. Setting up and maintaining hardware and services is time consuming and expensive. Lastly, scaling applications is non-trivial and often requires the application to be architected from the ground up according to scalability tenets. Cloud computing can potentially make all these headaches disappear. But assuming that all applications will end up in a cloud is, as of today, unrealistic. Cloud computing restricts developers to working in a virtual sandbox. Accessing file system files is not permitted. Background threads are not permitted. The application works within the strict confines of the cloud's API. While this is probably fine for most simple web apps, it simply is too restrictive for most highly customized, full featured web applications. These restrictions will likely ease with time. When they do, cloud computing may very well become the prominent model for application development and hosting. Until then, the future is indeed cloudy.

Drag & Drop Using the Yahoo UI Library

2008-04-02T16:06:00.003-04:00

Drag and drop is not only ubiquitous in "fat client" (desktop/PC based) applications, it is also widely understood by end users and often expected. Recent advances and a number of capable third-party utilities have brought this capability within reach of most web applications. One such utility is the Drag & Drop from Yahoo! UI Library. It allows developers to declare draggable objects and destinations. The API provides javascript call-back event-handlers to implement presentational and business behaviours (such as making an Ajax call when a hypothetical draggable object schedulingEvent is dragged and dropped into a calendarDayCell object).

The following code hosted on the Betterdot website demonstrates how easy it is to implement Drag & Drop on a page using the Yahoo UI Library.

Client Side Charting

2008-04-02T12:14:00.000-04:00

Move over server-side charting, there is a new sheriff in town. His name is flash-based client-side charting. While a server-side charting library like Cewolf/JfreeChart produce charts as images server-side, a new (not so new but gaining ground) breed of charting utilities leverages the superior dynamic capabilities of Flash to build charts on the client side. The chart is typically populated by an XML or JSON payload, either on the page or sourced from an Ajax call. Users love the polished look and dynamic behaviours of these charts. Developers love the ease of implementation and natural separation of the model (data layer) and the view (presentation). FusionCharts is an excellent charting library that offers many types of common and complex charts. It is a commercial product however. Yahoo has one such product too although the product is currently listed as experimental (so deploy at your own risk...).
Client side charting offers clear advantages over server-side charting in terms of reduced complexity, shortened development cycles and encapsulation. Provided serving a flash widget is permissible in the client's specific environment, client side charting is a very compelling option and one that should gain even more ground in the months and years ahead.

Business Rule Engine

2008-04-01T16:36:00.002-04:00

Much of the development in server-side programming in recent years has focused on declarative, loosely coupled components. This essentially amounts to building components (aka beans) and using XML descriptors to assemble business processes around these components. There are definite advantages to doing this, shortened development cycles and more flexibility around change management being two of the most compelling. The flag bearer of this movement is probably the wonderful Spring framework. While Spring is multi-talented, general purpose framework, there is another core technology most businesses need: a Business Rule Engine. A Business Rule Management System (BRMS), as these products are formally known, allows developers to declare and implement business rules, outside the realm of compiled code. The very capable, full-featured, open-source (and unfortunately named...) Drools from JBoss labs, is an BRMS tool that allows rules to be described using business semantics close to natural language. Since business rules is the portion of an application most likely to change over time, decoupling the rules from the core product makes sense. A BRMS is particularly well suited to data transformation, data validation and the implementation of any rule-based, conditional business process.

GZIP Compression for Improved Page Loads

2007-11-15T11:56:00.000-05:00

All modern browsers support GZIP compression (by sending a header to the server, Accept-Encoding: gzip). Enabling gzip server-side for HTML and XML significantly reduces the footprint of the server response which in turns improves the page load-time (latency). It also saves bandwidth costs. The cycles required to zip the response server-side and unzip it client side, are more than offset by the savings in bytes transmitted. In Tomcat 5.x, this is simply a matter of declaring gzip compression for the connector node in server.xml.

Compress your Javascript and CSS files using Yahoo's YUI Compressor

2007-11-15T11:24:00.000-05:00

The YUI Compressor from the Yahoo UI Library is an effective and easy to use compressor for js and css files. By eliminating white spaces and shortening local variables, I have found the tool compresses files by as much as 50%. This is particularly compelling for large web properties. Smaller downloads translate into bandwidth savings and lower page latency. Translation: costs less and makes users happy! The compressor comes as an executable jar file whose commands are easily included in an Ant deployment script. This seems preferable anyways since while the compressed files have smaller footprints, they are not particularly legible. Compressing at deployment time allows developers to continue working with a original, human-readable files.

JSON

2007-11-14T15:07:00.000-05:00

JSON (JavaScript Object Notation) is a fast-rising data interchange format. As such it is an alternative to the XML format for data interchange. Unlike XML, JSON is a subset of the Javascript language. While JSON has a smaller footprint than XML, its most compelling advantage is that JSON sets are Javascript arrays. This is particularly advantageous to Ajax-rich pages where the page controller is typically a Javascript event. A basic but functional implementation of JSON in Java is available on the json.org site.

RSS/Atom Publishing Made Easy

2007-11-14T14:55:00.000-05:00

Rome is an easy to use and configure Java library for creating RSS and Atom feeds. As with all such libraries, Rome lets developers write feeds using a simple object model. Rome is responsible for producing the feed compliant XML. The product supports several flavours of RSS and Atom.
While Rome works well as a servlet, large web properties are probably better off producing feeds as a scheduled batch or background thread and saving them to the local file system for a web server to handle. This allows the application server to focus on what it does best (serve dynamic requests) while delegating the serving of static content to web servers.

It's Good to Have Principles!

2007-08-16T23:34:00.000-04:00

In software development as in life, it's good to have principles. Design principles are essential to discuss and document in the early days of a software development project. Principles support and protect the vision of the architecture; that which will allow it to be stable, flexible and/or scaleable. Without them (and this is particularly true in larger teams, new teams and teams with high turnover), it is easy to make day to day decisions that will weaken the application, introduce bugs or won't scale. Design principles are guardian angels for software. Discuss them, review them often and go back to them when alternate implementations are being discussed.

While I have long relied on design principles for application and database development, the rise of Ajax and Javascript libraries places a bigger emphasis on design principles for the front-end. Conflicts in Javascript libraries and styles are more frequent with Javascript and scriplet-friendly Web 2 applications. And with Ajax bridging the gap between front-end and back-end technologies (and in the process bridging the gap between front-end and back-end developers), establishing design principles for the front-end is a worthwhile exercise for a development team as a whole.

Choosing an AJAX library

2007-08-08T09:51:00.000-04:00

The ubiquitous use of Ajax on Web 2.0 sites such as Google, Yahoo and Facebook has propelled Ajax into the spotlight. And for good reasons; used wisely, AJAX often improves the user experience by making it easier to find relevant and contextual information without leaving the page. The problem is that as of today, implementing AJAX is a mixed bag. Some features are trivial to implement (eg: auto-complete), others more complex and time consuming. It helps having a good AJAX library (or two) as a starting point. Just like designers and developers often use higher level tools to speed up development, AJAX libraries are a speedy alternative to coding AJAX by hand. The choice of a library hinges on a number of factors such as the template technology used (JSP, velocity templates, etc...), the type and number of AJAX functions and the degree of customization required. So unfortunately one size does not fit all. Also note that this is a relatively new market still. As the market mature so will the tools.

Today, one of the most useful AJAX tags library I have found for JSP development is Ajax Tags which is available as a Source Forge project.

Google and YouTube Scalability

2007-08-08T09:41:00.000-04:00

Google's recent conference on scalability held in Seattle in June 2007 offered an interesting insight into how two of the world's largest properties have and continue to scale their systems.

Google scalability presentation

YouTube scalability presentation

Scalability Principles

2007-08-08T09:18:00.000-04:00

It often comes as a surprise to business professionals but building scalable systems is a deliberate, purposeful and complex undertaking. Architected correctly, following certain design principles, a system will scale (handle a high level of concurrency and throughput), albeit with some effort. On the other hand, systems which were not designed to scale often end up being expensive and unreliable when stressed. So unless you are building a small departmental application, it's often best to sow the seed of scalability right into the core technologies, the base architecture of your application.

So how do you scale?

1. Identify a few design principles and guidelines before you start architecting. Google made the assumption that no single piece of the application could be deemed 100% reliable. What you think is bullet-proof will eventually fail. Knowing this forces the architect to handle failures gracefully and build fall-back systems. This principles applies to software, hardware and network components.

2. Avoid single points of failures. Application serves are load-balanced. Load balancers and switches are paired. Databases are setup using replication/pooling and/or partioning. Should any given machine fail, the traffic is automatically rerouted to other components.

3. Build your system as a set of discreet components. Each components hides its complexity (and error handling!) to the rest of the system. A component can run on all or some machines. For example, background jobs can be handled by a thread pool server(s) instead of bogging down an application server used to serve user requests. Please note that using property and descriptor files, a single application can be instantiated in a number of ways declaratively so the developer does not have to build several applications.

4. Automate your unit and load testing.

5. Build introspection capabilities into your production system. The worst thing about a bug is not being able to understand it. Threshold based introspection capabilities must be built into systems so a developer can understand what is happening, who is using the system, what resources are being used, etc...

SOAP - Apache Axis - Part 2

2006-11-14T15:49:00.000-05:00

In a previous post, we discussed the ease of implementation of jws-based web services. In this post, I want to look at the flip side of this argument: deploying wsdd-based web services is more flexible and powerful yet only marginally more complex.

The file server-config.wsdd located in the application's WEB-INF directory allows the developer to expose a class as a web service. Just like jws-based services, an existing class can easily be retrofitted and exposed as a web service. Unlike jws-based services, the class is compiled at design time (not run time) and can be packaged. But the superiority of this methodology mostly lies in the use of "handler" classes which can be assigned to the request or response flow of the web service. A handler is a class that does pre-processing or post-processing on the web service. A handler might be used to log the service's activity of maintain state for example.

While a wsdd-based web service is marginally more complex than a jws-based web service, it allows behaviours to be easily added declaratively to the service definition. Developers are encouraged to use wsdd-based web services for any critical or sensitive operation.

Java is dead. Long live Java!

2006-11-13T08:59:00.000-05:00

Sun Microsystems announced today that it would release Java as open-source under a GPL license. This allows developers to view, fix and expand the Java platform and do so freely as long as the changes are published. This news injects new life into an already thriving platform (see installation base figures below).
In fact considering how successful Java already is, where can it go that it hasn't gone before? I looked into the Betterdot crystal ball, ;), and this is what I saw... Expect a transition from "Java Anywhere" to "Java Everywhere". Expect Java in just about all embedded devices from kiosks to mobile devices. Expect most enterprise software to be written in Java or come with a Java API (most likely complemented by a web service back end). The Java ecosystems of free, high-quality enterprise grade applications will continue to grow over the next 24 months with the help of large commercial software vendors like IBM and Sun backing up open source software. Open source is a) good software and b) big business. For companies who have a vested investment in the platform this a very good news and an assurance of continued returns on the Java investment. For others considering core technologies for upcoming development, this is a compelling argument to consider the Java platform.

As a end note, let's look at the installation base for Java today (figures obtained from Sun Microsystems).

Java is currently installed on:

800 million desktops
1.2 billion phones
1.65 billion smart cards
5 million downloads of Java technology for the enterprise

SOAP - Apache Axis - Part 1

2006-11-08T15:57:00.000-05:00

Axis is Apache's implementation of SOAP, an XML based object invocation protocol. While SOAP services have been around for some time, what strikes me is how easy and fast it has become to implement a web service using Axis. There are two methods of creating a web service in Axis. The first and by far the fastest is to rename the java "class" containing the business logic you wish to expose from .java to .jws and place this file in the root of the war file. This .jws will be compiled to a .class on first invocation much like .jsp pages are compiled into servlets. Invoking the .jws (programmatic post or even browser get), effectively routes the SOAP request to the SOAP servlet and runs the method specified as a parameter (?method=). That's it! This is a fast and effective way of exposing a regular class and its methods as a web service. This also allows regular classes to be easily retrofitted/exposed as web services with very little effort. This approach does not yet permit the use of packages although directories are allowed. The second method involves writing a wsdl descriptor for the method which is more involved, more time consuming but arguably more flexible. However I find the ease and speed of the first approach too compelling to pass. In fact, I can't think of a faster way of exposing business logic as a web service or remote procedure call. Why go with SOAP when you may have an in-house XML over HTTP framework already in place? Any custom solution requires routing and handling code which SOAP elegantly and transparently handles. SOAP and Apache Axis allow the developer to spend less time on the routing and handling of requests and more time focusing on the business logic.

Google Analytics

2006-11-02T09:23:00.000-05:00

A web analytics tool helps you understand how people found your site and how they used it. Of course, web analytics and performance software is old news. Products like WebTrends have been around a long time; they are capable and mature analytical tools. In this post, I want to discuss a relatively new offering from Google called Google Web Analytics. While it is full-featured, web based and free, it is the underlying technology I find interesting. Just like Google Ad Sense and syndication widgets everywhere, Google Analytics works by including the reference to a remote script in the source code of each page being tracked. A remove JavaScript function is effectively run every time the page is fetched which fetches local variables and headers (including an account number which is provided at registration time).

Remote scripting is becoming ubiquitous in the Web2 landscape and offers many possibilities for two way data exchange.

Server-Side Charting

2006-10-31T18:09:00.000-05:00

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.

Use Cases: Too Much or Not Enough?

2006-10-27T17:20:00.000-04:00

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.

Life in the 99th Percentile

2006-10-26T18:44:00.000-04:00

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.

Technology Stack

2006-10-26T12:10:00.000-04:00

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:

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

Typical go-forward technology stack for Betterdot projects:

Type	Name	Description
Relational Database	PostgreSQL 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	Java	Widely used programming language for large-scale server-side applications. Not open source but free. Governed by a community review process.
Search Engine	Lucene	Java based search engine
MVC Framework	Struts	Java based MVC framework for building web applications
Object Relational Persistence	Hibernate	Facilitates the interaction of the object model with the data model
Application Configuration	Spring	Automated configuration and wiring of application objects
Template Engine	Velocity	Java based template engine. Used for user notifications.
Integrated Development Environment	Eclipse	Widely used open source integrated development environments. Many plug-ins available.
Deployment and Build	ANT	Java and XML based build tool for deployment automation

Why I love Lucene

2006-10-26T12:00:00.000-04:00

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.

Syndicating Content Using Widgets

2006-10-26T11:56:00.000-04:00

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: http://www.thestar.com/static/headlines/grabheadlines.html

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, http://www.thestar.com/images/xml/rss/news.js, located on the Toronto Star web server.

AJAX Libraries

2006-10-26T11:41:00.000-04:00

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: http://ajaxtags.sourceforge.net/
Google Web Toolkit: http://code.google.com/webtoolkit/documentation/examples/kitchensink/
ZK: http://www.potix.com/zkdemo/userguide/

Looking for a scalable database engine? Have a plum!

2006-10-26T11:23:00.000-04:00

The more I read about Greenplum Bizgress, the more I like it. Bizgress is a cluster architecture for the open source and highly capable PostgreSQL relational database. Each table is “distributed” across segments. Greenplum promises ultra-fast performance on 100+ terabytes databases. A clustered , "massively parallel" architecture seems to support this claim. The base product, Bizgres (http://www.greenplum.com/products/bizgres.php), is said to support 10-300 gigabytes databases. Bizgress is open source and free. For 300 gigabytes to 100+ terabytes, you'll need Bizgres Plus (http://www.greenplum.com/products/bizgresMpp.php). It’s still open source but not free.

Runs on many flavours of Unix/Linux but not Windows (not that you would…)