Client Platform Delegate¶
FWD has an inherently server-oriented design. The converted application code is only ever executed in the FWD Application Server. When an ABL session is executing, it executes in the server on a thread that has a security context assigned that maps to the user or process account that represents that session. Multiple sessions simultaneously run in the same server and the state of the sessions is kept separate. All ABL database processing is handled in the application server and ultimately that processing is translated into SQL and submitted to the database server where traditional SQL set-oriented processing is used.
In contrast, the ABL has an inherently client-oriented design. Some features such as an interactive user interface (UI) are obvious in how they may only implemented on a client system (where the end user exists). However, there are several other areas of the ABL that must be implemented in a per-user JVM process in order to match the behavior of the ABL in all user cases. In particular, that JVM must be executed in the proper operating system account to satisfy any dependencies the ABL application has on the environment. These non-UI features are handled by the Client Platform Delegate portion of the FWD Client. Since there is always a one-to-one ratio of a FWD Client JVM and the user/batch/Appserver/WebSpeed ABL session, this cleanly satisfies the requirement.
The following lists the ABL features which have at least some of their implementation in the Client Platform Delegate:
| Category | Description | ABL Features | FWD Server Class | FWD Client Class | Uses Native Code |
|---|---|---|---|---|---|
| Environment | Read/modify INI files, read/modify the Windows Registry, control the PROPATH, read state about the process. | Some SESSION system handle support (BATCH-MODE, TEMP-DIRECTORY), PROPATH (assignment and reading), GET-KEY-VALUE, PUT-KEY-VALUE, LOAD, USE, UNLOAD, OPSYS, (CHARSET, CPINTERNAL, CPSTREAM, CURRENT-LANGUAGE all should have a client-side implementation but do not at this time) | EnvironmentOps | EnvironmentDaemon, OsPropertiesDaemon | Yes (the Windows registry support uses registry.c) |
| File System | Read, search and manage the file system. | FILE-INFO system handle, SEARCH, OS-ERROR, OS-DRIVES, OS-GETENV, OS-APPEND, OS-COPY, OS-CREATE-DIR, OS-DELETE, OS-RENAME, MEMBER | FileSystemOps | FileSystemDaemon | Yes (filesys.c, filesys.h and filesys_<platform>.c), used for OS-GETENV and for some of the features reported by the FILE-INFO system handle. |
| Library Access | Invocation of native shared library APIs. | RUN (only for procedures defined using the EXTERNAL keyword), RELEASE EXTERNAL | NativeInvoker | LibraryDaemon | Yes (library.c, library.h and library_<platform>.c), this code is in turn dependent upon libffi |
| Memory | Direct memory access. | MEMPTR (almost all support must directly access memory) | memptr | MemoryDaemon | Yes (memory.c) |
| Process Launching | Launch child processes as a shell or connected to pipes for streams usage. | OS-COMMAND, BTOS, DOS, OS2, UNIX, INPUT THROUGH, OUTPUT THROUGH, INPUT-OUTPUT THROUGH | ProcessOps | ProcessDaemon | Yes (process.c, process.h and process_<platform>.c, shell.c, shell.h and shell_<platform>.c) |
| Socket Client | Connect to and use a TCP/IP socket as a client. | Socket object handle features | SocketFactory | LowLevelSocketImpl | No |
| Socket Server | Create, listen on and use a TCP/IP socket as a server. | Server socket object handle features | SocketFactory | LowLevelSocketListenerImpl | No |
| Streams | All forms of stream processing. | INPUT FROM, OUTPUT TO, INPUT CLOSE, OUTPUT CLOSE, INPUT THROUGH (the read/write portion), OUTPUT THROUGH (the read/write portion), INPUT-OUTPUT THROUGH (the read/write portion), INPUT-OUTPUT CLOSE, IMPORT, EXPORT, PAGE, SEEK (statement and function), PUT, LINE-COUNTER, PAGE-SIZE, PAGE-NUM, redirected terminal support when it read from to writes to a stream | StreamFactory, Stream and RemoteStream | StreamDaemon and Stream subclasses | Yes (the OS-DIR stream relies upon the FileChecker Java code which uses filesys.c) |
| Web Services | Invocation of a web service. | RUN (only for procedures defined as a web service) | ControlFlowOps/ServerImpl/WebServiceHelper | WebServiceImpl | No |
To make this work, the converted code that uses the above-listed ABL features will call a FWD class on the server which in turn calls (through the remote object protocol) down to a class on the FWD client. The FWD client may utilize Java code to implement the feature, it may call native code (via the Java Native Interface or JNI) in the libp2j.so or some combination of both techniques. The shared library libp2j.so is loaded by the FWD Client when it starts, which means it must be found on the client system. A convenient way to enable this is to list the shared library's containing folder in the the client JVM's java.library.path system property.
It should also be noted that the FWD Client user-interface (presentation delegate) code two dependencies on the native code (libp2j). The ChUI has a native TTY driver. On Linux/UNIX it uses NCURSES to directly drive a terminal and on Windows it uses the WIN32 Console API. The Java code is ConsoleHelper and the native code is found in terminal.c, terminal.h and terminal_<platform>.c. The client also needs to carefully manage signal processing from the operating system, this is done in the ClientCore Java code and uses signals.c, signals.g and signals_<platform>.c.
© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.