Features

QOREO implementiert eine modellierbare, mehrschichtige Architektur innerhalb von mindestens vier streng gebundenen Schichten. Diese Schichten ordnen sich ein zwischen den wählbaren Client/Server-Technologien auf der Präsentationsseite (Rich, Web, Mobile, QOREO Server) und der jeweiligen Datenzugriffschicht auf der anderen Seite (ADO.net, Webservice Proxies, Client Stubs Libraries, Files usw.). Die vier Schichten sind

• Presentation Layer (Client) / Service Layer (Server)
• Application Layer (Client) / Business Process Layer (Server)
• Business Entity Layer
• Data Abstraction Layer

Vertikal und schichtenübergreifend befindet sich der für Authentifizierung, Berechtigung und Benutzerrollen zuständige

• User Context Layer.

Jede Schicht erfüllt zusätzlich besondere Anforderungen:

• Presentation Layer: Performance, Asynchronität, Nutzerakzeptanz
• Application Layer: Sicherheit, Portabilität
• Business Layer: Portabilität, Skalierbarkeit, Datenintegration, Isolation von Custom Code
• Data Abstraction Layer: Best Performance pro Datenquellenart, Datenkonsistenz, Virtualisierung
• User Context Layer: Sicherheit, Performance, minimaler Administrationsaufwand

Für jede der Schichten existiert eine Konfiguration innerhalb eines verschlüsselten Repositories, welches alle konfigurierbaren Eigenschaften einer oder mehrerer QOREO-Anwendungen enthält. Diese Eigenschaften bestehen im Wesentlichen aus Meta-Daten, aber auch aus verwalteten Code-Komponenten, die gezielt einzelne Funktionen (zumeist Business Logik) der QOREO-Codebasis erweitern oder ersetzen.

Die Verwaltung des Repositories und die Unterstützung des gesamten Projektzyklus wird durch ein Entwicklerwerkzeug realisiert. Diese Software ist selbst bereits eine QOREO-Anwendung ("dogfood"), ist vollständig mit Microsoft Team Foundation Server integriert und besitzt neben den Modell-Editoren u.a. Assistenten zum Im-/Export von Datenbank-Schemas, die Erstellung von Source-Code-Gerüsten für Business-Logik, Verwaltung von Kunden und Projekten, Releases, Versionen, die Verwaltung und Ausführung verschiedener Deploymentarten, Bearbeitung von Stilen und Layouts von UI-Elementen, u.v.m.

Architektur

Projektzyklus (vereinfacht)

Ein einheitliches relationales Meta-Datenmodell, über verschiedenste Datenquellen hinweg, isoliert die Business-Logik von der Datenbereitstellung aus Datenquellen wie z.B.:

• Datenbanken (MSSQL, Oracle, DB2, SQLite, SqlCE, TinySQL, Pervasive…)
• Webservices (REST-API z.B. HPQC oder NAV, serviceorientierte Architekturen, Qoreo Server…)
• Objektbibliotheken (OTA, VMWare Virtual Center, Active Directory…)

Die Möglichkeit, “Joins” und “fachliche Constraints” zwischen beliebigen Entitäten auf der Ebene der Geschäftslogik zu modellieren, ermöglicht die vollständige Beschreibung der inhaltlichen Zusammenhänge des gesamten Informationsumfangs über Datenquellen hinweg und unabhängig von deren Art.

Es werden so unter anderem sehr fortgeschrittene Funktionen bereitgestellt, die üblicherweise nur sehr aufwändig oder gar nicht realisiert werden können:

• Live-Integration verschiedener Datenquellen und Datenquellenarten, auch nach Publish/Subscribe-Prinzip
• globale Transaktionen über Datenquellen hinweg
• Sicherungsmechanismen für die Datenkonsistenz über mehrere Datenquellen hinweg
• UNDO und Änderungsprotokollierung, transaktionssicher über Datenquellen hinweg
• Cut/Copy & Paste ganzer Hierarchien von über Datenbankgrenzen hinweg verknüpfter Informationen
• konsistenter Im-/Export/Merge un-/strukturierter externer Daten (Excel, CSV...) mit u.a. automatischer Zuordnung von Verknüpfungen
• physikalische Einheiten und Dimensionen für numerische Eigenschaften zur variablen Darstellung und automatisch korrekten Speicherung und Konvertierung von Werten
• Berechtigungen für Lesen, Ändern, Einfügen, Löschen von Daten
• Vererbung von Business Entities und wahlweisen Eigenschaften
• datenquellenunabhängige und portable Geschäftslogik im Business-Entity-Modell, deren Implementierung konsistent allen Verwendern von Daten, wie Benutzeroberflächen, technischen Prozessen und Auswertungen zur Verfügung steht
• Verschiedene PK-Generierungsarten, Nutzung von Stored Functions und Procedures und vieles mehr...

Der vorimplementierte Business-Layer kann mit beliebiger Granularität durch Custom Business Logic ergänzt und erweitert werden. Die Gesamtarchitektur stellt sicher, dass diese Implementierungen wahlweise in einer Client- oder einer Serverumgebung lauffähig sind. Sie erfüllt somit die Anforderung nach Skalierbarkeit und Nachhaltigkeit in einzigartiger Weise. Nicht nur das Wachstum einer Anwendung in der Zukunft, sondern auch Wechsel und Modernisierungen der verwendeten Datenbanksysteme und Client-Technologien werden um ein Vielfaches kostengünstiger.

Meta-Datenmodell

Praxisbeispiel: Datenintegration

Dem Application Layer liegt die Erkenntnis zugrunde, dass eine Softwareanwendung einen hierarchischen Aufbau hat. Ausgehend von Suchergebnissen, Menüpunkten und Selektionen, bewegt sich ein Benutzer über vorgesehene Pfade zu den gewünschten Informationen. Er navigiert dabei über die Datenlandschaft hinweg und bildet Sichten auf die Daten aus, die im Kontext des bereits gegangenen Weges stehen.

Gleiches gilt auch für Prozessmodelle, die anstelle von Benutzerinteraktionen über Regeln verfügen, die aufgrund von Ereignissen vorgegebene Funktionen realisieren.

Die modellierbare Anwendungsarchitektur in QOREO verknüpft die Daten und Funktionen des Business Layers mit Workflows, Berechtigungen und Ansichten des Presentation Layers. Sie ist portabel und ermöglicht den gleichzeitigen Einsatz mehrerer Frontend-Technologien. Innerhalb eines Repositories können mehrere Anwendungen für den selben Business Layer existieren und ein einheitliches Rollenkonzept verwenden.

Die Präsentationsschicht einer benutzerbedienbaren (Client-/Web-) Anwendung bildet die Schnittstelle zwischen dem Bediener und dem Application Layer. Sie präsentiert Daten und Funktionen in der durch die gewählte Client-Technologie vorgegebenen Art und Weise (plattformabhängig) und gleichzeitig nach den Regeln und Möglichkeiten des Application Layers (portabel). Gleiches gilt für Serveranwendungen, die analog dazu, aber innerhalb des Service Layers eine technische Schnittstelle bedienen, die zusätzlich wiederum portabel ist.

Die Implementierung des Presentation Layers für eine neue Plattform ist aufgrund des hohen gegebenen Abstraktionsgrades der darzustellenden Inhalte in sehr kurzer Zeit möglich, solange eine Implementierung mittels Dotnet vorgenommen werden kann. Das ist, neben Windows.Forms Anwendungen, aktuell für viele Web-Technologien und auch für Mobilplattformen wie iOS, Android und Windows Phone gegeben.

Die Qualität der Präsentationsschicht einer Softwareanwendung ist mit entscheidend für die Akzeptanz der Software. Da Benutzerakzeptanz aus unserer Sicht wiederum zu den entscheidenden Erfolgskriterien eines Softwareprojekts gehört, haben wir sehr auf das Erscheinungsbild und die Funktionalität der UI-Elemente geachtet.

Praxisbeispiel

Benutzer werden beim Start einer QOREO-Anwendung einer Benutzerrolle zugeordnet. Das gilt für technische Prozesse ebenso wie für natürliche Benutzer. Die resultierende Rollenzugehörigkeit eines Benutzers steuert seine Rechte innerhalb der Anwendung. Die Arten von Rechten sind vielfältig und betreffen Erlaubnisse oder Verbote hinsichtlich des Datenzugriffs, der Navigation innerhalb der Anwendung oder z.B. die Erlaubnis zum Kopieren von Daten aus Ansichten.

Die Zuordnung eines Benutzers zu seiner Anwendungsrolle geschieht über eines oder mehrere der folgenden Verfahren in Kombination:

• native Anmeldung mit Name und Passwort innerhalb der Anwendung
• integrierte Anmeldung nach positiver Zuordnung von Eigenschaften des konfigurierten QOREO-Benutzers zum System-Account
• integrierte Anmeldung nach Zuordnung der QOREO-Gruppe eines konfigurierten QOREO-Benutzers zu Gruppenmitgliedschaften des System-Accounts
• intergrierte dynamische Anmeldung nach positiver Zuordnung einer dynamischen QOREO-Gruppe (ohne vorkonfigurierte Benutzer) zu Gruppenmitgliedschaften des System-Accounts
• integrierte Anmeldung nach Zuordnung der QOREO-Gruppe eines konfigurierten oder dynamischen QOREO-Benutzers zu Gruppenmitgliedschaften innerhalb einer Domäne (Active Directory).

Die Auswahl der anzuwendenden QOREO-Gruppe bzw. des gegebenenfalls vorkonfigurierten QOREO-Benutzers erfolgt durch eine Prüfung aller an ihnen vorgegebenen System-Benutzereigenschaften,von der strengsten Vorgabe hin zur losesten Interpretation. Die erste QOREO-Gruppe, deren Kriterien vollständig erfüllt sind, wird die Gruppe und damit Anwendungsrolle des Benutzers.

Das geeignetste und empfohlene Verfahren zur Administration einer QOREO-Anwendung ist die Steuerung der Rollenzugehörigkeit über AD-Sicherheitsgruppen. Der Anwendungsarchitekt erstellt hierbei die Anwendungsgruppe innerhalb des QOREO-Repositories und ordnet diese einer oder mehreren AD-Sicherheitsgruppen zu. Der Adminsitrator der Systemumgebung, ordnet diesen Sicherheitsgruppen die entsprechenden Benutzer zu und administriert so die Anwendungsberechtigungen ohne seine gewohnte Administrationsumgebung zu verlassen oder gar mehrere Administrationsschritte machen zu müssen.

Die Benutzer- und Rolleneigenschaften steuern neben den vielfältigen Berechtigungen auf Navigation und Daten, zusätzlich das Vorhandensein eines Benutzerprofils zur Ablage des letzten Anwendungszustands. Benutzer denen ein Profil gestattet ist, finden die Anwendung nach dem Neustart wieder so vor wie sie sie verlassen hatten.

Die Wirkung der Berechtigungseinstellungen einer QOREO-Gruppe kann entweder "inklusiv" oder "exklusiv" konfiguriert werden, d.h. entweder müssen Rechte explizit vergeben werden da per-se alles verboten ist oder Verbote müssen explizit erteilt werden um eine generelle Erlaubnis zu widerrufen. Für jede Berechtigungsbeziehung einer Gruppe und Anwendungszuordnung kann eines der Verfahren jeweils neu gewählt werden. In der Regel müssen somit nur sehr wenige Einstellungen vorgenommen werden.