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 {{figure image="Systemarchitektur_Überblick.png" width="300"}}
13 Überblick der Modularisierung von {{formcycle case="dat"/}}.
14 {{/figure}}
15
16 {{formcycle/}} basiert auf einer hoch-modulare Anwendungs-Architektur welche sich in die folgenden Teile gruppieren lässt:
17
18 === Commons ===
19
20 Innerhalb der Commons Module stehen die in der kompletten Anwendung verwendeten Model- und Entitäts-Klassen zur Verfügung.
21
22 === DAO ===
23
24 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.
25
26 === Logik ===
27
28 Innerhalb der einzelnen Logik-Module ist die eigentliche Business-Logik von {{formcycle/}} gekapselt. Die relevantesten Funktionalitäten einzelner Module sind hierbei folgende:
29
30 * Durchführung der Workflow-Verarbeitung (Abarbeiten der konfigurierten Aktionen)
31 * Das Integrieren und Ausführen von installierten Plugins
32 * LDAP-Anbindung an Fremdsysteme (UnboundID LDAP SDK)
33 * Cluster-Kommunikation mehrerer {{formcycle/}}-Server (JGroups)
34 * Das Ausführen zeitgesteuerter Aufgaben (Quartz)
35
36 === Formular-Designer ===
37
38 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.
39
40 === APIs ===
41
42 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.
43
44 === Verwaltungs-Frontend ===
45
46 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.
47
48 === Formular-Frontend ===
49
50 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.
51
52 == Verwendete Technologien/Bibliotheken ==
53
54 Innerhalb von {{formcycle/}} kommen unter anderem folgende Bibliotheken und Technologien zum Einsatz:
55
56 * Java ab Version 8
57 * JSF inkl. Primefaces und Omnifaces
58 * HTML, CSS und JavaScript
59 * Aspose Word, Apache PDFBox, Apache POI
60 * div. Apache Commons Bibliotheken
61 * JPA, Hibernate ORM, HikariCP, JDBC
62 * Liquibase
63 * Hibernate Validator
64 * JavaMail
65 * Log4J über SLF4J
66 * Quartz
67 * EHCache
68 * JGroups
69 * SIMON, MINA
70 * UnboundID LDAP SDK
71 * SimpleXML, fastjson
72 * Xalan XSLT processor
73 * Mozilla Rhino
74
75
76
77 ALT:
78
79 == Systemarchitektur ohne Einsatz eines optionalen Frontend-Servers ==
80
81 {{figure image="systemarchitektur.png" width="300"}}
82 Architektur von {{formcycle case="dat"/}} mit nur einem Master-Server
83 {{/figure}}
84
85 {{table preSort="0-asc" dataTypeAlpha="0" colWidth="200-500"}}
86 |=Modul|=Beschreibung
87 |Frontend|Verwaltungsoberfläche
88 |API (REST)|REST-Schnittstelle zum Abruf verwaltungstechnischer Funktionen. Diese wird 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.
89 |API (RPC)|Ermöglicht den Zugriff auf Vorgänge, Status, Aktionsverarbeitungen, Aktionen und vieles mehr.
90 |Logic|Logikebene der Anwendung
91 |Logic (Plugin)|Bereitstellung für Plugins, die zusätzliche Funktionalität bereitstellen.
92 |DAO|Datenzugriffsschicht ({{smallcaps}}Jdbc{{/smallcaps}}-Datenbanken, Dateisystem)
93 |Common|Schichtenübergreifende Funktionalitäten.
94 {{/table}}
95
96 == Systemarchitektur beim Einsatz eines optionalen Frontend-Servers ==
97
98 {{figure image="systemarchitektur2.png" width="300"}}
99 Architektur von {{formcycle case="dat"/}}, wenn sowohl ein Master-Server als auch ein Frontend-Server genutzt wird.
100 {{/figure}}
101
102 Der Einsatz eines [[Frontend-Servers>>doc:Formcycle.SystemSettings.UserInterface.FrontendServer]] ist sinnvoll bei:
103
104 * Netzwerkübergreifende Installation (etwa lokales Intranet + DMZ)
105 * Lastverteilung
106 * Regionale Aufteilung (Jeder Mandant hat einen eigenen Frontend-Server mit eigenen Formularen)
107 * Kundenspezifische Erweiterungen (Integration in vorhandene Systemumgebung, eigene Verwaltungsoberflächen)
108
109 {{table dataTypeAlpha="0" preSort="0-asc" colWidth="200-500"}}
110 |=Modul|=Beschreibung
111 |Frontend|Informationen zum Status des Servers, eigene Oberflächen.
112 |API (RPC)|Ermöglicht den Zugriff auf Vorgänge, Status, Aktionsverarbeitungen, Aktionen und vieles mehr.
113 |Common|Schichtenübergreifende Funktionalitäten.
114 |BSV|Bidirektionale Socket-Verbindung zur Kommunikation zwischen Master-Server und Frontend-Server.
115 {{/table}}