Architektonische ansätze | Technologischer blog
02.03.2021
TECHNOLOGISCHE BLOGS AUS DER ANASOFT-UMWELT
Im heutigen Teil des Technologie-Blogs unterhalten wir uns mit Martin Vozár, einem der SW-Designer von ANASOFT. Er verfügt über mehr als 20 Jahre Erfahrung in der Entwicklung kundenspezifischer Anwendungen von kleinen bis zu großen Unternehmenslösungen. Es handelt sich um den distribuierten Ansatz der Anwendungsentwicklung und ihre Besonderheiten.
Wie würdest du einen distribuierten Ansatz der Anwendungsentwicklung den Lesern näher vorstellen?
Jeder, der jemals programmierte, kennt die Bemühung, die ganze Funktionalität in einer Anwendung zu haben. Es ist verständlich. Mit Programmieren beginnt man in kleinen Anwendungen, wo man alles selbst entwickelt und jeder andere Ansatz als eine einzige Anwendung nicht einmal wünschenswert ist. Es würde alles nur komplizieren.
Mit der zunehmenden Komplexität der Lösungen steigt jedoch auch die Anzahl der Entwickler, die daran teilnehmen, sowie die Notwendigkeit oder Gemäßheit, sie unterschiedlich zu implementieren.
Als Beispiel kann ich eine Anwendung nennen, die wir kürzlich für unseren Kunden implementierten. Aufgabe bestand darin, eine riesige Datenmenge von einem großen System zu verarbeiten und sie dann in das System zurückzugeben.
Wie gingt ihr in diesem Fall vor, und warum?
Für eine bessere Vorstellung ist es wichtig zu verstehen, was solch eine Anwendung zu tun hat. Zuerst müssen Daten für die Verarbeitung vom externen System abgerufen werden. Diese müssen in eigene lokale Datenbank gespeichert und Geschäftsprozesse ausgeführt werden. Mit Diesen ist auch die Benutzeroberfläche verknüpft, wodurch das System gesteuert wird. Anschließend müssen die verarbeiteten Daten an das System zurückgegeben werden, von dem sie stammen.
Aufgrund der Anwendungsart werden verschiedene Vorgänge ausgeführt. Integration bzw. Schnittstellenoperationen wie das Hochladen und Abrufen von Daten vom externen System, Backend-Operationen im Zusammenhang mit der lokalen Datenspeicherung und -verarbeitung, sowie Frontend-Operationen der Benutzeroberfläche zur Eingabe von Bedienungsanweisungen und zur Darstellung der Ergebnisse.
Dies erfordert einen distribuierten Ansatz?
Nicht wirklich. In diesem Fall war es aber eine der Optionen und erwies sich als richtig. Natürlich wäre eine technische Lösung möglich, wodurch eine große monolithische Anwendung entwickelt würde. In diesem Fall entschlossen wir uns jedoch, mehrere separate Anwendungen zu erstellen, von denen jede eine ganz bestimmte Rolle spielte. Die einzelnen Anwendungen arbeiteten auf der Grundlage von sog. Signalen zusammen.
Kannst du ein genaueres Beispiel nennen?
Zum Beispiel eine Anwendung, die für die Rückgabe von Daten an das ursprüngliche System verantwortlich ist, überwacht regelmäßig den Inhalt des vereinbarten Verzeichnisses. Wenn sich die Dateien im vereinbarten Format dort befinden, verarbeitet sie und sendet an das ursprüngliche System. Ein solcher Ansatz hat mehrere Vorteile.
Es wäre eine technische Lösung möglich, wodurch eine große monolithische Anwendung entwickelt würde. In diesem Fall entschlossen wir uns jedoch, mehrere separate Anwendungen zu erstellen, von denen jede eine ganz bestimmte Rolle spielte. Die einzelnen Anwendungen arbeiteten auf der Grundlage von sog. Signalen zusammen.
Welche sind die Wichtigsten Vorteile?
Es beginnt mit der Entwicklung selbst. Eine auf diese Weise entworfene Anwendung kann unabhängig vom Rest des Systems implementiert werden. Es kann von einem Entwickler ausgeführt werden, der keine anderen Teile des Systems kennen muss. Er muss lediglich wissen, dass er den Inhalt des Verzeichnisses überwachen, die Daten verarbeiten und an ein externes System übertragen muss. Dies ermöglicht eine parallele Entwicklung über die gesamte Lösung.
Ein weiterer Vorteil ist, dass der Code solcher Lösungen sauber und leicht zu lesen bleibt. Die Dateiverarbeitungsanwendung befasst sich nur mit dem Inhalt. Andere Teile des Systems, andere Anwendungen, Ein- / Aus-Vorgänge und Verbindungen zu umgebenden Systemen sind im Moment für sie uninteressant.
Solcher Ansatz vereinfacht die Wartung des gesamten Systems, sowie die Fehlerbehebung. Wenn die resultierenden Daten beispielsweise nicht an das externe System zurückgehen, ist es logisch nach einem Fehler in der Anwendung zu suchen, die für die Übertragung verantwortlich ist.
Falls das externe System nicht läuft, betrifft dies nur diese eine Anwendung, wobei die anderen Systemteile unabhängig voneinander weiter ausgeführt werden können. Wenn in der Anwendung, die Daten auf externes System hochlädt, ein Fehler gefunden wird, genügt es lediglich den Code dieser Anwendung zu korrigieren, testen und bereitstellen. Andere Teile des Systems, andere Unteranwendungen bleiben unverändert.
Erwähnenswert ist auch eine höhere Parallelität der Entwicklungsarbeit und die Möglichkeit, spezifischeres Fachwissen der Entwickler zu nutzen. Nicht jeder Entwickler passt zu jeder Art von Entwicklungsarbeit gleich gut. Einige sind besser darin, eine Benutzeroberfläche zu erstellen, andere besser in Datenbankoperationen, oder Schnittstellen zwischen verschiedenen Systemen. Die Entwicklung einer großen Anwendung würde bedeuten, dass verschiedene Entwickler gemeinsamen Code verwenden und zumindest eine grundlegende Ausrichtung haben müssen. Auch in Teilen, die nicht mit ihrer Arbeit zusammenhängen. Bei separaten Anwendungen hat jeder seinen eigenen "Spielplatz" und es ist wichtig, nur die Verbindung einzelner Teile der Lösung korrekt einzurichten.
Falls das externe System nicht läuft, betrifft dies nur diese eine Anwendung, wobei die anderen Systemteile unabhängig voneinander weiter ausgeführt werden können. Wenn in der Anwendung, die Daten auf externes System hochlädt, ein Fehler gefunden wird, genügt es lediglich den Code dieser Anwendung zu korrigieren, testen und bereitstellen.
Vielen Dank für das Interview
Das Interview wurde von Boris Rybár
Teammanager für Softwareentwicklung vorbereitet
Hat solch ein distribuierter Ansatz auch Nachteile?
Wie alle Ansätze, hat auch dieser seine Besonderheiten. Ich nenne es bewusst nicht ein Negativum.
Zunächst ist es sehr wichtig, die gesamte Lösung richtig zu gestalten, damit am Ende alles so zusammenarbeitet, wie es soll. Die Vorbereitung dauert also etwas länger, für Lösungen ähnlicher Art wird sie jedoch benötigt.
Es ist auch notwendig, richtige Entwicklungsstandards für alle Anwendungen und auf verschiedenen Ebenen festzulegen. Neben den Namenskonventionen spielt die ordnungsgemäße Protokollierung in einer solchen Architektur eine wichtige Rolle. Obwohl die einzelnen Anwendungen getrennt und auch die von ihnen ausgeführten Aktivitäten protokollieren sind, darf nicht vergessen werden, dass sie eine gemeinsame Aufgabe erfüllen.
Für den Fall, dass der gesamte Prozess irgendwo hängen bleibt, ist es wichtig, effektiv nachverfolgen können, wo das ursprüngliche Problem aufgetreten ist und wie es sich anschließend im gesamten System ausbreitet. Daher ist es wichtig, die Protokollierung so einzurichten, dass sich einzelne Anwendungen nach Möglichkeit an einem gemeinsamen Speicherort anmelden. Und zusätzlich zur Protokollierung der Anwendungsbesonderheiten ein Geschäftsattribut mitprotokollieren, wie z. B. eine systemübergreifende Ereignisnummer.
Wenn wir uns beispielsweise ein distribuiertes System zur Verarbeitung von Rechnungen vorstellen, sollten die einzelnen Teile des Systems unter anderem die Nummer der Rechnung protokollieren, mit der sie den Vorgang ausführen. Auf diese Weise ist es dann möglich, schnell nach dem Fehler im zentralen Protokoll zu suchen und Verbindungen zu erkennen, die sich auf denselben Vorgang (Rechnung) im gesamten System beziehen.
