Progress
ADM 2 Guide
SmartDataObject Deployment Files
The ADM support files are shipped only with the Windows versions of the product. This is because you normally develop SmartObjects only with the AppBuilder, which generates a great deal of code for SmartObjects. Because the include files and super procedures that form the ADM become in effect a part of the final application, it is essential that you use the same version of those files to build and run your application on all platforms. As a result, you must port needed super procedures to each deployment platform along with the application code. In order to test SmartDataObjects on an AppServer on which the Progress software is not installed, you must put these files into an
adm2
directory on that machine relative to its PROPATH.You need the following super procedures to run standard SmartDataObjects on an AppServer, either from a Progress client, from WebSpeed, or from a non-Progress client such as Java:
To facilitate testing distributed applications on a single NT workstation (where you can run both a Progress client and a Progress AppServer session), these three super procedures reside in both the
tty
directory and thegui
directory.You must move all SmartDataObjects to be run on an AppServer to that machine. You usually do not need to recompile the super procedures or SmartDataObjects on the target machine, unless it is a platform to which Progress .r code is not portable. However, if it is necessary or desirable to recompile the SmartObject super procedures or the application’s SmartObjects on the target machine, you must also move the following source files, as well as the
custom
subdirectory and its contents, to that machine, in asrc\adm2
directory relative to the PROPATH:When you run a SmartDataObject on an AppServer, the supporting super procedures
smart.r
,query.r
, anddata.r
are started automatically, just as on the client, and are left running in support of any SmartDataObjects that are run for the duration of that AppServer session. All the super procedures run stateless, without maintaining any data specific to an individual client, thus the same AppServer process can service a number of clients in succession, even when each client expects to have exclusive use of that AppServer for the duration of its connection. As a result, your application incurs the overhead of starting super procedures once per AppServer session. (You can even run these procedures persistently as part of the session startup.)
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |