ALP obeys the CCGA (Component Content Generation Architecture) developed by us as
internal standard. It defines a set of jacks (interfaces), components that must provide
them and communications between. CCGA allows component writing and thus allows extensions
to be written. The lowest level of the CCGA are content generators (or native applications)
they will be portable between different CCGA environments - for example ASP content
generator will run under ALP but it will be able to run under a CCGA WEB server too.
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
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 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
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.