Distribution perspective - Infrastructure
This article describes how formcycle can be used in various scenarios and infrastructures and how the corresponding communication paths and ports behave.
Contents
Scenario 1: Master server on the intranet
In the first scenario, formcycle in the form of the master server is only used for internal purposes. Accordingly, it is only operated on the intranet and there is no connection or access option to or through the Internet.
Use | Access |
Administration interface from the Internet | No |
Administration interface from the intranet | Yes |
Forms from the internet | No |
Forms from the intranet | Yes |
Components of the infrastructure
Module | Description |
Apache Tomcat with formcycle master server | Servlet container that provides formcycle |
DBMS | Database server which provides the formcycle system database |
Mail server | Mail server which enables the mail delivery by formcycle |
Internal third-party systems | Internal third-party systems which are connected by formcycle |
Protokolle und Ports
Connection | Protocol | Use | Ports |
Browser on the intranet → formcycle master server | HTTP(S) | Access to the administration interface or the forms | Tomcat standard: 8080 or 8443 |
WS(S) | Websocket connection between the user browser and the master server | Tomcat standard: 8080 or 8443 | |
formcycle master server → Database | JDBC | Connection of the system database | Depending on the database used. Examples: 3306 (MySQL), 5432 (PostgreSQL), ... |
formcycle master server → Mail server | SMTP | Connection of the mail server | Standard: 25 or 578 |
formcycle master server → Third-party systems | Protocols from third-party systems (optional) | Depending on the functional scope of formcycle, various third-party systems can be connected. | Port according to third-party system |
Quality and/or performance characteristics
Operating a master server in the intranet offers a high level of security, as there is no connection to the Internet. Also, no network load is generated in the form of a socket connection to any front-end server. In this scenario, the master server can be scaled both vertically and horizontally. For the last of these, a load balancer is required that has to work with sticky sessions.
Scenario 2: Master server with reverse proxy
In the second scenario, formcycle is operated in the form of the master server on the intranet and access to it is enabled by means of a reverse proxy. This allows applicants, clerks and administrators to access the administration interface and forms.
Use | Access |
Administration interface from the Internet | Yes (via reverse proxy) |
Administration interface from the intranet | Yes |
Forms from the internet | Yes (via reverse proxy) |
Forms from the intranet | Yes |
Components of the infrastructure
Module | Description |
Apache Tomcat with formcycle master server | Servlet container that provides formcycle |
Reverse proxy | Reverse proxy which enables access to the master server from the Internet |
DBMS | Database server which provides the formcycle system database |
Mail server | Mail server which enables the mail delivery by formcycle |
Internal third-party systems | Internal third-party systems which are connected by formcycle |
External third-party systems | External third-party systems which are connected by formcycle |
Protocols and ports
Connection | Protocol | Use | Ports |
Browser on the Internet → Reverse proxy | HTTP(S) | Calling up the administration interface or forms via the reverse proxy | Web standard: 80 or 443 |
WS(S) | Websocket connection between the user browser and the master server | Web standard: 80 or 443 | |
Browser on the intranet → formcycle master server | HTTP(S) | Access to the administration interface or the forms | Tomcat standard: 8080 or 8443 |
WS(S) | Websocket connection between the user browser and the master server | Tomcat standard: 8080 or 8443 | |
Reverse proxy → formcycle master-server | HTTP(S) | Resolving WS(S) requests to the reverse proxies by forwarding them to the master server | Tomcat standard: 8080 or 8443 |
WS(S) | Resolving HTTP(S) requests to the reverse proxies by passing them on to the master server | Tomcat standard: 8080 or 8443 | |
AJP | Alternatively, the Apache JServ Protocol can also be used for communication between the reverse proxy and the master server. | Tomcat standard: 8009 | |
formcycle master server → Database | JDBC | Connection of the system database | Depending on the database used. Examples: 3306 (MySQL), 5432 (PostgreSQL), ... |
formcycle master server → Mail server | SMTP | Connection of the mail server | Standard: 25 or 578 |
formcycle master server → Internal third-party systems | Logs from internal third-party systems (optional) | Depending on the functional scope of formcycle, various third-party systems can be connected. | Port according to third-party system |
formcycle master server → Reverse proxy → External third-party systems | Protocols from external third-party systems (optional) | Depending on the functional scope of formcycle, a wide variety of third-party systems can be connected. | Port according to third-party system |
Quality and/or performance characteristics
Operating a master server on the intranet offers a high level of security, as there is no direct connection to the Internet. However, this functionality is made possible by the reverse proxy. It also handles the forwarding of requests from the Internet to the master server. In this scenario, the master server can be scaled both vertically and horizontally. For the last of these, a load balancer functionality is required that has to work with sticky sessions.
Scenario 3: Master server with front-end server
In the third scenario, formcycle is operated in the form of the master server on the intranet and a frontend server in the DMZ. This enables forms to be delivered via the frontend server while no direct access to the administration interface of the master server is possible. If necessary, the mailbox is also offered on the frontend server so that administrators can also manage incoming data records.
Use | Access |
Administration interface from the Internet | No |
Administration interface from the intranet | Yes |
Forms from the internet | Yes (via frontend-server) |
Forms from the intranet | Yes |
Components of the infrastructure
Module | Description |
Apache Tomcat with formcycle master server | Servlet container that provides formcycle master server |
Apache Tomcat with formcycle frontend server | Servlet container that provides formcycle frontend server |
DBMS | Database server which provides the formcycle system database |
Mail server | Mail server which enables the mail delivery by formcycle |
Internal third-party systems | Internal third-party systems which are connected by formcycle |
External third-party systems | External third-party systems which are connected by formcycle |
Protocols and ports
Connection | Protocol | Use | Ports |
Browser on the internet → formcycle frontend server | HTTP(S) | Access to the forms and, if applicable, the mailbox | Tomcat standard: 8080 or 8443 |
WS(S) | Websocket connection between the user browser and the master server | Tomcat standard: 8080 or 8443 | |
Browser on the intranet → formcycle frontend server | HTTP(S) | Access to the administration interface or the forms | Tomcat standard: 8080 or 8443 |
WS(S) | Websocket connection between the user browser and the master server | Tomcat standard: 8080 or 8443 | |
formcycle master server → Database | JDBC | Connection of the system database | Depending on the database used. Examples: 3306 (MySQL), 5432 (PostgreSQL), ... |
formcycle master server → Mail server | SMTP | Connection of the mail server | Standard: 25 or 578 |
formcycle master server → formcycle frontend server | Socket connection | A socket connection based on the SIMON library is used for communication between the master and front-end server. This is established by the master server and then enables bi-directional communication. | SIMON standard: 4753 (UPD and TCP) |
| formcycle master server → Internal third-party systems | Logs from internal third-party systems (optional) | Depending on the functional scope of formcycle, a wide variety of third-party systems can be connected. | Port according to third-party system |
Quality and/or performance features
The operation of a master server in the intranet offers a high level of security, as there is no direct connection to the Internet. For this purpose, a frontend server is operated in the DMZ, which enables access to the forms and, if necessary, the mailbox. This saves the master server the load of form delivery and initial processing. The actual status processing still takes place on the master server. In this scenario, the master server can be scaled both vertically and horizontally. However, the last of these usually only makes sense if the frontend servers are also scaled vertically. The background to this is that a frontend server only ever allows one connection through a master server. If the frontend server is to be scaled vertically, it is advisable to operate it behind a load balancer with sticky sessions. Alternatively, each frontend server can also be accessed via its own URLs, allowing functional separation to be achieved.
Scenario 4: Master server in the DMZ
In the fourth scenario, formcycle is operated as the master server in the DMZ. This enables the delivery of forms and direct access to the administration interface from the Internet. As the master server requires a database, this can either be operated in the DMZ or accessed via a reverse proxy on the intranet.
Use | Access |
Administration interface from the Internet | Yes |
Administration interface from the intranet | Yes |
Forms from the internet | Yes |
Forms from the intranet | Yes |
Components of the infrastructure
Module | Description |
Apache Tomcat with formcycle master server | Servlet container that provides formcycle master server |
DBMS | Database server which provides the formcycle system database |
External third-party systems | External third-party systems which are connected by formcycle |
Protocols and ports
Connection | Protocol | Use | Ports |
Browser on the internet → formcycle master server | HTTP(S) | Access to the administration interface or the forms | Tomcat standard: 8080 or 8443 |
WS(S) | Websocket connection between the user browser and the master server | Tomcat standard: 8080 or 8443 | |
formcycle master server → Database | JDBC | Connection of the system database | Depending on the database used. Examples: 3306 (MySQL), 5432 (PostgreSQL), ... |
| formcycle master server → External third-party systems | Protocols from external third-party systems (semi-optional) | Depending on the functional scope of formcycle, various third-party systems can be connected. Since formcycle requires a mail server for proper operation, an external service provider is usually connected. | Port according to third-party system |
Quality and/or performance characteristics
Operating a master server on the Internet offers a high level of accessibility as it can be reached directly from the Internet. The accessibility and availability of a database and a mail server must be considered. In this scenario, the master server can be scaled both vertically and horizontally. For the last of these, a load balancer functionality is required that has to work with sticky sessions.
Addition: Master server cluster
Cluster functionality is necessary for the operation of several master servers. This ensures that master servers recognise each other and can communicate with each other. This is necessary in various contexts, e.g. when managing plugins.
Components of the infrastructure
Module | Description |
Apache Tomcat with formcycle master server 1 | Servlet container that provides formcycle |
Apache Tomcat with formcycle master server 2 | Servlet container that provides formcycle |
DBMS | Database server which provides the formcycle system database |
Mail server | Mail server which enables the mail delivery by formcycle |
Internal third-party systems | Internal third-party systems which are connected by formcycle |
Protocols and ports
Connection | Protocol | Use | Ports |
| formcycle master server → formcycle master server | Socket connection | Cluster connection between the master servers | Standard: 7600 |
A comparison: front-end server vs. reverse proxy
A reverse proxy receives all requests sent to it (Internet) and forwards them to the configured target computer (intranet). The entire load of requests is processed 1:1 by the target computer.
The formcycle frontend server only accepts valid requests and only forwards valid requests to the target computer (formcycle master server). In addition to this initial ‘preselection’, further functions such as authorisation management and caching are available.
Another important point is that communication is not established from the Internet (formcycle frontend server) to the intranet (formcycle master server), but exclusively from the intranet (formcycle master server) to the Internet (formcycle frontend server).
Function overview
Reverse proxy | Frontend server | |
Access to administration interface | Yes | No |
Access to the administrator's mailbox | Yes | Optional |
Access to forms | Yes | Yes |
Technical display authorisation for individual forms | No | Yes |
Extended form cache | No | Yes |
Encrypted connection | Yes | Yes |
Load balancing | No | Yes |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article
