GSoC Application Server Project

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. It is realistic not to expect all of the goals to be met by one person in one summer.

• Definitions of Application Server
  • Other Definitions
  • Project Definition
    • Supplier of Web Services
    • Supplier of UI for Web Services
• Goals
  • Create a specification for how to package services
  • Create a specification for how to specify web services
  • Create a specification for how to specify UI services
• Discardable Goals
• Non-Goals
• Design Details/Choices
• Links
• General Discussion

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 Weight

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|feature) is that Æjaks currently only works on Java Application Servers.

Heavy Weight

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". 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. (1,2) Minimal config install
2. (1,2) Zero compile install (i.e. pure Tcl except for pre-compiled extensions)
3. (1,2) Create a specification for how to package services.
4. (1,2) Create a specification for how to specify web services.
5. (1,2) Create a specification for how to specify UI services.
6. (1,2) Create a specification for how to authenticate a package contains the untampered code that provides the service it claims to.
7. (1,2) Create an API and specification for a plugable security module.
8. (1,2) Create an API and specification for a plugable authorization module.
9. (1,2) Create an API to allow another application (possibly another application server) to obtain updates to a service.
10. (1,2) Create a single simple API for logging of messages.
11. (1,2) Create a management API to allow the installation/deinstallation of services.
12. (1,2) Create a management API to allow the mapping of URLs to installed services.
13. (1,2) Create a management API to allow Access Control List to be placed on services.
14. (1,2) Create a management API to allow for controlled upgrades to a service without taking the server or service down.
15. (1,2) Create a management API for a simple user authorization module.
16. (1,2) Create a management API for filtering and routing of messages.
17. (1) Create a management API for resource usage (how many threads, how much time/memory).
18. (1,2) Create a GUI to the API for installation/deinstallation of services.
19. (1,2) Create a GUI to the API for mapping of URLs to installed services.
20. (1,2) Create a GUI to the API for Access Control List to be placed on services.
21. (1,2) Create a GUI to the API for controlled upgrades to a service without taking the server or service down.
22. (1,2) Create a GUI to the API for a simple user authorization module.
23. (1,2) Create a GUI to the API for filtering and routing of messages.
24. (1) Create a GUI to the API for resource usage (how many threads, how much time/memory).
25. (1,2) Create a module for session initiation, state storage, migration and finalization (including reaping of dead sessions) that conforms to the API mentioned above.
26. (1,2) Create a simple user authorization module.
27. (1,2) Create a simple security module that implements Access Control List.
28. (2) An implementation of the Æjaks API in pure Tcl (other than using existing DOM extensions).

Create a specification for how to package services

It is strongly suggested that the packaging mechanism be a Starkit. Starkits are widely accepted as the de facto standard on packing Tcl/Tk code.

Create a specification for how to specify web services

The project will use WS::Server and WS::Utility APIs to define Web Services. The API may have to be extended by the project.

Create a specification for how to specify UI services

A specification similar to WS::Server needs to be created, but can be much more light weight since type information may not be required. It may be very desirable to separate the processing from the formatting of the output (i.e. allow multiple forms of output). This may actually resolve into multiple specifications, e,g. one for HTML form/argument input and another for Æjaks.

An example of a simple specification for HTML form/argument input may be:

    UI::Server::Service ServiceName
    UI::Server::Proc ServiceName ProcedureName ArgList Body

where ArgList is a list of argument names, the last one can be args. Form/input elements are mapped by name to the arguments, any remaining elements are passed to args as a dictionary.

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.

1. (2) The re-implementation of the Æjaks API in pure Tcl should run on any web/application server.

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
• Will use WS::Server and WS::Utility APIs to define Web Services
• Use Starkits for packaging applications (aka servlets)

Links

• Wikipedia Definition of an Application Server[L2 ]

General Discussion