Version 6 of GSoC Application Server Project

Updated 2009-04-04 17:55:59 by GWL

This page contains design goals and discussions for the Tcl Application Server whose development is beginning as part of the Google Summer of Code (GSoC) project.

Definitions of Application Server

In the initial discussion of this project it became clear that different people had different definitions of what an application server was. This section of the Wiki page is intended to review those definitions then define what is meant by application server for this project.

Other Definitions

  • A common interface or API by which Tcl scripts interface to a web server which is running them.
  • A set of common interfaces that is available to an application run by a web server for access databases, et al
  • A server to supply updates of applications running on other computers
  • A web page server

Project Definition

The definition used on the project is similar to what the Java folks mean when they talk about an application server[L1 ]. For this project we will be talking about two related definitions:

  1. A server which run applications that supply a web service, either SOAP or REST based.
  2. A server which supplies a UI for a web service.

Supplier of Web Services

Supplier of UI for Web Services

For this type of server, the application runs partially in the server and may run partially elsewhere. Generally there are three types of UIs:

  1. Light Weight UI
  2. Medium Weight UI
  3. Heavy Weight UI

Light Weight

The user interface is rendered in HTML. The generation of HTML currently has a well defined and well received Tcl level API in the HTML package of TclLib.

Medium Wight

This approach to user interfaces uses JavaScript or the Tcl Plugin to implement the UI running in a bowser on the user's computer.

While the Tcl Plugin would seem to be the most desirable and easiest road since the implementer presumably already knows Tcl/Tk, or at least only has to learn one language. The reality is that there are several negative aspects to this approach:

  1. The Tcl Plugin does not ship pre-installed on any browser.
  2. Not all browsers accept the Tcl Plugin.
  3. Some company security policies would prevent the installation of the Tcl Plugin.
  4. Individuals may be extremely reluctant to install the Tcl plugin

The above considerations greatly reduce the deployability of "applications" that use the Tcl Plugin.

Now lets consider JavaScript. It has the following advantages:

  1. JavaScript ships pre-installed on virtually all browsers.
  2. It is rarely blocked by companies or users.
  3. There is a package in TclLib to support generation of JavaScript

However it has the following disadvantages:

  1. The programmer now must learn two languages to create their application.

However, there appears to be something that offers the best of both worlds Æjaks. This allows the programmer to learn Tcl/Tk and the Æjaks API (which is similar) to Tk to program an application. The current drawback is that Æjaks currently only works on Java Application Servers.

Heavy Wight

This is sometimes also called 3-tier or n-tier approach. In this approach sever levels of servers may be used (database, web services, application code/update server). The GUI is implemented by a Tcl/Tk program that the user installs and runs locally that communicates with a database or web services server. Where application server comes in is to serve up the code and/or updates to the code to be run locally. Depending on the design model chosen the Tcl/Tk program that the user launches may be very minimal and be just enough to download the actual application every time it is run. A variant on the previous model is to have the use launch a very minimal that access a local cache of the actual code and checks the server for any changes to the code before running the actual application. If changes are discovered, they are downloaded to the cache and the actual application then run from the cache.

Goals

This section list the long term goals of the project. As goals are meet, please mark them with the word "Meet". Initially this is a bulleted list. As a details are provided on a goal, please move it out of the bullet list and place it after as a Header Level 2 item.

Items with a (1) refer to a goal that applies to Supplier of Web Services. Items with a (2) refer a goal that applies to Supplier of UI for Web Services. Items with a (1,2) refer to a goal that applies to both.

  1. Create a management API to allow the installation/deinstallation of services.
  2. Create a management API to allow the mapping of URLs to installed services.
  3. Create a management API to allow Access Control List to be placed on services.
  4. Create a management API to allow for controlled upgrades to a service without taking the server or service down.
  5. Create a management API for a simple user authorization module.
  6. Create a management API for filtering and routing of messages.
  7. Create a GUI to the API for installation/deinstallation of services.
  8. Create a GUI to the API for mapping of URLs to installed services.
  9. Create a GUI to the API for Access Control List to be placed on services.
  10. Create a GUI to the API for controlled upgrades to a service without taking the server or service down.
  11. Create a GUI to the API for a simple user authorization module.
  12. Create a GUI to the API for filtering and routing of messages.
  13. Create an API to allow another application (possibly another application server) to obtain updates to a service.
  14. Create an API and module for session initiation, state storage and finalization (including reaping of dead sessions).
  15. Create a single simple API for logging of messages.
  16. Create an API and specification for a plugable security module.
  17. Create an API and specification for a plugable authorization module.
  18. Create a simple user authorization module.
  19. Create a simple security module that implements Access Control List.
  20. An implementation of the Æjaks API in pure Tcl (other than using existing DOM extensions).

Discardable Goals

This section list the long term discardable goals of the project. As goals are meet, please mark them with the word "Meet" and move it to the Goals section. If it is determined that a goal can not be meet, move it to the Non-Goals section.

Initially this is a bulleted list. As a details are provided on a goal, please move it out of the bullet list and place it after as a Header Level 2 item.

Non-Goals

This section list the non-goals of the project.

Initially this is a bulleted list. As a details are provided on a goal, please move it out of the bullet list and place it after as a Header Level 2 item.

  • Able to run under any web server anywhere.

Design Details/Choices

This section will be filled in as the project develops.

  • Tcl 8.6 based (this allows the use of TclOO and Tdbc)
  • Initial version will be Wub based

Links

  • Wikipedia Definition of an Application Server[L2 ]

General Discussion

Categories: Development Tools, Applications