Extending A Legacy System to the Web
An ISV sells ordering and billing systems written in C/C++ and VB6. Each system is consisted of two components and all share a relational database containing Tables, Views and Stored Procedures.
A Legacy System
The server component does the data processing, accepting commands from the clients. The commands are stored inside a predefined directory in the form of ASCII-encoded text files. The legacy* command processor repeatedly checks for new text file availability. If a text file is available, it will be processed. This is a continuous process. The only way to update the database is to create and send a command which will be picked up and handled sequentially by the command processor. When a command is handled successfully, the system updates the shared database.
The client component connects to the shared database (accessed in a read-only fashion) to display data on screen and to send pre-defined commands. The client is either a VB6 GUI or a handheld radio device similar to this one.
Nowdays, in order to reach the mobile market, it is quite difficult (and expensive) to maintain and expand the above client as-is. However, since each of the components has no knowledge of the other separate component, the client can be easily replaced.
Moving to HTTP services
The new HTML5 client will consume HTTP services. A service here act as the entry point for creating the ASCII-encoded text files which will be picked up by the legacy command processor.
When the application wants to submit data to be processed (by the legacy command processor) it sends a POST request. At this point, the new system creates a message which is send via a Datatype Channel to its receiver.
The receiver, of each particular message, forwards the processing of the command. A compatible text file is created, which will be picked up by the legacy command processor in order to update the database.
When the application wants to retrieve data it sends a GET request. At that point, the ApiController uses a Gateway (and internally Dapper) to access the shared database.
On refresh, the client sends a new GET request and the ApiController will return the updated data.
Moving to Smartphones, Tablets and HTML5
Now, the client part has to be re-built with HTML5. That way, it will be accessible from the browser, Internet Tablets (similar to this one), and Smartphones.
Initially, Sencha Touch was a very good choice. It even has a designer. There is even Sencha Architect. Everything is written in JavaScript (which is good) and everything runs fast while testing on iPhone, iPad and other similar devices with fast hardware.
The company however is willing to sell the final product to a price which includes the cost of the devices. (That is, a license for 5 users should also include the purchase of 5 mobile devices.) This means that the price for the devices can become orders of magnitude higher than the actual price of the application itself.
The above lead to the fact that the application must ship with a not-so-expensive device. After doing some testing and comparison with other devices, a Sencha Touch application did not perform smoothly in slower hardware (like this one). (The most annoying part was the scrolling.)
After trying everything it looks like jQuery Mobile combined with mustache are the best choices in terms of performance. The redistributable file is packed with PhoneGap and the application performs well even on slower hardware giving the flexibility to select among a wide range of mobile devices.
*“Legacy” The definition that Michael C. Feathers gives in his excellent book.