Anwendungsmodell (Avalanche - Anwendungsframework für Java)

"Avalanche - Application Framework für Java" - Implementierung der Technologie der Unschärfe Unterschiede
zwischen Aufrufen von lokaler und entfernter Vorwahl. Fehlertoleranz, Skalierbarkeit,
Modifizierbarkeit und ständige Verfügbarkeit werden mit attraktiven Boni gebündelt.

Das in diesem Artikel berücksichtigte Anwendungsmodell basiert auf unseren eigenen Erfahrungen bei der Implementierung und dem Betrieb verschiedener Integrationsinteraktionen von Informationssystemen (IS) und zielte in erster Linie darauf ab, den Einsatz verschiedener Ressourcen (finanziell, arbeitsintensiv, zeitlich usw.) bei der Implementierung dieser Integrationslösungen zu reduzieren.

Die meisten Unternehmen betreiben viele verschiedene Systeme, die einzelne Prozesse oder die Arbeit einzelner Struktureinheiten oder Abteilungen automatisieren. Infolgedessen muss der Informationsaustausch zwischen diesen Systemen oder mit den Informationssystemen verwandter Organisationen organisiert werden, um die Betriebskosten zu senken, die Einführung doppelter Daten und Dateninkonsistenzen in verschiedenen Systemen (z. B. NSI) zu vermeiden, den Einfluss des menschlichen Faktors zu verringern und den Zeitaufwand für den Informationsaustausch zu verringern.

Der Integrationsbedarf entsteht nicht nur in Spezialsoftware aus eigener oder kundenspezifischer Entwicklung, sondern auch in „Boxed“ -Lösungen. Die Umsatzkosten können die erwartete Reduzierung der Betriebskosten übersteigen.

Bestehende Möglichkeiten zur Integration von IT-Systemen:

• Dateifreigabe
• Messaging (eine Art der Dateifreigabe)
• Integration auf Datenmodellebene, z. B. Erstellung spezieller Datenbankobjekte oder gespeicherter Prozeduren
• Verwenden von RCP-Technologien (Remote Call Procedure), z. B. CORBA, RMI, SOAP, DCOM usw.

Alle diese Methoden zur Implementierung von Integrationslösungen weisen die gleichen Nachteile auf: Komplexität der Implementierung und Änderung, geringe Wiederholbarkeit, Notwendigkeit der Behebung von Fehlertoleranzproblemen, Unfähigkeit, während der Installation von Änderungen in einem Modus mit mehreren Versionen zu arbeiten, Komplexität des Betriebs und Aktualisierung der Betriebsdokumentation.

Als Ergebnis der Suche nach einer Alternative zu bestehenden Lösungen wurde die Idee formuliert, das MVC-Modell (MODEL-VIEW-CONTROLLER) in das MVFA-Modell (MODEL-VIEW-FUNCTION-APPLICATION) umzuwandeln, wobei CONTROLLER in zwei Programmebenen FUNCTION und APPLICATION aufgeteilt wurde, zwischen denen ein Datenübertragungsnetz (SPD) platziert werden kann )



Die Aufteilung in Funktionen innerhalb der Steuerung ist in allen modernen IT-Systemen zum einen oder anderen Grad vorhanden, insbesondere wenn die Entwicklung mit objektorientierten Programmiersprachen erfolgt. Und die Trennung dieser Funktionen in einer separaten Softwareschicht löst das Problem der Wiederverwendung durch andere IT-Systeme.

Das Trennen von "Anwendungs" -Objekten in eine separate Programmschicht standardisiert den Aufruf nicht nur auf seine eigenen Funktionen, sondern auch auf die Funktionen anderer Systeme, wodurch alle Unterschiede bei den Aufrufen von "eigenen" und "fremden" Funktionen beseitigt werden.

Zur Implementierung des MVFA-Modells wird das folgende Softwaremodell vorgeschlagen:

1. Function (Function), ein beliebiges Objekt, das Methoden zum Implementieren einer beliebigen Funktionalität enthält;
2. Ein Adapter, ein deklariertes Objekt ohne Implementierung. Dieses Objekt stellt die Verbindung der "Anwendungs" -Objekte mit lokalen oder Remote-Funktionen her. Für den Zugriff auf Remote-Funktionen wird das Objekt „interface“ verwendet.
3. Connector (Connector), ermöglicht den Zugriff auf die lokalen Funktionen von Remote-Objekten mithilfe von Objekten "Veröffentlichung";
4. Publication (Publish), veröffentlicht eine lokale Funktion im Connector.
5. Schnittstelle (Interface), ermöglicht den Zugriff auf Adapter für Remote-Funktionen;
6. Anwendung (Application), führt die Konvertierung von Daten zwischen der Präsentation und der Funktion / Funktionen durch, kann auch als "Funktion" für andere Objekte der "Anwendung" fungieren.

Ein Paar "Schnittstelle" - "Konnektor" bildet einen Datenkanal über ein Protokoll zwischen verschiedenen Systemen oder verschiedenen Knoten desselben Systems. Ein implementierter Kanal muss in der Lage sein, die erforderlichen Datenmengen weiterzuleiten.

Es gibt spezielle Implementierungen von „Schnittstellen“, bei denen keine „Konnektor“ -Elemente gepaart sind, z. B. eine Hochverfügbarkeitsschnittstelle, mit der Sie fehlertolerante Informationssysteme erstellen können. Der Hauptzweck der Hochverfügbarkeitsschnittstelle besteht darin, die Last bei der Planung oder außerhalb des geplanten Herunterfahrens eines der Systemknoten auf doppelte Knoten umzuleiten.

Das betrachtete MVFA-Modell ist in das Avalanche - Application Framework für Java-Softwareprodukt implementiert, das zur Kategorie Middleware gehört und zum Erstellen von Software-Clustern oder fehlertoleranten hochverfügbaren Informationssystemen dient.

Natürlich hat Avalanche - Application Framework für Java, wie jede Technologie, einige Einschränkungen:

1. Alle in den Adaptern deklarierten Objekte (Typen) (Eingabe- und Rückgabeparameter) können über das Netzwerk übertragen werden. Daher müssen diese Objekte die Schnittstelle java.lang.Serializable implementieren. Lokale Objekte werden direkt aufgerufen, ohne Lese- und Schreibvorgänge für den Stream zu verwenden.
2. Nicht alle Objekte können über das Netzwerk übertragen werden. Beispielsweise Objekte, deren Status oder Leistung von der Konfiguration des Systemknotens abhängt, auf dem sie erstellt wurden. Zu diesen Objekten gehören Objekte, die die Spezifikation javax.sql.DataSource implementieren.
3. Doppelte Systemknoten müssen sich auf unterschiedlicher Hardware befinden.
4. Doppelte Systemknoten sollten nicht gleichzeitig ausgeschaltet (gewartet) werden.

Ein Beispiel für eine einfache Anwendung finden Sie im Artikel - Erste Anwendung (Avalanche - Application Framework für Java).