newObjects (fromerly known as ZmeY soft) newObjects Active Local Pages 1.2
Home Products Docs & Libs
pixel.gif (49 bytes)
Home
Products by category
ALP site
ISAPI filters
ActiveX
Forums (discussions)
Buy direct (RegNet)
Articles and samples
Documentation online
Links
ACOMTools

Read more ...
Click here
ALP is implemented as an Asynchronous Pluggable Protocol. It acts like a WEB server but without need of network. It executes WEB applications such as ASP pages and CGI applications. ALP makes Internet Explorer to be server and client. With ALP you can write stand-alone desktop applications, CD-ROM autoruns, use ASP for pure desktop software and still keep your code ready to run on WEB servers too.
Write desktop software in ASP and CGI!
download it


NS Basic

Site navigation
Products
Active Local Pages



Binary and flat files

with ActiveX Pack1 ASP application is able to not just read/send binary files. They can be accessed as set of applciation defined records. And this is not limited to the files - any resource that behaves like file can be treated as like a DB table - memory streams, files, streams in OLE Compound files and so on.


Highlights of the day
Active Label ActiveX
Barcode ActiveX? Much more - the design and printing inside your WEB application
SQLite3 COM
SQLite3 COM ActiveX embeds the SQLite3 database engine and interface to it. Supports paremeterized views and triggers.
Active Local Pages 1.2
Write desktop apps in ASP and CGI. Create wutorun CDs using WEB technologies - yes it is possible!
ActiveX Pack1 family
Desktop Windows, CE/CE.NET and PocketPC! About 50 powerful components for all the Windows platforms.
AXGate 1.1 (new)
Script dafely any ActiveX in Pocket IE. Build applications in HTML and use local resources and components in them.
IE ScriptBar
Create complex toolbars for Microsoft Internet Explorer easier than you may have expected.

Licensing types legend
(M) Single machine license
(U) Unlimited per-company license
(D) Unlimited development license
(S) Special type of licensing

FreewarePPC.com

Quick contact
General
zmeyinc@newobjects.com
Support
support@newobjects.com
Sales
sales@newobjects.com

32Bit.com

Active visitors
69
Suggested links
Suggest this page to the other visitors. Click the button below to place this page in the list above .

 newObjects Active Local Pages 1.2   
Price: $15 (M) $320 (D) Discount for resalers
Information Download Buy
Welcome to ALP
Latest changes
ALP or PWS?
Overview
Licensing (read before buy)
FAQ
Discuss ALP (Forums)
ALP Internals
Purchase info
Application deployment (deployment examples)
ALP 1.2 Full (SFX 3.3M)
ALP 1.2 Full (zip 4.5M)
ALP 1.2 Redistributables only (SFX 0.7 MB)
ALPFrame demonstration
Buy (per-seat) $15
Buy (developer) $320
Buy on ShareIt
More information

ALP Internals

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



Copyright newObjects (ZmeY soft) 2001-2005