EG is either not a thin client, or not your normal thin client.
Thin clients are typically web enabled applications that access an underlying application server. The web server provides the user interface, and some light application responses. The application server does the next layer of heavier lifting, and may/will use a lower level server to do the real heavy lifting/processing.
EG is more like a thick or middle weight client.
A classic thick client would have been written in Visual Basic or PowerBuilder, where these applications ran on the workstation, provided the graphical user interface, and connected to underlying databases.
EG is written in ??, I guess within the .net framework (I had though it Java, and wish it were). It interacts with a metadata server or at least a metadata repository, and sends work tasks to an underlying SAS server, wherever it may be.
A SAS server is not the same thing as an Oracle server or a WebSphere server. SAS is more like Java, than those other things, but also not like Java.
Java is a programming language, like C and COBOL and ForTran are programming languages.
Java unlike other traditional programming languages, also defines an underlying standardized virtual machine. Java is compiled into the JVM's "machine" byte code (b-code), which is similar to an old compiler technique of compiling into p-code to provide transportability across platforms and compiled languages, but it is not the same.
The JVM either interprets the b-code, which is slow and inefficient, or just-in-time (JIT) compiles the b-code into the native machine code of the underlying "physical processor".
The command to run a java program is "java ... something.java" (somthing.class?) or "java ... something.jar", where the referenced file contains a class that contains the "main" method.
SAS is a programming language.
SAS is a statistical analysis system
SAS is ....
The command to run a sas program is "sas program.sas" or "sas program ", or some such form.
Just typing in "sas" on a windows or Unix box, will bring up an interactive SAS session, which is similar to an IDE.
The "sas" program is actually/essentially, a JIT compiler that takes the text SAS program, compiles and executes it in blocks at a time, per some well defined rules as to what a "block" is. This is not a server. It is not a virtual machine, per se.
If SAS is installed on a host box, and many people are able to use that SAS installation at the same time, then that box is referred to as a SAS server. If I have SAS installed on a mainframe, I can log into the mainframe through tso/ispf and then submit SAS jobs to do data processing, job written in the SAS programming language. If SAS is installed on a Unix "server", I can log into that box via telnet and run "sas ..." jobs on that box.
If SAS/CONNECT is installed on both the Unix box and the mainframe, I can submit a job on either "server" to remotely process SAS code on the other server via the signon, rsubmit and endrsubmit statements. SAS/CONNECT contains SAS/IT = Integration Technologies, which provide the inter-server connections/communications.
SAS EG is what I would call a thick client that requires the installation of SAS/IT to connect to a remote server that has SAS installed on it -- aka the "SAS Server". Part of SAS/IT is a process/program called a "spawner". The spawner is the thing that actually submits the "sas ..." command, which then executes SAS code.
Part of EG is a metadata repository, which incorporates the metadata concept of a Logical SAS Server, a named thing that references a physical box that has SAS installed on it. You can have multiple logical "servers" which point to the same box, but have differing user/application logins. The function of the metadata repository can be subplanted by SAS's SAS MetatData Server, which has much richer capabilities than the simple metadata repository.
EG essentially composes SAS code (a GUI based code generator) and ships it off to a "server" which is simply a started interactive SAS session, with that session's display capabilities turned off. We have been told by Chris@SAS that EG then polls the "server" for log file information while a task is running on that server. If all tasks are complete, then the remote SAS session is sitting idle, and EG is sitting idle, except to respond to user interface stuff. But, if an intervening network device can timeout the network connection between the EG workstation and the host that SAS is running on, due to lack of activity, then perhaps EG isn't polling, but the "server" is simply sending back log messages to the EG workstation as an ODS destination. I know from my own experience that if a data step takes an hour to run, the log entry for that step doesn't happen for that hour.
Is this interaction clear?
Does it make sense?
Am I correct?
Message was edited by: Chuck