|We will not try to explain all the details
here. Complete information about the CCGA will become public at later time. Here are
explained only basics that can help the ALP.
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 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.
- 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 and does not define security or a dispatching scheme. These details are
specific to the realization.
Scheme above shows the 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 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
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.
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.