Browser Interface Local Server (BILoc) Applications

Intro:

A standard web application consists of a browser for user interface display, and a server providing the application functionality, with connection between these two pieces over TCP/IP. For web applications like eCommerce, this separation is obvious. But with applications for project management, inventory management, finance, music jukebox, photo album, etc. the separation is less clear. You may want the information all on the server, all local, a mix of local and server, or replicated (synchronized) in both places.

The standard way to deal with these types of applications today is to write a standalone application to be installed on the user's computer. This application handles the display, local information processing, and server information access. Meanwhile

  1. The application must be installed for user access to server information.
  2. There was already a browser installed with user display and server communication capabilities.

The only thing that really needed to be installed was the application functionality, which could have been deployed to a local web server to create a local application. The resulting browser-interface/local server (BILoc) application could then be accessed directly from the browser by URL, for example as 

    http://localhost:8080/deploymentname/appname

Alternatively an icon could launch the default browser with this URL. A single installation of the local web server that starts up with the system could potentially host multiple applications, or the application and the web server could be packaged together as a single app.


Paradigm shift:

So now instead of a server-aware application, you have a local-enabled application. It now becomes possible to "tear off" a web application for use locally.


Work ahead:

Apache/Tomcat wasn't built to run as a local web server. In fact what we are looking for may have more in common with device embedded web servers. The idea is something that will unzip a .war, and then provide the standard HttpServletRequest/Response interface. Alternatively it could implement a SAND UIFormAdaptor (or the SAND HTTP interfaces) directly.

Of course the other major piece that needs to be available when running locally is persistency. This can either be solved by installing the same database used on the server, or by switching to an embedded database, or by using to a file based system supported by the application (e.g. a file-based SAND Persister implementation using the built in message matching).

back to techbase index







© 2005 SAND Services Inc.
All Rights Reserved.