Wiki-Quellcode von Systemarchitektur

Zeige letzte Bearbeiter
1 {{content/}}
2
3 {{formcycle/}} ist einer reine Java-Anwendung und basiert auf einer modularisierten und schichtenorientierten Komponenten-Architektur, die sich mit jedem Java-fähigen Betriebssystem unter einem Anwendungsserver (Tomcat, JBOSS) nutzen lässt. Der Datenbankzugriff basiert vollständig auf der //Java Database Connectivity API// ({{smallcaps}}Jdbc{{/smallcaps}}).
4
5
6
7 == Laufzeitumgebung ==
8 Für den Betrieb von {{formcycle/}} ist Java in mindestens der Version 11 sowie ein entsprechender Servlet-Container (z.B. Tomcat) nötig. Ferner wird für die Daten-Persistenz eine relationale Datenbank benötigt. FORMCYCLE unterstützt hierbei MySQL, MS SQL, PostgreSQL und Oracle.
9
10 == Überblick der Modularisierung ==
11
12 [BILD]
13
14 {{formcycle/}} basiert auf einer hoch-modulare Anwendungs-Architektur welche sich in die folgenden Teile gruppieren lässt:
15
16 === Commons ===
17
18 Innerhalb der Commons Module stehen die in der kompletten Anwendung verwendeten Model- und Entitäts-Klassen zur Verfügung.
19
20 === DAO ===
21
22 Innerhalb der DAO-Module ist die Logik für die Daten-Persistenz gekapselt. Hierbei kommt Hibernate als JPA-Implementierung zum Einsatz und ist für die entsprechenden CRUD-Operationen der einzelnen Entitäten verantwortlich. Die Kommunikation mit der verwendeten Datenbank wird mittels HikariCP und den jeweiligen JDBC-Treibern realisiert.
23
24 === Logik ===
25
26 Innerhalb der einzelnen Logik-Module ist die eigentliche Business-Logik von {{formcycle/}} gekapselt. Die relevantesten Funktionalitäten einzelner Module sind hierbei folgende:
27
28 * Durchführung der Workflow-Verarbeitung (Abarbeiten der konfigurierten Aktionen)
29 * Das Integrieren und Ausführen von installierten Plugins
30 * LDAP-Anbindung an Fremdsysteme (UnboundID LDAP SDK)
31 * Cluster-Kommunikation mehrerer {{formcycle/}}-Server (JGroups)
32 * Das Ausführen zeitgesteuerter Aufgaben (Quartz)
33
34 === Formular-Designer ===
35
36 Die Module des Formular-Designers sind neben dem eigentlichen Design-Prozess auch für das Rendern bestehender Formulare sowie das Validieren von eingegebenen Daten innerhalb eines Formular-Aufrufs verantwortlich.
37
38 === APIs ===
39
40 Basierend auf den Logik- bzw. Formular-Designer-Modulen setzten mehrere Schnittstellen auf welche es ermöglichen die entsprechenden Funktionalitäten zu nutzen. So steht neben einer Java-API basierend auf RPC (SIMON/MINA) auch eine REST-Schnittstelle zur Verfügung. Ebenso lassen sich hierrüber die CRUD-Operationen der DAO-Schicht aufrufen.
41
42 === Verwaltungs-Frontend ===
43
44 Das Frontend zur Verwaltung und Konfiguration von {{formcycle/}} besteht aus mehreren Modulen welche mittels entsprechender Beans (JSF) sowohl DAO, Logik oder auch entsprechende API-Module ansteuert und dem Benutzer die dazu benötigten Web-Oberflächen bereitstellt.
45
46 === Formular-Frontend ===
47
48 Beim Formular-Frontend handelt es sich um Module welche für die Auslieferung und Verarbeitung der Formulare verantwortlich sind. Hierfür wird neben der RPC-API zum Aufruf des eigentlichen Renderns des entsprechenden HTML-Codes (inkl. CSS, JavaScript) auch die REST-API benutzt um weitere Daten oder Dateien innerhalb der Ausführung im Client-Browser bereitzustellen. Ferner werden über die RPC-API auch weitere Funktionalitäten wie z.B. die Benutzer-Authentifizierung oder das Ausführen von Plugins realisiert.
49
50 == Verwendete Technologien/Bibliotheken ==
51
52 Innerhalb von {{formcycle/}} kommen unter anderem folgende Bibliotheken und Technologien zum Einsatz:
53
54 * Java ab Version 8
55 * JSF inkl. Primefaces und Omnifaces
56 * HTML, CSS und JavaScript
57 * Aspose Word, Apache PDFBox, Apache POI
58 * div. Apache Commons Bibliotheken
59 * JPA, Hibernate ORM, HikariCP, JDBC
60 * Liquibase
61 * Hibernate Validator
62 * JavaMail
63 * Log4J über SLF4J
64 * Quartz
65 * EHCache
66 * JGroups
67 * SIMON, MINA
68 * UnboundID LDAP SDK
69 * SimpleXML, fastjson
70 * Xalan XSLT processor
71 * Mozilla Rhino
72
73
74
75 ALT:
76
77 == Systemarchitektur ohne Einsatz eines optionalen Frontend-Servers ==
78
79 {{figure image="systemarchitektur.png" width="300"}}
80 Architektur von {{formcycle case="dat"/}} mit nur einem Master-Server
81 {{/figure}}
82
83 {{table preSort="0-asc" dataTypeAlpha="0" colWidth="200-500"}}
84 |=Modul|=Beschreibung
85 |Frontend|Verwaltungsoberfläche
86 |API (REST)|REST-Schnittstelle zum Abruf verwaltungstechnischer Funktionen. Diese wrd für beispielsweise für die Verwaltungsoberfläche eingesetzt. Diese Schnittstelle kann vom Kunden für die Erweiterung der Verwaltungsfunktionalität beziehungsweise für die Integration in eigene Verwaltungsoberflächen genutzt werden.
87 |API (RPC)|Ermöglicht den Zugriff auf Vorgänge, Status, Aktionsverarbeitungen, Aktionen und vieles mehr.
88 |Logic|Logikebene der Anwendung
89 |Logic (Plugin)|Bereitstellung für Plugins, die zusätzliche Funktionalität bereitstellen.
90 |DAO|Datenzugriffsschicht ({{smallcaps}}Jdbc{{/smallcaps}}-Datenbanken, Dateisystem)
91 |Common|Schichtenübergreifende Funktionalitäten.
92 {{/table}}
93
94 == Systemarchitektur beim Einsatz eines optionalen Frontend-Servers ==
95
96 {{figure image="systemarchitektur2.png" width="300"}}
97 Architektur von {{formcycle case="dat"/}}, wenn sowohl ein Master-Server als auch ein Frontend-Server genutzt wird.
98 {{/figure}}
99
100 Der Einsatz eines [[Frontend-Servers>>doc:Formcycle.SystemSettings.UserInterface.FrontendServer]] ist sinnvoll bei:
101
102 * netzwerkübergreifende Installation (etwa lokales Intranet + DMZ)
103 * Lastverteilung
104 * Regionale Aufteilung (Jeder Mandant hat einen eigenen Frontend-Server mit eigenen Formularen)
105 * Kundenspezifische Erweiterungen (Integration in vorhandene Systemumgebung, eigene Verwaltungsoberflächen)
106
107 {{table dataTypeAlpha="0" preSort="0-asc" colWidth="200-500"}}
108 |=Modul|=Beschreibung
109 |Frontend|Informationen zum Status des Servers, eigene Oberflächen.
110 |API (RPC)|Ermöglicht den Zugriff auf Vorgänge, Status, Aktionsverarbeitungen, Aktionen und vieles mehr.
111 |Common|Schichtenübergreifende Funktionalitäten.
112 |BSV|Bidirektionale Socket-Verbindung zur Kommunikation zwischen Master-Server und Frontend-Server.
113 {{/table}}