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 some cases.

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 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.