An EWD system consists of a server system accessed by browser clients.
The Server may run Apache or a Node-js Server (or both to be strictly correct). As such it must have a domain-name or IP address on the LAN or the Internet.
Usually an EWD-based system will operate securely using https:// protocol and therefore use SSH as a component of the server. See details of how it uses port 443 typically to encrypt messages transmitted between client browser and server over what my be the public Internet or a private (hospital) Intranet (LAN - local area network plus or minus wireless linkages. See EWD Network and SSH.
An Apache web server can be a complex topic in itself because of the multitude of features and modes available in this amazing open source product. Once configured, however, it just works and need not worry the developer after a system is set up and configured. Getting there is managed in the dEWDrop Virtual Machine or by AstroVistA debian-type installer.
Instead of apache, a Node js Web Server may be used as a component of EWD.
M_Gateway is a component which runs on the server and maps the incoming URLs to GTM as special EWD references instead of other web-requests to the server. It is analogous to older CGI requests which were mapped in early web systems to be interpreted by the Apache to create html pages from databases with 'variable' data instead of being fixed web html pages. EWD references by the browser take the form:
https is the protocol used to invoke SSH secure transmission for the request to the EWD server. 192.168.1.150 is a typical LAN IP address of the EWD server (in lieu of a domain name). vista/ is a specific string - a code to invoke the EWD system to process the rest of the URL. See M_Gateway. MyApp/ represents an EWD-App/EWD Application - a set of EWD code pages working together, compiled by EWD. MyPage.ewd has the specific extension .ewd and is a container page or Starting page of the EWD subsystem
The M_Gateway component is a low-level extension of the Apache server which triggers Run-time EWD. The "vista" here in the URL triggers EWD-Runtime with the rest of the URL at the back end of Apache.
EWD Pages are simple text files which have the file-extension *.ewd are high level tag-based code which are Compiled by EWD into functioning Mumps Routines (MRoutines) which are executed by the runtime portions of EWD.
EWD does this via Custom-Tags which are logical extensions of EWD. Rob Tweed developed the set of custom-tags which invoke extJS and Sencha Touch, but any developer can similarly develop custom-tags for other Frameworks or special Functions such as DOJo or to link directly with VistA on the backend.
The EWD Compiler is written in MUMPS and thus is invoked as a MUMPS Routine, for example by the M Command:
The EWD Compiler uses the NameSpace ^%zewd*. GTM source MRoutines are files _zewd*.m and GTM Object MRoutines are _zewd*.o. Note the % within MUMPS MRoutine Names is transformed to Underscore in Linux (which does not allow the % character in its filenames). GTM source files, the MUMPS source code are plain text files with extension *.m and GTM compiles these to corresponding files *.o which are invoked at GTM Runtime into running Linux processes composed of a number of MRoutines which reference each other. The fileName is the MUMPS RoutineName.
These files are scattered among a number of Linux Folders/Directories and this configuration of folders may be a source of confusion for the EWD Developer and are discussed in EWD Folders and Files.
EWD manages a number of otherwise sticky problems with web-based multiuser interactions between client browser and EWD server with the gtm mumps backend database. These include:
Creating a logical user-state in the server and browser in a stateless network at the TCP/IP level. Encrypting internal page references to prevent illegitimate entrance by unauthorized clients.