Case Study: Product Selection
- Product selection
Building CoolSelector with Aria
CoolSelector is a web-based tool for designing cold-room configurations. It was designed and built for Danfoss Refrigeration and Air Conditioning Controls group to allow their consultants, wholesalers and installers to select and configure all the components and controls needed to meet the cold-room requirements of their customers.
Danfoss A/S, the leading supplier of Air Conditioning and Refrigeration components and controls, asked Formaria to develop a configuration tool to allow them to design cold-rooms for their customers. Cold-rooms are typically used by supermarkets and manufacturing/processing plants to ensure that produce is held at a low enough temperature throughout its storage/processing. They needed a system that would allow them to select and configure all of the components and controls needed to build the cold-rooms. The design tool would be used by consultants, wholesalers and installers who would access Danfoss's website to order the cold-room kit on-line.
Danfoss had a clear picture of their client-side requirements, including an interactive graphical user interface to allow quick and simple selection of components.
Danfoss requested that this application be developed as ASPs. We used COM/DLLs objects for the core selection engine to handle the complex mathematical calculations involved in the physical modelling aspect of the system.
The system, known as `CoolSelector' was launched to much acclaim at the IKK show in 2002 and has already spawned a number of imitations.
Part of the inspiration for Aria
In developing CoolSelector, we maintained a clean separation between the underlying calculation model and the user interface. This separation was to allow the system to change and expand during its lifetime and to support a variety of client interfaces including a standalone, off-line version.
CoolSelector and its underlying data model provided much of the inspiration for Aria
Description of the Existing system
On the server-side, a set of ASPs provide integration with back-end corporate functions, such as user identification, localization and order processing. The ASPs employ a number of COM objects for input validation, database access, file access and functions such as unit conversion (metres to inches etc...).
Core calculations are implemented in C++ and rely on a SQL Server database and several further COM objects for XML access.
The core design works well and has allowed several extensions and changes to the system to be implemented. However, during development and since deployment we identified several areas with room for improvement.
Room for improvement
There are two main areas where improvements could be made to CoolSelector: firstly the coding, and secondly the deployment.
To some extent both of these problems relate to the use of COM objects and the types of interfaces they expose. From a coding perspective, the level of access to XML and databases is too low, resulting in the use of more "plumbing" code than is desirable. From a deployment perspective the use of COM objects means having to stop and start servers and well known DLL-compatibility issues.
Given all the above, CoolSelector Mark 1 neared the limits of what can be accomplished with an HTML-based front end.
The Aria experience
The Aria version of CoolSelector started as an experiment to see how Aria performed in the development of a rich/complex client application.
Encouraged by initial successes, we began to add new data-access features to CoolSelector using the Aria data model. Aria's data binding facilities immediately meant that a whole layer of data manipulation disappeared: instead of parsing responses and updating controls, Aria allows controls to be bound to data with a simple declaration. For CoolSelector, this meant that we could update all input fields by simply declaring the data bindings. Furthermore this binding removed another layer of custom coding used to coordinate data between pages. These advantages alone provide a persuasive argument for using Aria.
Next, we decided to try out some core calculations in the Aria version, and the results were astounding. Again the Aria approach paid dividends as we were able to remove large amounts of plumbing code (for XML, Database access and marshalling of server requests and responses). However, the performance impact was the biggest surprise!
We had expected that using Java in place of C++ for the intensive calculation operations needed would result in a sluggish system, but in fact, we found that un-optimized selections happened almost instantaneously instead of in the 20-30 seconds we had grown accustomed to!
To an extent, the results achieved are implicit in using a rich client as opposed to a thin (HTML) client. After all, the rich client provides locality of computing, one of the cornerstones of computing performance.
Perhaps the biggest win comes from the simplification of the architecture and code. Aria takes care of most of the plumbing so the application-specific code need only include the explicit business logic required. Isolating this business logic makes for easy coding and maintenance.
The Aria system comprises Java, XML and some SQL, all in all a lot simpler than the client architecture. Gone are the COM objects, simplifying the server deployment dramatically.
The gains do not stop there! Implicit in the Aria architecture is the ability to operate in an occasionally-connected environment, and therefore an off-line/standalone version is a given rather than an additional requirement. Automatic update and synchronization of an off-line version is also implicit. Therefore, a Aria CoolSelector user will see little difference whether they are on- or off-line.
From a corporate standpoint, Aria CoolSelector can still run within IE's JVM. This means that it can appear just as much a part of the corporate website as any other pages. Rebranding can be achieved by editing a single configuration file and a whole gamut of extensibility and customization features are at hand. It is easy to see how Aria as an inherently open architecture could form the basis of an industry platform.
Direct comparison between the Aria and HTML versions of CoolSelector may be inappropriate as some of the code has been replaced by library code and some gains are implicit in creating a rich client application instead of an HTML client. That said, the Aria version of the application represents a 75% reduction in code and approximately a 50% saving in the number of subsystems used.
Selections with Aria occur in 1-2 seconds, compared to 20-30 seconds with HTML/COM on the same machine - a staggering 3000% improvement in performance! In a multi-tier/multi-node server environment, this would translate to almost a complete removal of the work load. From an application-development point of view, the performance gain is significant in that it opens up the possibility of adding features such as simulation and diagnostic capabilities. Significantly, the Aria version of CoolSelector implicitly includes an updatable, standalone client-application as one of the many other functionality gains. Not only does this make CoolSelector accessible to a wider audience but it also makes it feasible to use CoolSelector on a broader range of devices (WebPads/Tablets/PDAs) some of which may be used by field workers such as service technicians.
CoolSelector has many advanced features. First of all it simplifies the task of choosing a coldroom system for a specific market niche. In the screenshot below you can see the main configuration options on the left hand side. A refrigeration engineer would be more than familiar with these settings and indeed some of these settings such as the voltages would be regional specific.
CoolSelector will remember the user preferences so that once the sytem has been used there is probably no need to set these options very often. Selecting a system then becomes a matter of choosing the appropriate options and entering some operating conditions.
Remember CoolSelector is built using AWT and with just the components built into Aria..
Notice how the settings page contains a language button. This button pops up a dialog where you can choose the language in which the application is displayed. The localization of CoolSelector uses the very same techniques as described in this manual, so you can see that is possible to translate a complete application using the simple methods we described. Here's the same page in German.
CoolSelector featues an interactive way of setting the load. Either the users can enter the data on the top half of the page in a form or they can setup the load interactively by clicking on various parts of the graphic at the bottom. Rules and validations are applied to both.
The beauty of a rich-client application is its ability to take advantage of local computing power and CoolSelector does this to great effect. Load calculations and selections are instantaneous and this is a vast improvement over web based systems. The ease with which the system can be programmed also lends itself to adding more powerful and compelling user interaction.
CoolSelector can work on-line or off-line. In an on-line mode CoolSelector will check for connectivity and provide extra product information from Danfoss's corporate website.
In the screenshot below some information about a component is being displayed.
The Web button provides a link to the Internet usings the JDIC web browser component.
Ultimately the application is an e-commerce application and we get a list of part numbers ready for ordering.
For off-line users and for project mangement purposes CoolSelector also produces detailed summary information that can be saved for quality control purposes.
The summary information can even be exported and printed. The export features include export to office formats so that the selection can be reported as part of a larger document, for example a design specification or as an offer document to a prospective client.
And for the techies in the business there are even diagrams showing the characteristics of the proposed systems operation: