NetDynamics Server Architecture

 ND Terminology
        Connection Client (CC) -- Located on the Web Server in the "cgi" directory, this is a lightweight CGI process responsible for forwarding ND URL requests from the Web Server to the ND Application (APP) server. These are easily identified by the ndCGI.exe, ndNSAPI.dll or ndISAPI.dll
        Java Connection Processor (CP) -- This component is responsible for running the Java business logic in the ND projects. It produces the dynamic HTML pages that are returned. The CP runs in a Java Virtual Machine (JVM).
        Persistence Engine (PE)-- This is NDs way of preserving state and session information for the web clients. It will store session objects for each web client, a way of maintaining client uniqueness. It also holds the "global" session objects (session information that is shared among all clients). The CP may get or put sessionable objects in and out of the PE anytime during the web event.
        Data Service (DS)-- this is a process responsible for processing database requests that are received from the CPs. it uses cached connections to the database(s) for improved performance. It can receive SQL or Stored Procedure requests from the CP and forward those requests to the appropriate data source (like Oracle, CICS, SAP, etc). The results are passed back to the CP for use in generating the requested page.
 
 

                                    ** Special Thanks to Craig Conover of NetDynamics, Inc. for the wonderful graphics!!!

    Web Flow using a NetDynamics Application
        Let's look at how these parts work together to use an ND application.
           When a user requests a ND page from their browser, the URL is sent to the web server and the web server will process the URL,
             "http://www.company.com/cgi-bin/ndCGI.exe/PrjFoo/PgHome
           then it runs the CC (ndCGI.exe) which receives the /Project/PgHome as its parameters. The CC will forward the parameters to the CP on the ND Application Server.

            Next the CP receives the ND project and page parameters and it will read all of the project's objects into local cache (this actually only happens for the first request of the first user), then it will create a new Session for the new user. It does this because it did not receive a Session ID with page request. The PE is responsible for generating the next session ID and returning it to the CP. The CP will continue with the page load event process for pgHome.
            Now the CP finishes creating the HTML for the page request and sends it back to the CC on the web server. The CC relays the HTML back to the HTTP server. The web server returns the HTML back to the requesting browser. The browser will parse the HTML (just like any other page), download embedded graphics, applets, etc. and finish displaying the HTML.

        If the client now requests a connection to a database (this would be a second request to the ND application), things change just ever so slightly. The CP will check for cached project objects and the CP will receive the session id from the URL. When the CP gets a session id it will contact the PE for the session objects for session id "123".

The URL would also contain a method, typically an _onWebEvent(). Let's say that this page is bound  to a data object that selects employees to be displayed. This will prompt the CP to send a DB request to the identified DB.  The DS will make a proper connection to the DB and send the request. The DB server returns the result set to the DS which will in turn send it to the CP for display on the page.
 
 


 
 
 
 

The  CP inserts the results, mapping data fields from the result set (data object) to the display fields on the page (this is known as binding). Now the CP will send the page to the CC on the web server who will return it to the browser.
 
 


 


 
 
 
 

 Contents    What is NetDynamics?    The Event Model