This page is provided only as additional information for the developers interested in the ALP internals. You do not need to read this page in order to use, write applications for ALP. Writing extensions/native applications for ALP requires deep knowledge in COM and our component model (Jacked-Objects). Currently the API is closed and not public. Development of native applications is offered to customers with special requirements (if they need because of some reason non-ASP, non-CGI WEB based applications and plug-ins for ALP/CCGA).

A few words about CCGA

CCGA looks like a WEB server architecture but it is different in many details. WEB servers implemented over the CCGA will work fine but will not be compatible with the some typical but rarely used WEB server features. For example CCGA assumes query string format to be of param_name=value form.

Assumptions and definitions

• Operation must be request-response based. There is clear definition what is the request and what is the response. Combination of several requests in one is possible.
• Data transfer occurs through standard data holding structures passed through streams.
• Parameters of the request are binary data and parameters that can be represented as a structured tree. Headers if present are translated to parameters in that structure.
• Response is returned through a binary stream and header/parameters interface.
• CCGA defines a set of global objects - Site, Application and Session. CCGA engine implementation manages the life scope of these objects itself and the modules used are responsible for their creation and usage (In difference with IIS for example where these objects are not managed by IIS itself).
• Content generator is a Jacked class implemented in a loadable module (DLL) and supports standard set of jacks. The class must be implemented as thread safe.

CCGA can be implemented as a WEB server or as a IRC server for example. Using the global objects content generators are able to prepare a code instance for every scope and thus the core has responsibility only to dispatch the requests. CCGA doesn't define what is the request nature but it defines how it must be transferred. These details are specific to the realization.

Scheme above shows a simplified overview of the modules functionality in a typical CCGA implementation. CCGA specifies the jacks that must be supported by every component and order of the calls to their methods. Also there is requirements about threading - i.e. it is defined in which thread(s) a particular method will receive the calls. Threading specification gives ability to plan initialization of the thread dependend components - COM objects for example.

The most "undefined" part is the core. It depends on the purpose of the realization. For example in ALP it is "URL oriented" and its actions are fully defined after the URL parsing. In other realization - imagine some kind of service with instances running on multiply machines used by a central WEB server for dispatching the requests - will determine required actions using some internal WEB server - service protocol based on standard data structure tree, XML or something else. We can name the core also gateway and its purpose is to make possible content generators created for one CCGA architecture to run on another (of course the OS must be the same). CGHolder is not required to be portable between the CCGA implementations but it is possible to be done in some cases - for example ALP CGHodler will not supply high performance in the WEB server case.

CCGA is not an ultimate solution for everything it is just a way to make our products a bit more compatible with each other. ALP is the first intended to implement request-response abstraction and we want to make it possible to share components between ALP and future products that will implement the same abstraction.

The CCGA standards in final form will define all the components and processing made in the core. Core is mostly consumer of the jacks defined by the other components but features such as security and filtering will be defined strictly too. This will include request processors and some other components. Standard data structures used to pass requests have similar capabilities to the XML but they are binary. It will be possible to use XML in the future implementations but not for the internal communications. Structures are represented by classes and form a kind of tree-like object model. That model was built with the Jacked-Objects C++ library (one of our internal libraries) and in difference to the XML allows integration of the data and classes that process it. As an example you can take a look at the configuration files of the ALP. Classes are bundled with the branches there and they are created over them. Thus initialization happens automatically and persistence is a feature that programmer uses without need to write specific code.

ALP specifics

ALP implements one optional feature - Thread spy. CGHolder (see scheme above) and CG (content generators) must be able to receive "Cancel" requests in a different thread. ALP registers the CG (if specified in the configuration) with the Thread spy and if the generator runs longer than allowed Thread spy sends "Cancel" request to it.

The CCGA core in ALP is implemented as Asynchronous Pluggable Protocol. It is very simple and implements itself only the basic URL parsing features. Internet Explorer creates and destroys the registered protocol very often - for example when the mouse moves over a hyperlink thus it must not require too much time for creation and destruction. ALP is a good example for the case of specific CGHolder implementation. For example it is possible to use the same CGHolder object in a stand alone CCGA WEB server and ISAPI filter implementing CCGA, but in case of ALP CGHolder part of the core functionality must be moved to the CGHolder class in order to avoid time consuming operations on every mouse movement over a hyperlink for example.