DE60031088T2

DE60031088T2 - Verfahren und Gerät zur Bereitstellung von Daten für einen Benutzer

Info

Publication number: DE60031088T2
Application number: DE60031088T
Authority: DE
Inventors: Hardy Schloer
Original assignee: RavenPack AG
Current assignee: CAPFLOW GMBH, 81925 MUENCHEN, DE
Priority date: 1999-12-24
Filing date: 2000-07-12
Publication date: 2007-05-16
Anticipated expiration: 2020-07-13
Also published as: DE60031088D1; EP1126674A2; ATE341886T1; EP1126674A3; EP1126674B1

Description

Die vorliegende Erfindung betrifft ein Verfahren und ein Gerät zur Darstellung und Lieferung von Daten für bzw. an einen Anwender bzw. Benutzer (im Folgenden "User") eines Netzwerks. Ein Beispiel eines solchen Netzwerks ist das so genannte Internet oder das World Wide Web und das Verfahren der Erfindung ist in Server, die mit dem Netzwerk verbunden sind, implementiert. Gemäß einem anderen Aspekt betrifft die vorliegende Erfindung ein Verfahren zum Speichern von Datenelementen in einer Datenbank und in eine dazugehörige Datenbank.
In dem herkömmlichen Verfahren zur Darstellung und Lieferung von Daten im Internet wird eine Anordnung verwendet, die schematisch in 2a und 2b gezeigt wird. Wie in 2a gezeigt, richtet ein User mit Hilfe entsprechender und passender Protokolle in einem Server 3 eine Verbindung zu einer Applikation 1 ein, wobei diese Applikation 1 Zugriff auf eine Datenbank 2 hat. Die Daten werden gemäß Seiten dargestellt, wobei einzelne Seiten über so genannte Links miteinander verbunden sind. Diese Seiten werden an den User geliefert und durch Treffen einer Auswahl auf den gezeigten Seiten kann er direkt oder indirekt einen Link so bestimmen, dass die Auswahl eines speziellen Links von einer Seite zu einer anderen führt. Auf diese Weise kann sich der User durch die Daten in der Datenbank 2 bewegen.
Mit anderen Worten, die darzustellenden oder zu liefernden Daten bilden eine Hierarchie, die über Verbindungen untereinander verbunden ist. Diese Art von Datendarstellung ist wohl bekannt und bedarf deshalb keiner weiteren Erklärung.
Ein Nachteil dieses Konzepts ist, dass der User keinen Einfluss auf die vorbestimmte Datenstruktur hat und gezwungen ist, sich entlang der vorbestimmten Pfade (Links) zu bewegen. Dies kann für den User sehr frustrierend sein, wenn er nicht in der Lage ist, das zu finden wonach er sucht oder zumindest einer hohen Anzahl von Links folgen muss, bis er das findet, was er sucht.
Ein weiterer Nachteil dieses Konzepts ist, dass es ein hohes Sicherheitsrisiko mit sich bringt. Ein böswilliger User kann die durch die Seitenhierarchie offenkundig gemachte Anordnung analysieren und dadurch Information über die Anordnung der Datenbank 2 erlangen. Mit dieser Information und durch Ausnutzen des Zugangs der Applikation 1 zu der Datenbank 2 kann ein solcher böswilliger User das System "zurückverfolgen", um Zugang zu der Datenbank zu erlangen und darin befindliche sensible Daten zu betrachten bzw. zu prüfen oder zu manipulieren. Auf diese Weise ist es z.B. möglich, einen Web-Server oder eine Website zu "entführen" und die Inhalte und die Darstellung gegen den Willen des Server-Bedieners zu verändern. Deshalb wirft das vorstehend beschriebene Konzept ernsthafte Sicherheitsprobleme auf.
Aus dem Artikel "Drop-in publishing with World Wide Web" von J. Davis et al, Computer Networks and ISDN Systems 28 (1995) 247–255, XP004001231, ist bekannt, ein Dokumentenveröffentlichungssystem im Internet vorzusehen, das ein spezielles, "Dienst" genanntes Protokoll zum Finden bzw. Ermitteln und Analysieren von Dokumenten verwendet. Jedes Dokument in dem "Dienst" weist einen einzigartigen, DocID genannten Identifikator auf. Die DocID weist drei Komponenten auf: eine Namenskonvention, einen Herausgeber und eine Nummer. Um sicherzustellen, dass jede DocID einzigartig ist, garantiert jede Komponente, dass die nächste Komponente einzigartig ist.
Eine Aufgabe der vorliegenden Erfindung ist es, ein verbessertes Konzept der Darstellung und Lieferung von Daten für bzw. an einen User über ein Netzwerk, das unter anderem die Sicherheit verbessert.
Diese Aufgabe wird durch den Gegenstand der eigenständigen Ansprüche gelöst. Vorteilhafte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.
Gemäß der vorliegenden Erfindung fügt der Prozess des Lieferns von Daten an einen User einen unidirektionalen oder Einweg-Pfad in den Datenfluss derart ein, dass kein Zurückverfolgen möglich ist. Dies macht einen unerlaubten Zugang zu Daten unmöglich.
Es kann angemerkt werden, dass der Begriff "User" im Kontext der vorliegenden Erfindung nicht auf einen menschlichen Anwender beschränkt ist, sondern sich auf jede Einheit bezieht, die Daten geliefert zu bekommen sucht, wie ein anderer Computer. Deshalb dehnt sich der Begriff "User" auf jeden Datenempfänger aus.
Gemäß einer bevorzugten Ausführungsform umfasst das erfindungsgemäße System: Errichten eines Links mit dem User über ein Kommunikationsmodul, Empfangen einer den User identifizierenden Identifikation, Übermitteln der Identifikation an ein Eingabemodul, das so ausgelegt ist, dass es nur Daten aus dem Kommunikationsmodul empfangen kann, aber die Daten nicht an das Kommunikationsmodul senden kann, Übermitteln der Identifikation und/oder der durch Verarbeiten der Identifikation abgeleiteten Daten an ein Datenauswahlmodul, wobei das Datenauswahlmodul so ausgelegt ist, dass es nur Daten aus dem Eingabemodul empfangen kann, aber die Daten nicht an das Eingabemodul senden kann, dass es auf der Grundlage der von dem Eingabemodul empfangenen Information auf die Datenspeichervorrichtung zugreifen kann und dass es bestimmen kann, welche Daten in der Datenspeichervorrichtung für den User dargestellt werden sollen.
Über den Sicherheitseffekt hinaus hat die bevorzugte Ausführungsform den zusätzlichen Vorteil, dass die Auswahl von Daten gemäß einer den User identifizierenden Identifikation durchgeführt werden kann, was eine Lieferung oder Darstellung einer individuellen Auswahl von Daten an bzw. für den User gestattet, vorzugsweise in Form einer einzelnen Seite, die sich gemäß der Auswahl des Users verändert, aber die keine durch den Programmierer des Datenservers vorbestimmte Link-Hierarchie darstellt. Mit anderen Worten, die bevorzugte Ausführungsform gestattet das Beseitigen der Link-Hierarchie und schafft die Möglichkeit des Sendens von Daten auf einer einzelnen Seite, was ein System etabliert, das auch als "Einseiten-Web (One-Page-Web") bezeichnet werden kann.
Gemäß einer anderen bevorzugten Ausführungsform, die auch die vorstehend beschriebene Ausführungsform umfassen kann, weist der Datenserver zur Bereitstellung von Daten für einen User eine Drei-Tier-Software-Architektur auf, wobei ein erster Tier mindestens eine darzustellende Daten enthaltende Datenbank umfasst, ein zweiter Tier ein oder mehrere Module zum Implementieren von Applikationslogik für das Verarbeiten von Daten und für den Zugang zu der Datenbank in dem ersten Tier umfasst, und ein dritter Tier ein oder mehrere Module für die externe Kommunikation und das Verarbeiten von Daten für die Anzeige umfasst. Mit anderen Worten, der erste Tier wird dem Speichern von Daten gewidmet, der zweite Tier wird dem Zugriff auf die Datenbank gemäß den Logikimplementierungen gewidmet und der dritte Tier wird der Behandlung der Kommunikation mit einem externen Netzwerk gewidmet, was typischerweise den Empfang und die Behandlung von Anforderungen von dem Netzwerk und das Senden von Antworten zurück in das Netzwerk umfasst.
Diese Architektur, die in der vorstehend beschriebenen Weise Funktionen trennt, bietet viele Vorteile, insbesondere den der Flexibilität. Es ist nämlich möglich, die Module oder Funktionseinheiten in jedem der drei Tier unabhängig voneinander so zu konzipieren, dass eine kundenspezifische Anpassung auf einfache Weise durch Zusammenfügen der einzelnen Komponenten auf eine gewünschte Art und Weise erreicht werden kann.
Der zweite Tier kann unter Verwendung einer Architektur, die austauschbare Elemente, wie Plugins, aufweist, selbst auf eine solche flexible Weise ausgelegt werden. Des Weiteren kann der dritte Tier eine Mehrzahl von Kommunikationsmodulen enthalten, zum Beispiel ein Modul zum Einrichten von Internet-Verbindungen, ein Modul zum Einrichten vom Verbindungen zu einem halbintelligenten TV-System, ein Modul zum einrichten einer Verbindung zu einem SMS-Netzwerk etc., wobei dann all diese verschiedenen Netzwerke durch Verwendung der gleichen Funktionselemente in dem zweiten Tier, die diesen externen Netzwerken gemein sind, auf die gleichen Daten zugreifen können (in dem ersten Tier). Auf diese Weise ist es z.B. möglich, in dem zweiten Tier eine Logik zu implementieren, die Aktionen von einem Netzwerk für die Erzeugung von Aktionen in anderen Netzwerken berücksichtigt.
Gemäß einer anderen bevorzugten Ausführungsform, die mit den vorstehend beschriebenen Ausführungsformen kombiniert werden kann oder auch allein verwirklicht werden kann, werden die in der Datenbank befindlichen Datenelemente auf eine derartige Weise gespeichert, dass jedes einzelne Datenelement (ein Text, ein Bild, ein Film, ein Musikstück, etc.) einer einzigartigen Seriennummer zugeordnet wird, wobei jede Seriennummer ein vorbestimmtes Format hat und das Format jede Seriennummer in definierte Segmente teilt, wobei jedes Segment mit der Dateneinheit zusammenhängende Information codiert. Vorzugsweise codieren die Segmente Kategorien und Attribute betreffende Information.
Durch Wahl einer Seriennummer von ausreichender Länge, vorzugsweise mindestens 128 Stellen, noch besser mindestens 256 Stellen, ist es möglich, eine große Tiefe beim Klassifizieren und Beschreiben der Datenelemente mit den Seriennummern zu erzielen, wobei in der Tat die Anzahl von Segmenten (z.B. 14) einen Raum etabliert, der eine entsprechende Anzahl von Dimensionen aufweist (z.B. 14), wobei der Wert in jedem Segment genau die Dateneinheit entlang der dem Segment zugeordneten Dimension derart festlegt, dass in der Tat jede Dateneinheit dann einem Punkt in dem mehrdimensionalen Raum entspricht.
Auf Grund der Speicherung der Datenelemente auf die vorstehend beschriebene Weise ist es möglich, nach einer Dateneinheit ausschließlich auf der Grundlage ihrer Kategorie und/oder ihres Attributs zu suchen, ohne in der Lage sein zu müssen, die Dateneinheit selbst zu beschreiben. Mit Bezug auf den vorstehend beschriebenen mehrdimensionalen Raum entspricht die Anzeige einer Mehrzahl von Kategorien und/oder Attributen Schnittpunkten in dem mehrdimensionalen Raum.
Gemäß einer bevorzugten Ausführungsform einer solchen Datenbank, die in Zusammenhang mit der vorstehend beschriebenen zweiten, die Drei-Tier-Software-Anordnung aufweisenden Ausführungsform zu verwenden ist, sind die Datenelemente in der Datenbank nicht irgendwelchen Abfragelogikfunktionen zugeordnet, wie dies in Datenbanksystemen gemäß dem Stand der Technik der Fall ist, weil diese Funktionsweisen in dem zweiten Tier implementiert werden. Dies schafft abermals den Vorteil einer erhöhten Flexibilität und spart Ressourcen, da eine einzelne Datenbank für eine Vielzahl unterschiedlicher Tasks verwendet werden kann.
Die vorliegende Erfindung wird nun auf der Grundlage detaillierter Ausführungsformen, die ein besseres Verständnis der Erfindung vermitteln, aber in keiner Weise den Rahmen der Erfindung beschränken sollen, wobei die Ausführungsformen auf die beigefügten Zeichnungen Bezug nehmen. Es zeigen bzw. illustrieren:
1 eine Strukturskizze einer Ausführungsform der vorliegenden Erfindung;
2 schematisch die Anordnung eines herkömmlichen Systems zur Bereitstellung von Daten für einen User über das Internet;
3 eine Strukturskizze einer anderen Ausführungsform der Erfindung;
4 ein ausführliches Beispiel der Ausführungsform von 4;
5 eine Inhaltsinformationstabelle, eine Inhaltstabelle und eine in dem Datenmodell der vorliegenden Erfindung verwendete Ansichtentabelle;
6 ein Inhaltshauptverzeichnis, der zu dem Datenmodell der vorliegenden Erfindung gehört;
7 ein Beispiel der einer Seriennummer des Datenmodells der vorliegenden Erfindung zugeordneten Beschreibung;
8 ein Beispiel von Reihungswerttabellen, die zu dem Datenmodellen der vorliegenden Erfindung gehören;
9 Reihungswerttabellen-Eigenschaften;
10 ein Beispiel einer User-Tabelle, die zu dem User-Modell der vorliegenden Erfindung gehört;
11 ein Beispiel einer User-Session-Tabelle, die zu einem User-Modell der vorliegenden Erfindung gehört;
12 Beispiele einer Anzahl weiterer Tabellen, die in Verbindung mit der User-Tabelle von 10 zu dem User-Modell der vorliegenden Erfindung gehören;
13 die Rolle der Anziehungskraft-Abbildungs-Tabelle als einem Mittel ("Agent") zum Aufzeichnen des Interaktionsgrades eines bestimmten Users mit einer bestimmten Dateneinheit;
14 eine Einzelheit aus 13;
15 die Umfeldabbildungs-Tabelle zusammen mit der User-Tabelle;
16 die Produktetabelle zusammen mit der Inhaltsinformationstabelle;
17 ein Beispiel des Geschäftsbetriebssystems;
18 Einzelheiten des Geschäftsbetriebssystems ("business operating system (BOS)") schematisch;
19 schematisch Einzelheiten des zentralen Entscheidungsmoduls ("central decision module (CDM)") in dem Geschäftsbetriebssystem;
20 ein UML-Diagramm der Gate-Hierarchie in einer Ausführungsform eines BOS;
21 Einzelheiten der BOS-Registrierungsberechtigung;
22 ein UML-Diagramm einer Session-Manager-Hierarchie;
23 ein UML-Diagramm einer Kanalhierarchie;
24 ein UML-Diagramm einer Mittel-Hierarchie;
25 eine Übersicht des Web-Betriebssystems ("web operating system ("w³OS")");
26 ein Beispiel eines Web-Servers für das Interagieren mit dem in 25 illustrierten Web-Betriebssystem;
27 eine schematische Übersicht einer Ausführungsform der vorliegenden Erfindung, eine Illustration des Konzepts des Einrichtens einer unidirektionalen Datenflusses enthaltend;
28 eine Web-Sicherheitsschnittstelle hinsichtlich objektorientierter Elemente;
29 ein auf das Seitenerstellungselement bezogenes Klassendiagramm;
30 ein Beispiel einer dem visuellen Inhaltsmanager ("visual content manager (VCM)") zugeordneten grafischen User-Schnittstelle ("Graphical User Interface (GUI)");
31 ein Screenshot-Beispiel einer Toolbox für einen VCM-Pane von 30;
32 ein Beispiel einer dem Ansichtenerstellungselement ("View Composer (VC)") zugeordneten GUI kombiniert mit dem VCM von 30;
33 verschiedene Layout-Gestaltungen;
34 ein anderes Beispiel einer dem VC zugeordneten GUI;
35 Anwendungsfälle für den VCM;
36 Anwendungsfälle für den VC;
37 eine objektorientierte Implementierung von visuellen Hilfsmittel- bzw. Tool-Mitteilungen ("visual tool ("Vtool") messages");
38 ein Inhaltsseriennummern-Objekt;
39 einen Kommunikations-Wrapper für die VTools/BOS;
40 ein Beispiel eines BOS-Mittels ("BOSAgent"), d.h. eines VTools-Mittels ("VToolsAgent");
41 ein Beispiel einer VTools-Geschäftstransaktionsmaschine ("VTools business transaction engine (BTE)") und einer Ansichten-Geschäftstransaktionsmaschine ("View business transaction machine");
42 Inhaltscode-Mappings;
43 eine Ansichten-BTE ("ViewBTE");
44 die Beziehung zwischen Inhalt, Darstellung und Ansichten;
45 die Beziehung zwischen Ansichten-BTE ("ViewBTE"), w³OS-Mittel ("w³OSAgent") und Direktive ("Directive");
46 die Managementkonsole in Beziehung zu die Datenbank, das BOS und das Web-Betriebssystem;
47 die Kommunikationsarchitektur des Managers; und
48 die Kommunikationsschnittstellen.
Im Folgenden wird mit Bezug auf 1 eine Ausführungsform der vorliegenden Erfindung beschrieben. Elemente die äquivalent zu diesen bereits in Verbindung mit 2 beschriebenen sind haben die gleichen Bezugszeichen.
Ein Server 3 ist an ein Netzwerk angeschlossen oder Teil des Netzwerks, was Verbindungen zwischen Gliedern des Netzwerks, z.B. gemäß der TCP-/IP-Protokollfolge, ermöglicht. Der Server hat eine Adresse in dem Netzwerk und mit Hilfe der Adresse schließt sich ein User an eine Applikation 1 an, die als Kommunikationsmodul dient. Im Allgemeinen wird dann eine spezielle Seite an den User gesendet, die auf den Server bezogene allgemeine Daten enthält, z.B. eine so genannte Willkommensseite. Dem User steht es frei, auf dieser Willkommensseite eine Auswahl zu treffen oder nicht. Um ein Beispiel zu nennen, falls der Server Versandprodukte liefert oder darstellt, könnte die Willkommensseite bereits eine Auswahl von Inhalten (Bücher, Kleidung etc.) vorlegen.
Gemäß der Ausführungsform wird eine den User identifizierende Identifikation ("ID") empfangen. Dies kann durch direkte Eingabe des Users erreicht werden, z.B. die Willkommensseite fordert zur Eingabe eines User-Namens auf, oder automatisch als ein Teil der Protokollsession zwischen dem User und der Applikation 1, z.B. die User-Seiten-Applikation (z.B. der Netzwerkbrowser des Users) fügt automatisch die ID in die Kommunikation ein.
Diese ID und die mögliche Auswahl, die der User auf der Willkommensseite traf, werden dann an ein Eingabemodul 4 übermittelt. Das Eingabemodul 4 ist so ausgelegt, dass der Datenfluss ausschließlich von der Applikation 1 zu dem Eingabemodul 4 fortschreitet, aber nicht in die entgegengesetzte Richtung. Dies wird durch den Pfeil in 1 angezeigt.
Das Eingabemodul führt eine Vorverarbeitung und unter Umständen irgendeine Art von Filterung der empfangenen Daten durch. Zum Beispiel ist es möglich, die ID anhand allgemeiner Kriterien, die eine Entscheidung bezüglich der Gültigkeit der ID ermöglichen, überprüft werden. Solch ein Kriterium könnte z.B. das Format der ID sein.
Das Filtern kann verwirklicht werden, indem nur sehr spezielle Daten, z.B. User-IDs und eine vordefinierte Auswahl, angenommen werden. Alle anderen Daten werden verworfen. Mit Hilfe einer solchen Filterung in Kombination mit der Unmöglichkeit des Sendens von Daten aus dem Modul 4 an die Applikation 1 ist es einem böswilligen oder betrügerischen User nicht möglich, unerlaubten Zugang zu dem Modul 4 zu erlangen. Solch ein User kann höchstens die ID eines anderen Users benutzen, aber dies ist ein Problem, das außerhalb des Rahmens der vorliegenden Erfindung liegt.
Das Ergebnis der Vorverarbeitung und der ID werden dann an ein Hauptmodul 5 weitergegeben, das als Datenauswahl dient. Das Hauptmodul 5 ist so ausgelegt, dass der Datenfluss nur von dem Eingabemodul 4 an das Hauptmodul 5 möglich ist, aber nicht in die entgegengesetzte Richtung (siehe Pfeil in 1). Dies kann z.B. sichergestellt werden durch ein spezielles Protokoll oder irgendein anderes passendes Mittel, sei es in Bezug auf Hardware oder Software, zum Beispiel durch Auswahl einer entsprechenden Klassenhierarchie in der objektorientierten Programmierung derart, dass der Datenfluss in Bezug auf Objekte und Threads unidirektional ist. Das Hauptmodul 5 hat Zugriff auf die Datenbank 2 und hat die Aufgabe zu entscheiden, welche Daten dem User vorgelegt werden sollen. Die Entscheidung wird auf der Grundlage der ID und unter Umständen der durch den User getroffenen Auswahl und der Vorverarbeitung durch das Eingabemodul 4 getroffen.
Vorzugsweise wird die Auswahl durch Einrichten einer Verbindung zwischen dem Hauptmodul 5 und einem bezeichneten entfernten Server in dem Netzwerk durchgeführt, was durch Pfeil 10 in 1 angezeigt wird. Dieser Server empfängt dann die ID und unter Umständen weitere Daten, z.B. die durch den User getroffene Auswahl. Der bezeichnete entfernte Server trifft dann Entscheidungen über die Basis eines User-Profils bezüglich der Frage, welche Daten an den User geliefert werden sollen. Das Ergebnis wird dann an das Hauptmodul 5 übermittelt, das dann auf Daten in der Datenbank 2 zugreift.
Andererseits wäre zu beachten, dass das Hauptmodul immer in der Lage ist, allein Entscheidungen zu treffen, z.B. in dem Fall dass es nicht möglich, ist eine Verbindung zu dem entfernten Server einzurichten und die vorliegende Ausführungsform ohne irgendeinen derartigen entfernten bezeichneten Server implementiert werden kann, in welchem Fall das Hauptmodul allein alle Entscheidungen trifft bezüglich der Frage, welche Daten an den User geliefert werden. Der Vorteil des Implementierens der Ausführungsform in Verbindung mit dem bezeichneten Server liegt in der Tatsache, dass die Implementierung des Moduls 5 in dem Server 3 vereinfacht werden kann, da die erforderliche Verarbeitung verringert wird.
Die ausgewählte(n) Daten und unter Umständen Information bezüglich der visuellen Darstellung der Daten werden dann von dem Hauptmodul 5 an ein Modul 6 gesendet, das dann eine Datenseite auf der Grundlage dieser empfangenen Anzeigen vorbereitet. Eine vorbereitete Seite wird dann in einem passenden Format (z.B. HTML oder XML) an die Applikation 1 ausgegeben, wobei die Applikation die Seite an den User weiterleitet. Der User kann dann weitere Entscheidungen treffen, die wieder in der Schleife 1-4-5-6-1 gemäß dem vorstehend beschriebenen Konzept bearbeitet werden.
Das Seitenvorbereitungsmodul 6 ist vorzugsweise ebenfalls so ausgelegt, dass es außer Stande ist, irgendwelche Daten aus der Applikation 1 zu empfangen, sondern lediglich Daten an die Applikation 1 senden kann.
Auf Grund der Tatsache, dass es die obige Auslegung dem User nicht gestattet, irgendeine Struktur der Datenbank (in Form von Link-Hierarchien) anzusehen und durch das Bestehen eines unidirektionalen Flusses von Kontrolle und Datenverarbeitung wird eine absolute Datensicherheit sichergestellt und das System kann durch externe User nur in der vorbestimmten und gestatteten Weise benutzt werden.
Ein weiterer Vorteil der Erfindung besteht in der Tatsache, dass dem User individuell ausgewählte Daten vorgelegt werden, was zu einer Reihe von Vorteilen führt. Zum Beispiel ist es möglich, das System derart auszulegen, dass spezieller Inhalt (Datenelemente) nur durch vorbestimmte User angesehen werden kann.
Wenn z.B. das Hauptmodul und/oder der bezeichnete entfernte Server feststellen, dass der User minderjährig oder anhand seines User-Profils vermutlich minderjährig ist, dann kann aller anstößiger Inhalt automatisch gesperrt so werden, dass kein derartiger Inhalt an den User geliefert wird. Zurückkommend auf das vorstehend erwähnte Beispiel eines Versandhandelsdienstes kann andererseits eine User-spezifische Darstellung derart ausgeführt werden, dass der User Information über Produkte, die ihn wahrscheinlich interessieren, in einer Form empfängt, die er vermutlich ansprechend finden wird. Wenn zum Beispiel festgelegt wird, dass ein User ein Teenager ist, der Musik-CDs kaufen möchte, dann kann eine vollständig andere Auswahl dargestellt werden als für einen User, der als über 16-jährig beurteilt wird. Gleichermaßen kann die visuelle Darstellung individuell angepasst werden, z.B. kann die Font-Größe für einen älteren User größer gewählt werden und alle Blink- und Ablenkungs-Elemente können weggelassen werden.
Nun wird in Verbindung mit 3 und den anschließenden FIG. eine andere Ausführungsform der Erfindung beschrieben. 3 zeigt eine schematische Darstellung einer Drei-Tier-Software-Architektur, wobei ein erster Tier 31 Datenspeicherung behandelt, ein zweiter Tier 32 funktionales Verarbeiten und den Zugriff auf den Datenspeicher-Tier 31 behandelt und ein oder mehrere Kommunikationsmodule 33 bilden einen dritten Tier, der die Kommunikation mit entsprechenden externen Netzwerken behandelt. Anzumerken ist, dass die vorstehend in Verbindung mit 1 beschriebene Ausführungsform in Kontext mit der Ausführungsform von 3 gebracht werden kann, in welchem Fall die Datenbank 2 dem Datenspeicher-Tier 32 entspricht, das Hauptmodul 5 dem Logik-Tier 32 entspricht und die Module 1, 4 und 6 in einem Kommunikationsmodul 33 enthalten sind.
Jedes der Kommunikationsmodule 33 stellt einen Kommunikationskanal an ein jeweiliges Netzwerk bereit, z.B. das World Wide Web, ein Telefonnetzwerk, ein Fax-Netzwerk etc. Genauer gesagt können einige der Kommunikationsmodule aktive Module zum Einrichten aktiver Kommunikationskanäle für das Senden von Daten in ein entsprechendes Netzwerk sein und andere Kommunikationsmodule können interaktive Module zum Einrichten von interaktiver Kommunikation sein.
Vorzugsweise umfasst der zweite Tier 32 eine Software-Architektur, die Software-Elemente für das Verarbeiten von Datentransaktionen von Software-Elementen für die Implementierung von Applikationslogik trennt. Vorzugsweise bilden die Software-Elemente für das Verarbeiten von Datentransaktionen eine grundlegende Transaktionsarchitektur und die Software-Elemente, die Applikationslogik implementieren, sind Plugins, die dafür ausgelegt sind, in die grundlegende Transaktionsarchitektur eingeklinkt zu werden.
Ferner wird es bevorzugt, dass Datentransaktionen durch Mittel ausgeführt werden, an denen die Applikationslogik implementierenden Software-Elemente Tasks durchführen.
Die in 3 gezeigte Struktur wird vorzugsweise derart implementiert, dass sie ein gemeinsames Datenmodell (in dem ersten Tier 31), Geschäftsapplikationen, die alle denselben Mechanismus von Datenbearbeitung (durch den zweiten Tier 32 bereitgestellt) verwenden und irgendeine mögliche Weise, Daten zu präsentieren (behandelt durch den dritten Tier 33), vollständig integriert.
Dadurch, neben dem Aufweisen eines gemeinsamen Datenmodells für alle Applikationen und Schnittstellen, werden Flexibilitäten bei der Entwicklung jeglicher Art von Geschäftsapplikationen sowie bei der Nutzung jeder möglichen Technologie zum Darstellen von Daten angeboten. Sogar solche Mittel wie tragbare ("wearable") Computer, die gegenwärtig nicht einmal im Handel erhältlich sind, können in der Zukunft integriert werden.
Nun wird eine Zusammenfassung der drei Tiers in 3 abgegeben, wobei eine ausführlichere Beschreibung von jeder einzelnen Komponente folgen wird.
Ein Aspekt des gezeigten Systems ist die Anwendung eines neuen Datenmodells in dem Datenspeicher-Tier 31. Auf der Grundlage dieses Datenmodells kann irgendeine Art von Verarbeitungslogik, wie Geschäftslogik, implementiert werden, so wie jede mögliche Weise von Datenpräsentation verwendet werden kann. Eine beachtenswerte Innovation des Datenmodells ist die Tatsache, dass jeder Inhalt in einzelne Teile zerlegt werden kann, die als Datenatome behandelt werden. Jedem einzelnen von diesen Datenatomen (oder Datenelementen) wird eine einzigartige Inhaltsseriennummer zugewiesen, was eine sehr ausführliche Beschreibung des Inhaltsatoms ergibt, basierend auf allen seiner Attribute und/oder Kategorien.
Es gibt zwei grundlegende Unterteilungen von Inhaltsdeskriptoren, nämlich die erste Unterteilung, die die so genannten natürlichen Gruppen sind und die zweite Unterteilung, die die zusätzlichen Gruppen sind. Diese natürlichen Gruppen werden in einem so genannten Stammkatalog kategorisiert und beschrieben. Hierbei wird eine Inhaltsbeschreibung abgeleitet durch Zerlegen der Inhaltsgesamtheit in eindeutige Datensätze unter Verwendung einer hierarchischen Struktur mit einer Tiefe von n Ebenen, wobei n eine natürliche Zahl ist und n z.B. gleich 14 sein kann. Die zweite Gruppe von Inhaltsdeskriptoren, nämlich die zusätzlichen Gruppen, kann mehr als vier Dutzend zusätzlichen Attributen entsprechen, die dazu benutzt werden können, jedem Inhaltsatom spezielle Eigenschaften oder Qualitäten zuzuweisen. Zudem wird dieser Mechanismus des individuellen Beschreibens der Daten mit einer Seriennummer nicht nur auf Inhalt angewendet, sondern auch auf User. Erneut umfasst der Begriff "User" nicht nur menschliche Wesen, sondern meint gleichermaßen angedockte Computersysteme und zusätzliche Hardware. Alle User werden in dem Datenmodell in der gleichen Weise beschrieben. Deshalb können sich auf User beziehende Attribute leicht verglichen und an Attribute, die Inhalt beschreiben, angeglichen werden.
Mit diesem neuen Weg des Zerlegens von Daten in Atome und der Fähigkeit, jedem Atom verschiedene Deskriptoren zuzuweisen, erreicht man ein lang ersehntes Ziel: Es ist möglich, die enormen Mengen irrelevanter Daten zu bezwingen und immer und zum jeder Zeit direkt zu der einen bestimmten Information, die man wirklich benötigt, zu gehen. Es verschafft einem die Möglichkeit, dass man nun auf individueller Basis Daten gruppieren, nach Inhalt suchen, auf gewisse Klassen von Information zugreifen kann. Man ist nicht länger auf vordefinierte Strukturen und Mechanismen angewiesen, sonder man kann immer dynamisch alle benötigten gewünschten Kriterien anwenden. Dies wird auch eine organische Datenclustersynthese bezeichnet. Dadurch ist es möglich, diese eindeutig definierte Suche nach präzisem Inhalt auf jeden Geschäftsvorgang, auf jede Suche auf einer Website, auf jeden Walk-through in einem online e.commerce Laden, etc. anzuwenden und immer die einzelne Auswahl auf den User (dem Anforderer von Daten) zu richten.
Außer dem vorstehend beschriebenen grundlegend neuen Datenmodell stellt das System auch ein absolutes Inhaltstransaktionsmanagement bereit. Es existiert nämlich ein einziges Betriebssystem, das die Fähigkeit hat, eine Brücke zwischen verschiedener unterschiedlicher Hardware und verschiedenen unterschiedlichen Applikationen zu schlagen (letztendlich eine große Anzahl dieser Einzwecksysteme zu ersetzen), d.h. eine Applikation, die in der Lage ist, wahres Inhaltstransaktionsmanagement zu implementieren. Inhaltstransaktionsmanagement interagiert besonders mit dem vorstehend beschriebenen Datenmodell. Es bedeutet, einen Weg zu haben, Struktur auszutauschen und in Daten umzusetzen. Da man nun in der Lage ist, auf irgendeine Art von Datenatom auf direkte Weise zuzugreifen und Inhalt durch seine Attribute zu definieren, wird es sehr leicht, irgendeine Art von Geschäftsfunktionalität zu implementieren. Das einzige, das man benötigt, ist eine gemeinsame Plattform, die die Grundlage für alle der verschiedenen Geschäftsapplikationen schafft, die das Datenmodel verwenden und Teil des gesamten Inhaltstransaktionsmanagements sind.
Diese gemeinsame Plattform wird in dem Tier 32 implementiert und wird auch als ein Geschäftsbetriebssystem ("business operating system (BOS)") bezeichnet. Es ist das ultimative erweiterbare System, das nur die Grundlagen und die notwendige Basisfunktionalität, die allen der durchgeführten Inhaltstransaktionen gemein ist, implementiert. Das Geschäftsbetriebssystem bietet allen Arten von externen Systemen Gates an, die auch das Inhaltstransaktions-Managementsystem nutzen können. Dies macht eigentlich das BOS zur wesentlichen Verarbeitungseinheit innerhalb eines großen Unternehmens.
Ein Hauptmerkmal des BOS ist die Tatsache, dass jegliche Art von Geschäftsfunktionalität implementiert werden kann. Die neue Architektur dieses fortschrittlichen Systems macht es möglich, für jegliche vorstellbare Art von Geschäftsfall Funktionalität in separaten Modulen, den so genannten Geschäftstransaktionsmaschinen ("business transaction engines (BTEs)"), die im weiteren Verlauf ausführlich beschrieben werden, zu implementieren.
Diese Module können unabhängig voneinander aus irgendwelchen Default-Geschäftstransaktionsmaschinen entwickelt werden. Sie können zu jeder Zeit konfiguriert, freigegeben, unwirksam gemacht oder vollständig aus dem System entfernt werden. Geschäftstransaktionsmaschinen werden in bestimmte Inhaltstransaktionskanäle eingeklinkt. Vorzugsweise verfügt das Geschäftsbetriebssystem standardmäßig über drei verschiedene Kanäle: einen Logistikkanal, einen Finanzkanal und einen Ausführungskanal. Datentransfer und Anforderungen werden bezüglich ihrer Art von Ziel auf verschiedene Weisen an Kanäle und Geschäftstransaktionsmaschinen geroutet.
Auf diese Weise kann das System genau gemäß der maßgeschneiderten Funktionalität (perfekte kundenspezifische Anpassung) implementiert werden, ist aber auch zu flexibler Anpassung fähig.
Außer dass es ein sehr starkes und fortschrittliches Basissystem für jegliche Art von Inhaltstransaktionsmanagement jeglichen Geschäfts aufweist, bietet das System auch die Möglichkeit, alle möglichen Systeme und Technologien zu benutzen, um interaktiv mit Usern und anderen Systemen zu kommunizieren. Die Kommunikationsmodule des dritten Tiers sind entweder aktive Kommunikationskanäle oder interaktive Kommunikationskanäle. Alle der Kommunikationskanäle empfangen Nachrichten durch ihre fest zugeordneten Gates. Interaktive Kanäle senden auch Anforderungen und Mitteilungen zurück an das BOS. Sie führen Kommunikation in beide Richtungen durch, aktive Kanäle empfangen lediglich von dem BOS.
Beispiele aktiver Kommunikationskanäle sind:
SMS-OS, d.h. ein Kurznachrichten-Betriebssystem das Nachrichtenversand über Mobiltelefone und Pager bietet,
APM-OS, d.h. ein Betriebssystem für automatischen Nachrichtenversand über Telefon, das automatisch vordefinierte und dynamisch erzeugte Telefonnachrichten an jeden in dem System registrierten senden kann,
Ad-OS, d.h. ein Anzeigen-Betriebssystem, das unter Verwendung von Beamern, Video-Projektion oder Fernsehschirmen individuell kundenspezifische Werbeanzeigen zu fest zugeordneten Plätzen stellen kann, und
RTS-OS, d.h. ein Lauftext-Betriebssystem, das Tickermeldungen und Lauftextanzeigen, z.B. für Börsen-Angebote oder -Meldungen, verwaltet.
Beispiel der interaktiven Kommunikationskanäle sind:
ein Web-Betriebssystem (das im Folgenden als w³OS bezeichnet wird), das XML und die vorstehend erwähnte One-Page-Web-Technologie verwendet, um über das Internet zu jedermann Zugang zu haben und durch jedermann benutzt zu werden,
PDA-OS, d.h. ein persönliches Datenmanagement-Betriebssystem, das die Integration von persönlicher digitaler Unterstützung und Palmtop-Computern bietet,
ITV-OS, d.h. ein interaktives Fernseh-Betriebssystem, das interaktives Fernsehen mit dem System integrieren kann,
Mail-OS, d.h. ein Mail-Betriebssystem, das Berichtsmechanismen, wie Versenden von auto-erzeugten E-Mails, die durch Eskalationsabläufe in dem BOS herausgegeben werden, anbietet,
Fax-OS, d.h. ein Fax-Betriebssystem, das auch Berichts-Features und Empfängermechanismen anbietet,
Telex-OS, d.h. ein Telex-Betriebssystem, das ein Gate zu alten Telexsystemen weltweit ist,
I-OS, d.h. ein Bestands-Betriebssystem, das die JINI-Architektur verwendet, um Haushaltsgeräte wie intelligente Kühlschränke etc. zu integrieren, und
WC-OS, d.h. Wearable-Computer-Betriebssysteme, die die Integration von miniaturisierten Wearable Computergeräten bieten.
4 zeigt ein Beispiel in dem die vorstehend erwähnte Struktur erweitert worden ist. Es zeigt die vorstehend erwähnten Betriebssysteme, die mit dem BOS interagieren, das auch die drei erwähnten Transaktionskanäle, die Gates und externen Andockungen zeigt und worin der Datenspeicher als der EIC bezeichnet wird, nämlich der Unternehmungsinformations-Cluster ("enterprise information cluster (EIC)"). Des Weiteren zeigt 4 die in das BOS eingeklinkten Geschäftstransaktionsmaschinen. Weiterhin führt ein als eBrain 5 bezeichnetes intelligentes Server-Gerät eine Optimierung der gegenwärtigen Geschäftstransaktionsmaschinen durch und erstellt neue Geschäftstransaktionsmaschinen auf der Grundlage von Aktivitätsinformation von Usern bezüglich Inhalt, wobei bestimmte, dem intelligenten Server-Gerät bereitgestellte Prinzipien, Ethik und Grundlinien berücksichtigt werden.
Inhaltsmodell und User-Modell
Nun wird eine Ausführungsform erläutert, in der das allgemeine Konzept des Anordnens von Daten in der Datenbank beschrieben wird. Wie bereits vorstehend erwähnt, werden dieses neue Datenmodell und User-Modell in Verbindung mit dem Gesamtsystem in 3 und 4 als implementiert beschrieben, es ist jedoch zu beachten, dass dieses Datenmodell und User-Modell auch unabhängig von der vorstehend beschriebenen Drei-Tier-Struktur implementiert werden können, nämlich zusammen mit irgendeiner Datenbank.
Ein Aspekt des Inhaltsmodells gemäß der vorliegenden Erfindung ist, dass es Inhalt, Inhalts-Metainformation (Beschreibung, Attribute, Eigenschaften) und die Darstellung von Inhalt trennt.
Diese Tatsache gestattet das Kategorisieren von Inhalt und seine Zuordnung zu einer großen Anzahl spezieller Attribute. Diese Attribute können jedem Stück von Inhalt spezielle Eigenschaften zuweisen. Der Nutzen daraus ist, dass die Datengesamtheit viel durchsuchbarer und viel besser strukturiert wird.
Zwei wichtige Teile des Inhaltsmodells setzen diese Struktur der Inhaltsgesamtheit durch: nämlich der Inhaltsstammkatalog und die Inhaltsseriennummern. Dies wird nun ausführlich erläutert.
Der Inhaltsstammkatalog definiert eine insgesamt abstrakte Struktur für die gesamte Inhaltsgesamtheit. Sie ist erweiterbar konzipiert, um alle künftigen Bedürfnisse zu befriedigen. Die Inhaltsseriennummer beschreibt jedes Inhaltsatom und besteht aus zwei Gruppen von Reihungen: den natürlichen Gruppen und den zusätzlichen Gruppen.
Jedes Inhaltsatom (oder Inhaltselement) wird durch seine Seriennummer beschrieben. Die natürlichen Gruppen sind mit dem Inhaltsstammkatalog verbunden und die zusätzlichen Gruppen sind mit der Reihnungswertabelle verbunden. Diese Reihungswerttabellen enthalten Werte, die alle einem speziellen Inhalt zugewiesen werden können.
Inhalt ist im Wesentlichen jedes Stück von Information oder jedes Stück von Daten. Deshalb kann Inhalt alles sein: ein Bild, ein Text, eine Schlagzeile, eine Schaltfläche (im Folgenden: Button), ein Spielfilm etc.
Die Seriennummer, die ein jedem Inhaltselement zugeordneter einzigartiger Teil ist, umfasst in der augenblicklich beschriebenen Ausführungsform 256 Stellen. Um eine effiziente Tiefe zu schaffen, sollte sie mindestens 128 Stellen umfassen, aber 256 oder mehr sind vorzuziehen.
Die Reihungswerttabellen umfassen zusätzliche Teile der Seriennummer, um Attribute den Inhaltselementen zuzuweisen. Selbst die Sicherheitsoptionen für Inhaltselemente sind in diesen Tabellen enthalten.
Die ersten 14 Reihungen gehören alle zu den natürlichen Gruppen und sind in dem Inhaltsstammkatalog definiert. Die anderen 38 zusätzlichen Gruppen sind in den Reihungswerttabellen definiert. Zu beachten wäre, dass abhängig von der bestimmten Situation selbstverständlich mehr oder weniger als 14 Reihungen zu den natürlichen Gruppen gehören können und mehr oder weniger als 38 zu den zusätzlichen Gruppen.
Jede Nummer in einem Segment wird auf einem entsprechenden Deskriptor in dem bzw. den vorstehend erwähnten Inhaltsstammkatalog oder Reihungswerttabellen abgebildet. Um eine Beispiel zu geben, die Nummer 0000001 in dem Hauptschlüssel (sieben Stellen) könnte "Computerhersteller" darstellen. Dann könnte der Unterschlüssel 000001 (sechs Stellen) einen bestimmten Firmennamen, wie "Compaq", darstellen und die weiteren Unterschlüssel werden weitere Deskriptoren in einer Hierarchieordnung identifizieren.
Man stelle sich vor, dass jemand in einem Firmennetzwerk, einem eCommerce-System, oder sogar im gesamten Internet nach einer Einzelheit oder einem Objekt suchen möchte, aber man den bestimmten Namen nicht weiß. Typischerweise wird es lange Zeit dauern, irgendeine Information darüber zu finden, sofern man überhaupt etwas findet, weil alle gegenwärtigen Internet-Dienste lediglich für klar definierte Gegenstände eine Suche bieten. Ein anderes Problem ist die Arbeit von Suchmaschinen. Diese suchen meistens nach einer passenden Beschreibung in dem META-Tag-Bereich der Web-Seite, weshalb man keine Chance hat, eine bestimmte Einzelheit zu finden.
Mit dem vorstehend beschriebenen kategorisierten Inhaltsmodell ist eine neue Art des Suchens nach Inhalt möglich. Nun ist es möglich, über Attribute, die das gewünschte Objekt hat, zu suchen. Man könnte z.B. eine Anforderung durchführen für etwas das schwarz, essbar, teuer, Seafood und in England verfügbar ist. Das Ergebnis einer solchen Suche könnte sein: Kaviar.
Der Teil der Natürlichen Gruppierung besteht aus 14 verschiedenen Gruppen, in die man den Inhalt in eine hierarchische Struktur von der allgemeinsten Kategorie bis zu einer sehr elementaren, bestimmten Information sortiert. Der maximale Grad verschiedener Gruppen zum Kategorisieren von Inhalt ist 9,99 ...·10^?74 mit einer Gruppierungstiefe von 14 Stufen.
Um ein Maximum an Sicherheit zu gewährleisten, umfasst das Seriennummernsystem ("Serial Number System") verschiedene Sicherheitsgruppen ("Security groups") für jedes Inhaltselement. Es ist definierbar, welcher Sicherheitsgruppe, Stufe oder Person dieses Element gezeigt werden darf oder nicht.
Nicht nur die Datensicherheit ist Teil dieser Gruppen, sondern auch das Alterseignungsattribut für den User, da Ursprungsland, von dem die Anforderung kommt und der Verfall des Inhalts sind wichtig.
Letztendlich ist es möglich, den Inhalt auf "inaktiv" zu setzen und er wird in keiner Weise aufscheinen. Nicht benutzte Gruppen wären Null.
Die zusätzlichen Gruppen sind vordefiniert – in den Reihungswerttabellen – aber erweiterbar. Sie folgt nicht dem Algorithmus, der für die Natürlichen Gruppen benutzt wird. Wenn der Systemmanager einen Gegenstand hinzufügen möchte, kann ein Inhaltseingabe-Tool diesem eine neue nicht verwendete Nummer geben, z.B. die nächste die in der Reihe frei ist. Die Serialisierung des "Professionellen Codes" (Gruppe 35) wird von dem deutschen Finanzcodiersystem kopiert, damit es sich von irgendwelchen anderen Codiersystemen in unserem Inhaltsmodell unterscheidet.
Die neutralen Attributgruppen ("Neutral Attribute Groups") bieten die Möglichkeit, klarere Information über ein bestimmtes Thema zu erhalten, ohne seinen allgemeinen Namen zu kennen bzw. zu wissen. Die neutralen Gruppen beschreiben den Inhalt über seine allgemeinen Eigenschaften wie: Sprache, Ursprungsland oder Material aus dem er gemacht ist. Ferner können diese Gruppen der "normalen" Suche hinzugefügt werden, um klarere Information über etwas herauszubekommen.
Die User-abhängigen Attributgruppen sind den neutralen Attributgruppen ziemlich ähnlich, aber sie geben dem Objekt eine emotionalere und humanere Beschreibung. Gruppen wie der "Spirituelle Code", den "Bildungsumfang" oder der "Spaßindex" bieten eine Suchfunktionalität, die in der IT-Welt völlig neu sind.
Die natürlichen Gruppen bestehen aus 14 Feldern, die ein sehr ausführliches Abbilden und Beschreiben des Inhalts bieten.
Die erste Gruppe ist die Hauptgruppe und sie umfasst 7 Stellen: 0000000 bis 9999999.
Die zweite bis vierte Gruppe hat 6 Stellen: 000000 bis 999999.
Die anderen Gruppen haben 5 Stellen: 00000 bis 99999.
Das bietet eine maximale Flexibilität von 9999999·(999999)³ (99999)^?10 = 9,9 ...·10^?74 verschiedene Gruppen.
Um einer Gruppe eine einzigartige Nummer zu geben, ist es erforderlich, sie vor dem Speichern zu sortieren. All diese 14 Gruppen werden die Daten nach ihren ersten zwei oder nur dem ersten Buchstaben der Beschreibung sortieren (in dem obigen Beispiel, wo ein Deskriptor in der Hauptgruppe "Computerhersteller" war, wären diese zwei Buchstaben CO). Die folgende Tabelle zeigt den Buchstabensortieralgorithmus:
Das bedeutet, dass eine bestimmte Gruppe die Nummer erhalten wird, die eine Beziehung zu dem bzw. den ersten Buchstabe(n) ihrer Beschreibung hat. Nun ist es möglich, Spannweiten von Nummern in jeder Gruppe zu definieren, die zu verschiedenen Buchstaben gehören.
Das englische Alphabet umfasst 26 Buchstaben Jede Nummer unserer 14 Gruppen wäre nicht mit 26 teilbar, deshalb müssen wir den Dezimalrest der Nummer abtrennen, um sie als eine Ganzzahl zu behalten. Dies bedeutet, dass einige Nummern aus jeder Gruppe herausfallen werden. Um den Weg zu kontrollieren, auf welchem Nummern niemals benutzt werden, ist es erforderlich einen speziellen Algorithmus zu definieren. Es gibt zwei mögliche Wege, wo wir sie verlieren können:

– Zwischen jedem der 26 Teile
– Am Ende der ganzen Gruppe

Dafür müssen wir jede Gruppe (denken Sie daran, dass die erste bereits 7 Stellen hat) durch 26 teilen (für die ersten 3 Gruppen durch (26)², weil wir sie über ihre ersten zwei Buchstaben speichern werden).
Nach dem Abtrennen des Dezimalteils der Nummer kennen bzw. wissen wir die Spannbreite für jeden Buchstaben. Nun müssen wir diese Nummer mit der Nummer multiplizieren, die der Buchstabe hat. Zum Beispiel: Das D zwingt unser System mit dem Faktor 3 zu multiplizieren. Auf diese Weise ist es möglich, die Nicht-Benutzt-Nummern zu fixieren, weil sie am Ende jeder Gruppenebene sein werden.
Es gibt zwei Hauptbestandteile in unserer Seriennummer ("Serial Number"): Die Natürlichen Gruppen, die die Inhaltselemente in eine Art von Katalog sortieren und die Reihungswertgruppen, zu denen die Sicherheits- und Attribut-Gruppen gehören. In beiden Bestandteilen ist es dem Systemmanager möglich, neue Untertypen zu erzeugen und in die enthaltende Struktur einzufügen. Wenn ein neues Produkt herauskommt, das zu einer neuen Gruppe gehört, kann es leicht hinzugefügt werden.
Ferner hat der Systemmanager die Möglichkeit, aus einer bestehenden Liste wie einem Dropdown-Menü auszuwählen. All diese Listen für jede Gruppe und Kategorie müssen in der Datenbank vordefiniert werden.
Die Ansichten (oder visuellen Darstellungen) gehören auch zu der Inhaltsdatenbank ("Content Database"), wie es jedes Inhaltselement tut. Der Grund für diese Art des Speichern von Daten ist sehr einfach. Ansichten werden ebenfalls in der Inhaltsdatenbank ("Content Database") gespeichert, weil sich jedes Inhaltselement in der Inhaltsdatenbank ("Content Database") auf ihre eigene Ansicht beziehen wird. Dies bedeutet, dass ein bestimmtes Element nicht nur mit ihrem reinen Daten- und Byte-Strom gesichert wird, sondern auch mit kurzen Formatierungstags, um dem System mehr ihr in der Ansichtentabelle ("View Table") zugewiesene Funktionalität zu geben. Zum Beispiel werden zu einem Bild auch die Tags "<zeige Bild ></zeige Bild>" in der Ansichtentabelle gesichert. Dies bietet späteren Versionen die Möglichkeit, Seiten "während des Übertragens" ohne irgendwelche Regeln von vordefinierten Ansichten zu erzeugen.
Die Ansichten-ID ("ViewID") ist eine Ganzzahl mit einer Länge von 4 Stellen. Somit ist die Maximalkapazität von verschiedenen Ansichten 9999.

Spannweite Ansichten

0001 bis 0999 Inhaltsansichten für einzelne Elemente

1000 bis 9999 Ansichten, Stilvorlagen, Zusammenstellungen
Die ersten 999 ID-Nummern werden die Ansichten für alle einzelnen Inhaltselemente, wie Buttons, Bilder, Texte und so weiter definieren. Ab 1000 werden die Zusammenstellungen definiert. Damit hat der Systemmanager die Möglichkeit, annähernd 9000 verschiedene Ansichten zu erzeugen. Ansichten werden mit den nachstehenden Visuellen Tools ausführlicher definiert.
Die Inhaltsdatenbank ("Content Database") besteht aus drei Gruppen von Datenbanktabellen:

– Inhaltstabelle ("Content Table") (die tatsächlichen Inhaltsatome ("Content Atoms") speichernd)
– Ansichtentabelle (Beschreibungen für Default und kundenspezifische Ansichten des Inhalts speichernd)
– Seriennummerntabellen ("Serial Number tables") (die Werte für die Inhaltsseriennummer-Reihungen ("Content Serial Number sequences") definierend)

In dem Inhaltsmodell befinden sich drei Tabellen:

1. Inhaltsinformationstabelle ("Content Information Table (CIT)")
2. Inhaltstabelle ("Content Table (CT)")
3. Ansichtentabelle ("View Table")

Dies wird in 5 gezeigt.
2 zeigt die Abhängigkeiten der drei Inhaltstabellen. Auf diese Weise ist es möglich, eine Inhalts-ID ("Content ID") einer speziellen Ansicht (ViewID) zuzuweisen.
Die Inhaltsinformationstabelle ("Content Information Table (CIT)") 51 enthält wichtige Information. Die gesamte vorstehend beschriebene Seriennummer ("Serial Number") und Beschreibung ("Description") geben dem Inhaltselement einen einzigartigen Platz in unserem Datenbankmodell. Die Produktdefinition ist nur ein Bitwert, der anzeigt, ob der Inhalt ein verkäuflicher Artikel ist (mit zugeordnetem Lagerbestand und Preis in der Finanzdatenbank) oder nicht. Der Produkt-Flag ist durch Default auf '0' gesetzt, was bedeutet: Kein Produkt. Die CIT 51 enthält ferner einen Wert für eine Defaultansicht ("DefaultView"). Dies bedeutet, dass der Systemmanager definieren kann, ob ein Default-Layout verwendet werden sollte oder nicht.
Die Inhaltsinformationstabelle ("Content Information Table") weist folgende Attribute auf:

– ID. Dies ist ein interner Identifikator für Inhalte, der einzigartig und eindeutig ist.
– Seriennummer ("SerialNumber"). Die Seriennummer ("SerialNumber") besteht aus 256 Bytes und funktioniert als eine vollständig detaillierte Beschreibung für jeglichen Typ von Inhalt. Sie klassifiziert nicht nur diese Daten, sondern ermöglicht das Zuweisen einer breiten Spanne von Attributen an sie.
– Beschreibung. Eine Textbeschreibung dieses Inhalts.
– DefaultView. Dies ist eine Bezugnahme auf eine ViewID, die die DefaultView darstellt. Der DefaultView-Parameter kann weggelassen werden, um anzuzeigen, dass es keine DefaultView gibt, oder wenn es nur eine Ansicht gibt, dann wird diese automatisch der Default. Vor allem muss diese DefaultView in der Inhaltstabelle ("Content Table") aufgelistet werden.
– ErstellerID ("CreatorID"), Erstellt ("Created"), ModifikatorID ("ModifierID"), Modifiziert ("Modified"). Diese Attribute müssen automatisch eingestellt werden, wenn der Datensatz verändert wird.

Die Inhaltstabelle ("Content Table") 52 speichert die tatsächlichen Inhaltselemente. Die CITID weist ihn der Seriennummer ("Serial Number") zu. Auch da gibt es zwei Spalten für die Daten, ein Textfeld für Zeichenfolgen und ein Binärfeld für die binär gesicherten Daten (wie Bilder). Die Typ-Spalte definiert, welcher Typ von Daten gespeichert wird. Die Spezielle-Sicherheit-Spalte ist ein wichtiges Feature, weil einfach durch die Seriennummer alle Elemente eines speziellen Inhalts die gleiche Sicherheitsstufe (Bilder, Texte, Dateivorsätze) haben werden. Dies schafft die zusätzliche Möglichkeit, mit der gleichen CITID die Sicherheitsstufe einem einzelnen Inhaltselement anders als die anderen Inhaltselementen einzustellen.
Die Inhaltstabelle ("Content Table") enthält für jedes Element auch eine Ansichten-ID ("ViewID"). Diese Ansichten-ID ("ViewID") bezieht sich auf die Ansichtentabellen. Dies gestattet den ViewTools für eine oder mehrere Inhaltselemente eine spezielle Ansicht oder Zusammenstellung einzustellen oder auszuwählen.
In der Inhaltstabelle ("Content Table") werden alle tatsächlichen Inhalte und ansichten für Inhalte gespeichert. Für jeden durch eine einzige, individuelle Seriennummer ausgedrückten Inhalt können ein oder mehrere Darstellungen bestehen:

– ID. Dies ist eine fortlaufende Nummer, die für jeden Eintrag in die Tabelle einzigartig ist.
– CITID. Dieser Identifikator stimmt mit der ID des in der Inhaltsinformationstabelle ("Content Information Table"), zu der diese tatsächlichen Inhaltsdaten gehören, beschriebenen Inhalts überein. Für jede Darstellung einer Inhaltsbeschreibung besteht in der Inhaltstabelle ("Content Table") ein Datensatz mit der der Seriennummer ("SerialNumber") zugeordneten CITID und dem beschreibenden Eintrag in der Inhaltstabelle ("Content Table").
– Ansichten-ID ("ViewID"). Jede Darstellung eines Inhalts kann als eine Ansicht betrachtet werden. Jegliche in der Inhaltstabelle ("Content Table") benutzte Ansichten-ID ("ViewID") bezieht sich auf eine Ansichtsdefinition mit einer einzigartigen Ansichten-ID ("ViewID") in der Ansichtentabelle.
– Textdaten ("TextData"). Dies ist ein Feld für textliche Inhaltsdarstellungen.
– Binärdaten ("BinaryData"). Dies ist ein Feld für im Binärformat gespeicherte Inhaltsdarstellungen. Die ViewID stellt fest, ob das TextData- oder das BinaryData-Attribut verwendet wird (es ist nicht möglich, dass beide Daten enthalten).
– Spezielle Sicherheit ("ExtraSecurity"). Dieses Attribut kann eine zusätzliche (sich unterscheidende) Sicherheitseinstellung für die tatsächlichen Inhaltsdarstellungen enthalten (falls erforderlich). Das ExtraSecurity-Feld dehnt die Sicherheitseinstellungen in der Seriennummer dieses Inhalts aus; infolgedessen muss ExtraSecurity niedriger sein als die Gesamtsicherheitseinstellung.
– CreatorID, Created, ModifierID, Modified: Diese Attribute müssen automatisch eingestellt werden, wenn der Datensatz abgeändert wird.

Die Ansichtentabelle 53 enthält die XML-Zeichenfolgen aller erzeugten Ansichten und auch Platzhalter für neue. Die Ansichtentabelle enthält keine Inhaltsinformation. Sie enthält die Ansicht und eine typdefinierende XML-Zeichenfolge. Das bedeutet, dass eine spezielle Ansicht immer zu einem speziellen Inhaltstyp (wie "kleines Bild") gehört. Weil Ansichten ohne Inhaltsinformation aber mit Inhaltstypinformation verwendet werden, kann man eine Ansichtentabelle für alle Inhaltselemente in der gesamten Datenbank verwenden. Zum Beispiel wird ein Button immer wie ein Button funktionieren, damit man dieselbe Ansicht für alle Buttons verwenden kann, aber unterschiedliche Funktionalität wird in dem Button-Code in der Inhaltstabelle ("Content Table") spezifiziert.
Die Ansichtentabelle listet alle vordefinierten Typen von Ansichten auf, beginnend bei Grundtypen wie Bilder, Schlagzeilen, Paragraphen, Links bis hin zu Ansichten, die andere Ansichten und/oder Bezüge zu Content IDs enthalten:

– ViewID. Jede ViewID identifiziert einen speziellen Ansichtentyp eindeutig.
– XML-Zeichenfolge ("XMLString"). Dieses Attribut der Ansichtentabelle enthält die leere XML-Datei für diese Ansicht. Diese XML-Zeichenfolge enthält eines der folgenden:
– Tags die den Aufbau der Ansicht beschreiben, falls erforderlich (für "gefüllte" Ansichten) in Kombination mit den ViewIDs für die zwischen diese Tags zu placierenden Darstellungen oder Zusammenstellungen
– Tags die lediglich das Format der Ansicht beschreiben, mit Platzhalter (Nummern), die durch jede beliebige Ansicht ersetzt werden können.

Der XMLString kann Bezugnahmen enthalten auf

– andere Ansichten ("ViewIDs") oder
– Inhalte ("Content IDs"), falls erforderlich in Kombination mit einer ViewID ausgenommen Default.

Diese Bezugnahmen ermöglichen eine rekursive Zusammenstellung von Ansichten und Inhaltsdarstellungen. Da eine Ansicht auf eine andere Ansicht Bezug nehmen kann, kann diese zweite Ansicht in die erste gestellt werden. Gleichzeitig können Ansichten zu jeder Zeit auch direkt entweder auf eine Inhaltsbeschreibung (was die Anforderung an die DefaultView leitet, die selbstverständlich wiederum andere Ansichten oder Inhalte enthalten kann) oder auf eine besondere Ansicht (Darstellung) oder einen Inhalt (wenn die Bezugnahme auch eine ViewID aufweist) Bezug nehmen.
– Beschreibung. Dieses Feld enthält eine eindeutige Beschreibung für diese Ansicht.
Die Seriennummer ist in Reihungen geteilt. Der Grund für diese Teilung ist, dass wir jede Reihung einem bestimmten Attribut des Inhalts entsprechen lassen können. Die Reihungen enthalten die natürlichen Inhaltsgruppierungen und die jedem Inhaltselement zugewiesenen zusätzlichen Attribute, wie Farbe, Sicherheit und ihren professionellen Code.
Der Inhaltsstammkatalog umfasst 14 natürliche Gruppen, die den Inhalt kategorisieren, siehe 6.
Wie in 6 gezeigt, weist der Inhaltsstammkatalog 14 Serienummer ("SN")-Segmente auf. Sie ermöglichen ein Gruppieren von Inhalt in einer sehr detaillierten Hierarchie. Alle Segmente zusammen etablieren eine einzigartige Nummer; es ist nicht gestattet, diese 75 Stellen lange Nummer zweimal zu haben (Einmaligkeitsbedingung). 7 zeigt ein Beispiel des Inhaltsstammkatalogs.
Die Reihungswerttabellen enthalten die anderen, die Sicherheitsoptionen, Attribute und Eigenschaften aufweisenden Teile der Seriennummer. Sie bieten neue Wege des Sicherheits- und Inhalts-Managements. Aber ebenso bieten sie neue Möglichkeiten einer Suchfunktionalität. Es ist möglich, einfach mit Attributen nach speziellem Inhalt zu suchen, ohne seinen Namen kennen bzw. wissen zu müssen. Zum Beispiel ist es möglich, nach etwas einfach über seine(n) bzw. ihren(n) Farbe, Beschaffenheit oder Beruf zu suchen.
Ein weiterer Task der Reihungswerttabellen ist das Abbilden eines Teils der Seriennummer auf einer Beschreibung. Es ist nicht erforderlich, dass der Systemmanager irgendetwas über die Seriennummernstruktur weiß. Es ist möglich, einen neuen Inhalt in die Datenbank einzufügen und seine Attribute mit Dropdown-Boxen auszuwählen. Diese Kästen können mit Hilfe der Reihungswerttabellen verwirklicht werden, weil sie die benötigte Seriennummer auf der Textbeschreibung abbilden. 8 zeigt ein Beispiel der Reihungswerttabellen.
Alle Reihungswerttabellen sind auf die gleiche Weise konzipiert. Dies ist möglich, weil alle von ihnen denselben Task haben: einem Teil der Seriennummer eine Beschreibung zuzuweisen, folglich habe sie eine Mapping-Funktionalität haben, siehe 9.
Die Seriennummerreihung wird in der Wertespalte aufgewiesen. Das Beschreibungsfeld macht die Nummer für Menschen lesbar und verständlich.
Es gibt Beispiele der Seriennummerreihungen, die in den jeweiligen Reihungswerttabellen definiert werden können:
Activity, ApplicationCode, AdditionalApplicationCode1, AdditionalApplicationCode2, AdditionalApplicationCode3, AgeCode, AgeIdentifier, ArtIDCode, ColorCode, ConsistencyCode, CoolIndex, CountryAvailability, CountryOfOrigin, Creation Time, EducationRange, Expiration, FunIndex, Gender, EnvironmentCode, GovernmentCode, LanguageID, PrivacyCode, ProfessionalCode, RelativeSize, RelativeValueCode, SecurityGroup, SecurityLevel, SexualityCode, SiteCode, SpecialSecurityKey, SpiritualityCode, TextureCode.
Selbstverständlich können noch mehr Reihungen implementiert werden, wie gewünscht.
Nun wird ein Beispiel einer User-Datenbank der Erfindung beschrieben.
Der grundlegende Gedanke ist, ein Gesamt-User-Modell zu haben, in dem jeder User in Beziehung zu jeder Art von Inhalt gesetzt werden kann. Diese Beziehungen zu Inhalt werden durch Verwendung von zwei Arten von Mapping-Tabellen implementiert: Gravity-Mappings, die einen User in Beziehung zu den natürlichen Gruppen eines Inhalts setzen. Und die Peripheral Mappings, die einen User in Beziehung zu den Attributen der zusätzlichen Gruppen eines Inhalts setzen.
Durch die Verfügbarkeit dieses neuen User-Modells, das dem Inhaltsmodell entspricht, sind wir nun in der Lage, dynamische Inhaltsmanagementsysteme zu implementieren. Hierbei muss Inhalt nicht mehr statisch sein, Inhalt ist nun wirklich dynamisch, weil man ständig die Beziehung eines Inhalts zu einem bestimmten User durch Verändern der Mapping-Attribute neuberechnen kann.
Die primären User-Daten werden in der User-Tabelle gespeichert, wovon ein Beispiel in 10 zu sehen ist.
Ein anderer Teil des User-Modells ist die Sessionstabelle (siehe 11). Die Sessionstabelle speichert User-Sessionen, auch mit der Fähigkeit, eine alte Session zu reaktivieren und da fortzufahren, wo ein User seine Session an einem früheren Zeitpunkt verlassen hat.
+Andere Teile des User-Modells sind z.B. Tabellen, die noch mehr User-Information wie Adressen, E-Mails, Telefonnummern, Fax-Nummern, Sicherheitseinstellungen (Sicherheitsstufen und Sicherheitsgruppen) speichern, siehe 12.
Die gespeicherten Sicherheitseinstellungen sind vorteilhaft, da sie an die Sicherheitseinstellungen für jeden Inhalt (in dem CIT-Seriennummernfeld gespeichert) angepasst werden können. Für jeden User-Zugriff auf Inhalt gestattet dies immer auf sehr einfache Weise die Zugriffsrechte zu überprüfen. Dies ist ein sehr wichtiger Vorteil des gegenwärtig beschriebenen Inhalts- und User-Modells.
Eine andere Tabelle, die vorzugsweise enthalten ist, ist die so genannte Gravity-Mapping-Tabelle, die die Beziehung eines Users zu bestimmten Inhaltselementen durch Herstellen einer Beziehung zu Natürliche-Gruppen-Einstellungen der Seriennummer dieses Inhalts speichert Für jeden Inhalt bezeichnet eine Gravity-Zahl (0 = sehr geringe Relevanz, 99 = sehr hohe Relevanz) die Beziehung dieses Inhalts zu einem User, siehe 13 und 14. Mit anderen Worten, die User-Gravity-Tabelle speichert die zwischen einem bestimmten User und einem bestimmten Inhalt ausgeübte "Anziehungskraft" durch Überwachen der Aktivität, wobei diese Intensität an Interaktion zwischen dem User und dem Inhalt mittels der Gravity-Zahl aufgezeichnet wird.
Ein weiterer Teil ist die so genannte Peripheral-Mappings-Tabelle, die die Beziehung eines Users zu bestimmten Inhaltselementen speichert durch Herstellen einer Beziehung zu bestimmten Zusätzliche-Gruppen-Attributen dieses Inhalts. Für jeden Inhalt bezeichnet eine Peripheral-Zahl (0 = sehr geringe Relevanz, 99 = sehr hohe Relevanz) die Beziehung dieses Inhalts zu einem User, siehe auch 15.
Vorzugsweise enthält das Datenbanksystem auch eine Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database"), die die einzige Datenbank ist, auf die durch kundenspezifische Implementierungen irgendwelcher Geschäftslogikelemente (die Geschäftstransaktionsmaschinen ("Business Transaction Engines"), siehe nachstehend) zugegriffen werden kann. Diese Datenbank ist kundenspezifisch anpassbar in der Weise, dass jede Firma sie mit allen notwendigen Tabellen bestücken kann, die sie für ihre unternehmungsbezogene Geschäfts-Applikation benötigt. Die benötigten Geschäftsapplikationen werden in dem BTEs implementiert, die dann auf die Tabellen in der Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") zugreift.
Eine spezielle Tabelle in dieser Verbindung ist die so genannte Produktetabelle, die eine Demonstration davon ist, irgendeine Produktinformation zur Verfügung zu haben, die man zum Implementieren irgendeiner Muster-Auto-Preisbildungs- und -Lagerbestands-Funktionalität benutzen kann. (Die Musterpreisbildungs-BTE ist ihr Gegenstück.) Ein Beispiel wird in 16 gezeigt, siehe Tabelle 161.
Die Produkteinformation ist mit Inhalten in der CIT verbunden, die ihre "Produkt-Flag (Product Flag")" auf richtig gesetzt aufweisen, siehe Tabelle 162 in 16. Alle zusätzliche Information, die sich auf Inhaltselemente bezieht und in irgendeiner Tabelle in der Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") residiert, wird später ebenfalls mit der CIT verbunden.
Geschäftsbetriebssystem ("Business Operating System (BOS)")
Das Geschäftsbetriebssystem ("Business Operating System (BOS)") ist die zentrale Intelligenzeinheit des gesamten Systems. Vorzugsweise implementiert es die gesamte Applikationslogik und ist die einzige Systemkomponente, die auf den Unternehmungsinformations-Cluster ("Enterprise Information Cluster (EIC)") zugreift, d.h. die Datenbank weist die vorstehend beschriebene Struktur auf.
17 zeigt eine Übersicht einer bevorzugten Ausführungsform eines Geschäftsbetriebssystems ("Business Operating System (BOS)").
Eines der primären Design-Features für die modulare Architektur des BOS ist, dass sie in hohem Maße gesichert ist. Das heißt, sie widersteht jeglichen böswilligen Angriffen zum Zweck des Einfügens böswilliger Anforderungen in das System. Nur das CDM ("Central Decision Module") sollte auf die Datenbank, in der alle verfügbare Information aufbewahrt wird, Zugriff haben. Andere Aspekte von Sicherheit schließen die Authentisierung von jeder Anforderung bei ihrem Sender ein.
Das BOS ist in der Lage, sich an andere Geschäftsmanagementsysteme ("Business Management Systems") (wie z.B. SAP oder EDS) anzupassen, sowie an externe Systeme, die möglicherweise die Transaktionsfunktionalität des BOS benutzen möchten. Beispiele sind AdServer, Suchmaschinen oder andere.
Das BOS-Untersystem ist für die Bewältigung zukünftiger Entwicklungen konzipiert. Die Funktionalität des BOS (insbesondere das CDM) ist auf alle Arten von Bedürfnissen irgendeines zukünftigen Kunden anpassbar. Genauer gesagt, jegliche Funktionalität, an die während der anfänglichen Implementierungsbeschreibung nicht gedacht worden ist, sollte dem System später zu jeder Zeit hinzugefügt werden können, ohne das System zu modifizieren.
Obwohl das BOS möglicherweise komplexe Rechnungen zu verarbeiten haben wird, ist die Gesamtgeschwindigkeit sehr hoch, sogar wenn es viele User auf einmal gibt.
Herkömmliche Inhaltsmanagementsysteme sind sehr statische Applikationen, die auf eine Vielfalt verschiedener Transaktionsbedürfnissen nicht angepasst werden können. Dies bedeutet, dass falls sich die Anforderungen für Inhaltsmanagement verändern, muss das gesamte System ersetzt werden oder zumindest ein großer Teil davon muss verändert und enormen Modifikationen unterzogen werden.
Die vorliegende Erfindung stellt eine sehr modulare und erweiterbare Architektur für das BOS vor. Die Haupt-Features für das BOS sind:

1) Eine sehr strikte Trennung von direkter Verarbeitungsarchitektur und die tatsächliche Implementierung von Geschäfts- und Applikations-Logik. Dies bietet die Möglichkeit zum späteren jederzeitigen Hinzufügen oder Ersetzen bestimmter Geschäftstransaktionsfunktionalität zu bzw. an dem System.
2) Die Fähigkeit sich an Geschäftsmanagementsysteme Dritter anzuschließen. Damit kann man zu bestehenden Altsystemen, die eine Firma möglicherweise noch benutzen will, eine Brücke schlagen.
3) Eine sehr offene Architektur für das Integrieren externer Systeme. Dies schafft die Fähigkeit, andere externe Systeme einen Teil der Funktionalität der BOS-Implementierungen nutzen zu lassen, wie das Anbieten der großen Suchfähigkeiten für besonderen Inhalt an bestimmte Suchmaschinen.
4) Ein zentrales Management-Tool, das die notwendigen Konfigurationen und Wartungsbetriebe an dem BOS ausführt.

Diese Anforderungen führten zu eine sehr modularen und strukturierten Aufbau des BOS, das in 18 gezeigt wird. Der Anforderungsabwickler ("Request Dispatcher") 181 und das Seitenerstellungselement ("Page Composer") gehören zu dem dritten Tier und sollen später beschrieben werden. Ein einzelnes Gate 183 ist vorgesehen für die Behandlung von in das BOS eingehenden Nachrichten, sei es von einem Kommunikationsmodul (das einen Anforderungsabwickler ("Request Dispatcher") 181 umfasst), von einer externen Schnittstelle ("Docking") 184 oder von einer Gate-Schnittstelle 185. Eine BOS-Maschine verteilt die Anforderungen an entsprechende Transaktionskanäle, wobei ein Datenbankzugang, Geschäftslogik von einer oder mehreren Geschäftstrabsaktionsmaschinen 187 einbeziehend, Daten bereitstellt, die dann in einem Element 188 vorbereitet werden.

ad 1) Die tatsächliche Geschäfts- und Inhalts-Transaktionsfunktionalität ist völlig getrennt von der architektonischen Implementierung, die sie liefert. Die Transaktionsarchitektur ist zu jeder Zeit dieselbe, ganz gleich was die benötigte Geschäftslogik jeweils erfordern mag. Jegliche Art von Geschäftlogik wird dem System mittels dynamischer Plugins, die Geschäftstransaktionsmaschinen ("Business Transaction Engines (BTEs)") genannt werden, hinzugefügt. Diese BTEs allein liefern die komplette Geschäftslogik-Implementierung. Deshalb ist es leicht zu verändern, hinzuzufügen oder sogar bestimmte Funktionalitäten zu löschen, einfach durch Aktivieren oder Deaktivieren der jeweiligen BTE.
ad 2) Das CDM bietet eine Gate-Schnittstelle, um eine Brücke zu bestehenden Altsystemen einer Firma zu schlagen.
ad 3) Externe System Dritter können – falls autorisiert – selbst bestimmte Anforderungen starten, die in das BOS eingehen können und auf die gleiche Weise behandelt werden wie interne Mitteilungen.
ad 4) Ein zentrales Management-Tool wird ebenfalls bereitgestellt

Das BOS kann als eine durch eine Fassadenschnittstelle gekapselte Komponente betrachtet. Sie verbirgt verschiedene Komponenten, die nachfolgend beschrieben werden, siehe 19.
Andererseits können die Module auch in einem Drei-Tier-Architekturmodul klassifiziert werden. Die Gate-Schnittstelle und die externen Dockings an das CDM bilden den ersten Tier. Sie sind die Brücke für externe Systeme zu dem BOS. Die BOS-Maschine ("BOS Engine"), die BOS-Mittel (BOS Agents") und die Transaktionskanäle sind eine abgetrennte Einheit von Applikationslogik, die nur die Plattform für Geschäfts- und Inhalts-Transaktionen bereitstellt. Die Transaktionsfunktionalität ist ausschließlich in den BTEs implementiert. Sie sind der dritte Tier und halten die Implementierungen von Geschäftslogik auf eine sehr modulare Weise.
Das BOS-Gate 183/191 ist der Eingang zu dem CDM. Es ist der einzige Weg auf dem irgendwelche System-Mitteilungen/-Anforderungen in das CDM eintreten können. Alles muss durch dieses Tor gehen. Das BOS-Gate kann Sicherheitsüberprüfungen anstellen und dann leitet es die System-Mitteilungen/-Anforderungen an die BOS-Vermittlung bzw. -Agentur ("BOS Agency") 192 weiter. Anforderungen, die an dem BOS-Gate ankommen, können z.B. von mindestens drei verschiedenen Quellen kommen:

– Das w³OS (oder andere Kommunikationskanäle)
– Interne Schnittstellen (GATES)
- Externe Dockings

Für diese Systeme bestehen zwei Unterkategorien von Gates: EIN-Gates und AUS-Gates. Sie sind der jeweilige Typ von Gate für eingehende Nachrichten an das BOS und von dem BOS zurück an ein bestimmtes System ausgehende Nachrichten.
Während des Betriebs könnten wir bei einem laufenden BOS z.B. die folgenden Gates vorfinden: Ein w³OS-EIN-Gate und eine SAP-EIN-Gate, die beide von dem w³OS- und einem bestehenden SAP-System stammende eingehende Nachrichten an das BOS-EIN-Gate weiterleiten und andererseits ein w³OS-AUS-Gate sowie ein SAP-AUS-Gate bearbeiten, die von dem BOS-AUS-Gate ausgehende Nachrichten zu dem ordnungsgemäßen Empfangssystem, entweder der w³OS- oder der SAP-Applikation, delegieren.
Deshalb führen wir eine sehr abstrakte und flexible Gesamtstruktur allgemeiner Gates ein, siehe 20.
Für jedes Paar eines bestimmten Typs von EIN- und AUS-Gates möchten wir unter Verwendung des Singleton-Musters die Klasse implementieren, wobei wir sicherstellen, dass wir bei jeglichem vorgegebenen Typ immer nur einen einzelnen Fall eines EIN- oder AUS-Gates haben.
Wenn eine eingehende Anforderung an dem BOS-EIN-Gate in eine interne Systemmitteilung umgesetzt wird, wird sie auch an Attribute weitergegeben, die die Anforderungsquelle und das Ziel der Antwort auf die Anforderung berücksichtigen müssen. Angesichts dieses Mechanismus wollen wir in der Lage sein, bestimmte Prozesse sehr flexibel zu routen. Während der Verarbeitung von jeder Anforderung können wir im laufenden Betrieb bestimmen (auch unter Berücksichtigung ihrer Quelle), wohin die Antwort zu senden ist. Quelle und Ziel könnten sich sehr wohl voneinander unterscheiden.
Vorzugsweise ist ein separates Gate für die visuellen Tools vorgesehen. Deshalb müssen wir ein separates VTools-EIN-Gate und ein separates VTools-AUS-Gate berücksichtigen, die spezielle VToolsSystem-Mitteilungen ("VToolsSystemMessages") behandeln.
Die BOS-Vermittlung bzw. -Agentur ("BOS Agency") 192 ist der zentrale Initiator von jeglichem in dem BOS ausgeführten Inhaltstransaktionsmanagement. Tatsächlich parst die Agentur eingehende Anforderungen, erzeugt BOS-Mittel ("BOS Agent") für jeden Anforderungstyp und sendet dieses Mittel ("Agent") mit der Anforderung zum Ausführen der erforderlichen Transaktions-Tasks ab. Jedes BOS-Mittel ("BOS Agent") erhält auf der Grundlage des Typs einer eingehenden Anforderung eine anfängliche Task-Liste. Auf der Grundlage ihrer Task-Liste sendet die BOS-Vermittlung bzw. -Agentur das Mittel ("Agent") an die jeweiligen Transaktionskanäle ("Transaction Channels"), um auf die BTE zuzugreifen, die die erforderlichen Tasks an dem BOS-Mittel ("BOS Agent") durchführen wird.
Die Hauptfunktionalitäten der BOS-Vermittlung bzw. -Agentur ("BOS Agency") sind die folgenden:

– Einreihen von System-Mitteilungen/-Anforderungen, die von dem BOS-EIN-Gate kommen
– Erzeugung von BOS-Mitteln ("BOS Agents")
– Abbilden eingehender System-Mitteilungen/-Anforderungen auf den registrierten Typen von BOS-Mitteln ("BOS Agents")
– Konfigurieren von BOS-Mitteln ("BOS Agents")
– Speichern von BOS-Mitteln ("BOS Agents")
– Starten der BOS-Mittel ("BOS Agents")
– Flusssteuerung von BOS-Mitteln ("BOS Agents")

Die Erzeugung von neuen BOS-Mitteln ("BOS Agents") kann auf drei Weisen initiiert werden:

• Durch das BOS-Gate 191, das die BOS-Maschine 193 anweist, ein neues Mittel ("Agent") für bestimmte eingehende System-Mitteilungen/-Anforderungen zu starten.
• Durch eine Geschäftstransaktionsmaschine ("Business Transaction Engine (BTE)") 194 während der Durchführung irgendeines Tasks, der das Starten eines Spin-Oft-Eskaltionsprozesses erfordert. Ein neues BOS-Mittel ("BOS Agent") wird diesen Eskalationsprozess implementieren.
• Durch eine BTE, die ein Timer-Mittel ("Timer Agent") startet, das nur zu bestimmten Zeiten ohne ansteuerndes Geschehnis laufen gelassen wird.

Auf diese Weise ist es möglich, unbegrenzte Eskalationsvorgänge zu implementieren.
Im Grunde benötigt die BOS-Vermittlung bzw. -Agentur (BOS Agency") immer irgendwelche Entscheidungen, bevor sie irgendwelche Mittel ("Agent") startet: Als Erstes muss sie feststellen, von welchen Typ die eingehende Anforderung ist und welches das entsprechende Mittel ("Agent") ist, das es zum Starten dieser Anforderung benötigt. Und als Zweites muss sie die anfängliche Zieladresse des erzeugten Mittels feststellen. Das bedeutet, sie muss für einen bestimmten Typ von Anforderung bestimmen, auf welchen Transaktionskanal ("Transaction Channel") sie das Mittel ("Agent") setzen muss, so dass es von der ordnungsgemäßen BTE, die diesen Kanal abhört, abgeholt werden kann. Um die erwähnten Entscheidungen während des Anlaufs eines Mittels und seiner Flusssteuerung zu treffen, nutzt die BOS-Vermittlung bzw. -Agentur ("BOS Agency") die BOS-Registrierungsberechtigung in hohem Maße. Hauptsächlich benutzt es sie, um Abbildungen von Anforderungstypen auf Typen von Mitteln ("Agents") oder Abbildungen von BTEs auf Transaktionskanälen ("Transaction Channels") nachzuschlagen.
Durch Default wird ein BOS-Mittel ("BOS Agent") immer durch die folgende Folge von Kanälen gehen: Den Logistikkanal ("Logistics Channel"), den Finanzkanal ("Financial Channel") und den Ausführungskanal ("Execution Channel"). Jedoch kann diese Folge in speziellen Fällen durch Entscheidungen, die in irgendeiner BTE getroffen wurden, abgeändert werden.
Die BOS-Registrierungsberechtigung ("BOS Registration Authority") 195 ist die zentrale Komponentenregistratur des BOS. Sie wird von der BOS-Vermittlung bzw. -Agentur (BOS Agency") häufig während der Mittelerzeugung und Flusssteuerung benutzt und sie enthält Information über die folgenden Komponenten:

• Installierte Transaktionskanäle ("Installed Transaction Channels"). Irgendein Transaktionskanal ("Transaction Channel"), der unter Verwendung des Managers installiert wird, muss hier registriert werden.
• Installierte Geschäftstransaktionsmaschinen ("Business Transaction Engines (BTEs)"). Alle installierten BTEs, die in dem Manager aktiv gestellt sind, sind in der BOS-Registrierungsberechtigung ("BOS Registration Authority") registriert. Dies wird für die BOS-Vermittlung bzw. -Agentur (BOS Agency") benötigt zum Nachschlagen, welche Arten von BTEs installiert und am Laufen sind und welche Funktionalität sie bereitstellen.
• Existierende Typen von BOS-Mitteln ("BOS Agents"). Alle Typen von BOS-Mitteln ("BOS Agents") werden per Default in der BOS-Registrierungsberechtigung registriert. Wann immer eine neue BTE installiert wird (und mit ihr eine neue Art von BOS-Mittel ("BOS Agent")) muss auch der neue Mitteltyp registriert werden.

Abgeleitet von dieser Information enthält sie auch Abbildungen von irgendeiner Information:

• BTE-auf-Kanal-Mapping ("BTE to Channel Mapping"): Enthaltene Information, welche BTEs auf welchem Transaktionskanal ("Transaction Channel") installiert sind. Die BOS-Vermittlung bzw. -Agentur ("BOS Agency") muss diese Information nachschlagen, um zu bestimmen, wohin ein Mittel ("Agent") gesendet werden soll, damit es von einer bestimmten BTE abgeholt werden kann.
• Anforderungen-auf-Mittel-Mapping ("Request to Agent Mapping"): Beschreibt welche Klassen von Anforderungen durch welchen Typ von BOS-Mittel ("BOS Agent") bearbeitet werden sollen. Dies wird für die BOS-Vermittlung bzw. -Agentur (BOS Agency") benötigt zum Bestimmen welcher Typ von Mittel ("Agent") für eine eingehende Anforderung initialisiert werden muss.

21 zeigt ausführlicher die Aktionen innerhalb der BOS-Registrierungsberechtigung.
Der BOS-Sessionsmanager ("BOS Session Manager") verwaltet interne Sessionen. Wir begründen das Bestehen unterschiedlicher Sessionsmanager für alle Arten unterschiedlicher Systeme, die auf das CDM in der Zukunft zugreifen werden. Man kann z.B. einen separaten Sessionsmanager für SAP-Sessionen haben oder einen unterschiedlichen Sessionsmanager für eine Suchmaschinensession in dem BOS.
22 zeigt ein UML-Diagramm der Suchmaschinen-Managerhierarchie.
Inhaltstransaktionsmanagement ("Content Transaction Management") findet immer in dem Geschäftsbetriebssystem ("Business Operating System (BOS)") statt. Es wird vorzugsweise in drei Stufen durchgeführt:

• PHASE 1: Zuerst werden alle möglichen Inhaltsseriennummern und ihre damit zusammenhängende Information werden aus der Inhaltsdatenbank innerhalb des EIC abgerufen.
• PHASE 2: Nun wird alle notwendige Verarbeitung der Inhaltsseriennummer durchgeführt. Es ist möglich, dass einige Inhaltsseriennummern auf Grund irgendwelcher Ausschlussbedingungen während der Verarbeitungsphase fallen gelassen werden, aber keine zusätzlichen Seriennummern sollten während der PHASE 2 hinzugefügt werden. Andere zusätzliche Information, wie Preisbildung zum Beispiel, könnte von der Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") abgeholt werden. All diese verschiedenen Arten zusätzlicher Information werden zu den Seriennummern gepackt.
• PHASE 3: Hier wird der ganze tatsächliche Inhalt von der Inhaltsdatenbank ("Content Database") abgeholt und in eine präsentierbare Form gebracht. Dies ist die Stelle, wo Ansichten eintreten. In dieser letzten Phase wird der ganze anwendbare Inhalt abgeholt und wenn er präsent ist, werden die Entscheidungen für Layouts getroffen, zusammengepackt und an das BOS-Gate gesendet.

Diese drei Funktionsgruppen von SCHRITT 1 (Abholung der Inhaltsinformation), SCHRITT 2 (zusätzliche Informationsverarbeitung) und SCHRITT 3 (Abholung von tatsächlichem Inhalt, zusätzliche Layout-Verarbeitung und Zusammenpacken) können drei Transaktionskanälen ("Transaction Channels") zugeordnet werden:
Das meiste der Implementierung der Funktionalität von PHASE 2 wird durch das Implementieren der Geschäftstransaktionsmaschinen ("Business Operation Engines (BTEs)") durchgeführt. Spezielle BTEs können ebenfalls zum Erzielen eines Teils der Funktionalität von PHASE 1 und PHASE 3 verwendet werden. Jedoch ist der Hauptunterschied der, dass wir bei dem Finanzkanal ("Financial Channel") nur kundenspezifisch konzipierte BTEs zulassen wollen, die selbst Zugriff auf die Finanz-/Geschäfts-Datenbank haben. Jegliche BTEs die in der PHASE 1 oder PHASE 3 müssen vorinstallierte Default-BTEs sein. Sie können nicht ersetzt oder deaktiviert werden, da sie die einzigen mit Zugriff auf die Inhalts-DB und die User-/Dockings-DB sind und sein müssen.
Transaktionskanäle ("Transaction Channels") sind ein Weg, bestimmte BTEs und ihre Funktionen (z.B. alle Finanz-BTEs oder BTEs die Buchhaltungsinformation liefern) und ihren Datenbankzugriff zusammenzugruppieren. Per Default befinden sich in der BOS drei verschiedene Transaktionskanäle:

1. Der Logistikkanal ("Logistics Channel")
2. Der Finanzkanal ("Financial Channel")
3. Der Ausführungskanal ("Execution Channel")

Normalerweise greift ein BOS-Mittel ("BOS Agent") auf diese drei Transaktionskanäle ("Transaction Channels") in der vorstehend erwähnten Reihenfolge zu. Nachdem jeder Kanal seine Ausführung beendet hat, wird ein Mittel ("Agent") mit einem die Beendigung eines Kanals anzeigenden Flag zurück an die Agentur geroutet. In speziellen Fällen kann die Vermittlung bzw. Agentur ("Agency") das Mittel ("Agent") auf einem von dem Default unterschiedlichen Pfad erneut routen, z.B. es mehrere Male zu dem Finanzkanal zum Abholen zusätzlicher Information senden bevor sie es zu dem Ausführungskanal sendet.
Der Transaktionskanal ("Transaction Channel") selbst führt keine tatsächliche Arbeit aus. Alles was er tut ist, dass er die BTE veranlasst, sich anzuschließen und dann BOS-Mittel ("BOS Agents") zu routen, die sich auf dem Kanal zu der richtigen BTE bewegen. Durch die Einführung von Transaktionskanälen ("Transaction Channels") können wir die Fähigkeit der BTE, nur bestimmte Kanäle abzuhören, beschränken. Z.B. könnten wir eine bestimmte BTE veranlassen, nur den Finanzkanal abzuhören. Eine andere könnte den Logistikkanal oder den Ausführungskanal abhören. Die Entscheidung, auf welchem Kanal ein BOS-Mittel ("BOS Agent") gesendet wird, wird durch die BOS-Vermittlung bzw. -Agentur (BOS Agency") getroffen.
23 zeigt ein UML-Diagramm der Kanalhierarchie.
BOS-Mittel ("BOS Agent") sind Ausführungsobjekte, die durch die BOS-Agentur erzeugt und dann auf bestimmten Transaktionskanälen ("Transaction Channels") gesendet werden. Eine eingehende Anforderung an die BOS-Vermittlung bzw. -Agentur ("BOS Agency") weist immer einen passenden oder entsprechenden Typ von BOS-Mittel ("BOS Agent") auf, das zum Transportieren dieser Anforderung an die entsprechende BTE geschaffen ist. Diese BTE holt dann das Mittel ("Agent") von dem Transaktionskanal ("Transaction Channel") ab und führt die notwenigen Tasks auf der in dem Mittel ("Agent") enthaltenen Anforderung aus.
Auf der Grundlage des eingehenden Anforderungstyps muss die BOS-Vermittlung bzw. -Agentur ("BOS Agency") in der Lage sein zu entscheiden, welche Art von Mittel ("Agent") für diese Anforderung zu erzeugen ist.
Jedes BOS-Mittel ("BOS Agent") muss drei Boole'sche Flags aufweisen, die jedes Mal anzeigen, wenn ein Mittel seine Bewegung durch einen bestimmten Transaktionskanal beendet hat. Diese Flags sind bLChannelDone für Beendigung des Logistikkanals ("Logistics Channel"), bFChannelDone für die Beendigung des Finanzkanals ("Financial Channel") und bXChannelDone für die Beendigung des Ausführungskanals ("Execution Channel"). Die Quelle- und Ziel-Attribute eines BOS-Mittels ("BOS Agent") zeigen an, woher die ursprüngliche Anforderung kam und wohin die zusammengestellte Antwort zu senden ist.
Es bestehen drei verschieden Arten von BOS-Mitteln ("BOS Agents"):

• w³OS-Mittel ("w³OS Agents"): Diese Mittel werden zum Behandeln oder Transportieren von Anforderungen erzeugt, die von dem Web-Betriebssystem (w³OS) eingehen.
• Systemmittel ("System Agents"): Bestimmte planmäßige Timer-Ereignisse triggern die Erzeugung von Systemmittel. Sie werden für die Durchführung bestimmter System-Tasks verwendet, die im Hintergrund durchgeführt werden können.
• BTE-Mittel ("BTE Agents"): Diese Mittel werden erzeugt, um Tasks zu bearbeiten, die während der Ausführung bestimmter Transaktionen in einer BTE getriggert worden sind.

24 zeigt ein UML-Diagramm der Mittelhierarchie.
Nun sollen die Geschäftstransaktionsmachinen ("Business Transaction Engines") ausführlicher beschrieben werden. Die Geschäftstransaktionsmaschinen ("Business Transaction Engines (BTEs)") nehmen die tatsächliche Geschäftslogik auf. Immer zusammen mit einer BTE und ihrer Funktionalität bestehen bestimmte Typen von BOS-Mitteln ("BOS Agents"), die zu ihrer Funktionalität passen. BTEs sind der Teil des Systems, der zu einer kundenspezifischen Konzipierung fähig sein muss, um alle Arten von verschiedenen, für die unterschiedlichen Typen von Geschäftsapplikationen benötigte Funktionalitäten aufzunehmen. Jedes Mal wenn eine neue BTE mit einem neuen Satz Funktionalitäten entwickelt wird, dann wird es einen neuen Typ von BOS-Mittel ("BOS Agent") geben, der auf den neuen BTE-Funktionen abgebildet wird. Eine BTE schließt sich bestimmten Transaktionskanälen ("Transaction Channels") an und wartet auf BOS-Mittel ("BOS Agents") die passen. Sobald der Kontakt hergestellt worden ist, startet das Mittel ("Agent") ihr Durchführungsverfahren und ruft die Funktionalität der BTE dazu auf, auf ihre Daten einzuwirken.
Wie in dem Abschnitt über Transaktionskanäle ("Transaction Channels") beschrieben, sollten nur diese BTEs kundenspezifisch konzipiert werden, die Zugriff auf die Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") haben. Vorzugsweise sollte es keinerlei kundenspezifischen BTEs ("Custom BTEs") für das Zugreifen auf oder sogar Modifizieren irgendwelche(r) Inhaltsdaten in der Inhaltsdatenbank ("Content Database") oder irgendwelche(r) User-bezogenen Daten in der User-/Dockings-Datenbank geben. Deshalb sind vorzugsweise nur BTEs zugelassen, die kundenspezifisch konzipiert werden, um sich den Finanztransaktionskanälen ("Financial Transaction Channels") anzuschließen und nicht den Logistik- oder Ausführungs-Kanälen.
Es bestehen verschiedene Typen von BTEs. Man kann alle BTEs in mindestens zwei separate Gruppen teilen:

• System-BTEs, die durch Default installiert werden. Diese BTEs kommen mit dem Grundprodukt und können nicht unwirksam gemacht, ersetzt oder aus dem System entfernt werden. Sie werden grundsätzlich für das ordnungsgemäße Funktionieren des Systems benötigt.
• Kundenspezifische BTEs ("Custom BTEs"), die in das Grundsystem eingeklinkt werden können. Sie stellen einfach zusätzliche Funktionalität bereit, können aber auch unwirksam gemacht oder entfernt werden, ohne das Grundsystem in seinen Funktionen zu beeinflussen.

Einher mit der Gruppierung von System-BTEs und kundenspezifischen BTEs ("Custom BTEs") geht die Unterscheidung von BTE-Zugriff auf die Datenbank. Da kundenspezifische BTEs ("Custom BTEs") später kundenspezifisch entwickelt und von einer Anzahl verschiedener Entwickler eingesetzt werden sollen, ist es wünschenswert, diese BTEs von einem Zugriff auf entscheidende Systemdatenbanken wie die Inhaltsdatenbank ("Content Database") [(Inhaltsinformationstabelle ("Content Information Table (CIT)"), Inhaltstabelle (Content Table (CT)"), Stammkatalogtabelle ("Master Catalog Table (MCT)") und Ansichtentabelle (View Table (VT)")] und die User-/Dockings-Datenbank (User-Tabelle, Dockings-Tabelle) auszuschließen.
Andererseits sollte man den kundenspezifischen BTEs ("Custom BTEs") Zugriff auf die Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") gewähren, ansonsten wären die kundenspezifische BTEs ("Custom BTEs") nicht im Stande irgendwelche Entscheidungen zu treffen, weil sie keine Information für die Beweisführung hat. Diese Unterscheidung, die wir hier vornehmen, wird durch die Tatsache untermauert, dass wir kundenspezifischen BTEs ("Custom BTEs") nur gestatten wollen, sich dem Finanztransaktionskanal ("Financial Transaction Channel") anzuschließen, der lediglich Zugriffsrechte zum Verbinden mit der Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") und keiner anderen Datenbank innerhalb des EIC hat. Um es zusammenzufassen, dies bedeutet: Kundenspezifische BTEs ("Custom BTEs") können sich nur dem Finanztransaktionskanal ("Financial Transaction Channel") anschließen und haben nur Zugriff auf die Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database").
Dies bedeutet auch, dass kundenspezifische BTEs ("Custom BTEs") irgendwelche Funktionen der Default-System-BTE zu nutzen hat, weil alleine sie Zugriff auf inhaltsbezogene und User-bezogene Daten hat. Zum Beispiel muss eine kundenspezifische BTE ("Custom BTE"), die irgendeine Finanzentscheidung bezüglich irgendwelcher Produkte einer Firma zu treffen hat, als Input irgendeine Seriennummerinformation über die Inhaltselemente empfangen, über die sie Entscheidungen zu treffen hat.
Man kann alle System BTEs in drei Gruppen teilen:

1. System-BTEs die sich ausschließlich dem Logistiktransaktionskanal ("Logistics Transaction Channel") anschließen;
2. System-BTEs, die sich ausschließlich dem Ausführungstransaktionskanal (Execution Transaction Channel") anschließen; and
3. System-BTEs, die sich sowohl dem Logistiktransaktionskanal ("Logistics Transaction Channel") als auch dem Ausführungstransaktionskanal (Execution Transaction Channel") anschließen.

Wir finden folgende BTEs in den erwähnten Kategorien vor:
Kategorie 1: USER-BTE, SERIENNUMMERN-BTE
Kategorie 2: INHALTS-BTE, ANSICHTEN-BTE
Kategorie 3: VISUELLE-TOOLS-BTE("VTOOLSBTE")
Beispiele von kundenspezifischen BTEs sind:
LAGERBESTANDS-BTE, PREISBILDUNGS-BTE, ...
Während einer "normalen", in dem CDM durchgeführten Verarbeitung haben wir immer die folgende Reihung von BTE-Aktionen: Zuerst erhält die USER-BTE in dem Logistiktransaktionskanal ("Logisitcs Transaction Channel") alle User-Information, am wichtigsten die Sicherheitseinstellungen des Users. Diese Information wird von diesem Punkt an durch jede BTE-Verarbeitung hindurch benutzt. Als Nächstes, noch in dem Logistiktransaktionskanal ("Logisitcs Transaction Channel"), holt die SERIENNUMMERN-BTE die ganze Inhalts-Metainformation ab. Üblicherweise wird sie eine Suche nach Seriennummer-Spannweiten durchführen, wobei die Sicherheitseinstellung des Users berücksichtigt wird. Die SERIENNUMMERN-BTE sendet eine anfängliche Nummer oder Inhaltsseriennummern ("Content Serial Numbers") und ihre Inhaltsinformationstabellen-IDs ("Content Information Table IDs") zurück. Diese Information kann nun in allen späteren Schritten der Inhaltsverarbeitung durch alle folgenden BTEs benutzt werden.
In den folgenden Schritten treten sich dem Finanztransaktionskanal ("Financial Transaction Channel") anschließende BTEs ein. Nun können sie ihre notwendigen Funktionen an dem Inhalt durchführen und sie können auch auf alle Tabellen in der Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") zugreifen, um ihre Entscheidungen zu stützen und zusätzliche Information abzuholen oder Information an die Finanz-/Geschäftsfluss-Datenbank ("Financial/Business Flow Database") zu schreiben.
Nachdem alle der BTEs des Finanztransaktionskanals ("Financial Transaction Channel") ihre Arbeit beendet haben und alle zusätzlich benötigte Information zu der ursprünglichen User-Information und den Inhaltsseriennummer ("Content Serial Number")n gepackt haben, leiten sie diese Information auf dem Ausführungstransaktionskanal ("Execution Transaction Channel") weiter.
Auf dem Ausführungstransaktionskanal ("Execution Transaction Channel") geht die Inhalts-BTE ("Content BTE") durch den Satz von Inhaltsseriennummern ("Content Serial Numbers"), die an sie übergeben worden sind und holt dann den entsprechenden tatsächlichen Inhalt von der Inhaltstabelle ("Content Table") innerhalb der Inhaltsdatenbank ("Content Database") ab. Danach übergibt sie die ganze Information (User, Inhaltsseriennummern, zusätzliche Finanz-/Geschäfts-Daten und den tatsächlichen Inhalt) an die ANSICHTEN-BTE. Die BTE betrachtet nun die verfügbare Information und trifft Entscheidungen über die Ansichten, um diese bestimmte Anordnung von Inhalten auszuwählen. Deshalb greift sie auf die Ansichtentabelle zu, holt die Ansichtsinformation ab und stapelt dann den ganzen Inhalt und seine Ansichten in eine individuelle kundenspezifische Seite. Zum Schluss sendet die Ansichten-BTE das Seitendatenobjekt ("PageData object") an sein Ziel.
Eine andere BTE ist die Seriennummern-BTE ("SerialNumberBTE"). Die Seriennummern-BTE ("SerialNumberBTE") wirkt auf den Logistikkanal ("Logistics Channel") ein und greift nur auf die Inhaltsinformationstabelle ("Content Information Table") in der Inhaltsdatenbank ("Content Database") zu.
Die Kriterien, die für das Auswählen bestimmter Seriennummern durch die BTE wichtig sind, sind im Wesentlichen irgendwelche Attribute innerhalb der Inhaltsseriennummer (eine bestimmte Alterseignungs-Spannweite, ...) und auch immer die Sicherheitseinstellungen des Users. Z.B. falls die Sicherheitsstufe eines Users 5 ist, dann können nur Seriennummern mit Sicherheitseinstellungen von 5 oder niedriger ausgewählt werden.
Ein anderes Beispiel einer BTE ist eine Preisbildungs-BTE. Die folgende Preisbildungs-BTE ist ein sehr einfaches Beispiel einer typischen kundenspezifischen BTE ("Custom BTE"). Im Grunde kann irgendeine gewünschte Funktionalität in der BTE implementiert werden. Die gegenwärtig beschriebene Preisbildungs-BTE führt Preiskalkulationen durch. Z.B. erhöht sich der Preis eines Produkts automatisch, falls irgendeine von zwei Bedingungen zutrifft:

1. Die Anzahl der innerhalb der letzten 24 Stunden verkauften Einheiten ist niedriger als die Umsatzkennziffer.
2. Der Lagerbestand dieses Produkts sinkt unter das Lagerbestands-Limit.

Der Preis des Produkts sinkt, falls irgendeine der beiden Bedingungen zutrifft:

1. Die Anzahl der verkauften Einheiten liegt über der Umsatzkennziffer
2. Der Lagerbestand des Produkts war unter dem Lagerbestands-Limit und ist dann über das Lagerbestands-Limit gestiegen.

Auch die Preisbildungs-BTE schließt sich dem Finanzkanal an und wirkt auf zusätzliche Lagerbestandseinheiten ein und aktualisiert die Lagerbestands- und Preisbildungs-Information in der Produktetabelle.
Vorzugsweise residiert ein Datenbankmodul innerhalb des BOS und wirkt als Verbindungselement zu allen Datenbanken innerhalb des Unternehmungsinformations-Clusters ("Enterprise Information Cluster (EIC)").
Interne Schnittstellen ("GATES") bilden eine Eingangsstelle für bestehende Geschäftsmanagementsysteme wie SAP oder EDS in das Geschäftsbetriebssystem ("Business Operating System (BOS)"). Sie schließen sich an Altsysteme an und ermöglichen eine Datenübertragung.
Die Externen Schnittstellen und Dockings stellen einen Weg für Applikationen Dritter dar, das BOS zu nutzen. Die Externen Schnittstellen ("Dockings") greifen durch das BOS-Gate auch auf das CDM zu. Musterapplikationen, die auf das BOS zugreifen könnten, sind Suchmaschinen, Werbeanzeigen-Server oder viele andere.
Die Kommunikationskanäle
Alle Kommunikationskanäle befinden sich in dem Darstellungs-Tier (dritter Tier). Sie sind Mittel zum Interagieren mit Endusern oder um ihnen Inhalt darzustellen. Das System integriert alle Zugreifen auf das BOS verfügbaren Technologien. Jeder Kommunikationskanal greift durch spezielle EIN-Gates auf das BOS zu und empfängt am anderen Ende Daten aus seinem jeweiligen AUS-Gate.
Jeder Kommunikationskanal selbst ist verantwortlich für das Aufrecherhalten von Sessionsmanagement und das Durchführen dieser notwendigen Tasks. Ferner führt jeder Kommunikationskanal selbst das richtige Formatieren der von dem BOS empfangenen Inhaltsdaten durch. Z.B. formatiert das Seitenerstellungselement ("Page Composer") einzelne Webseiten für Internet-Browser für das w³OS.
Die Aktiven Kommunikationskanäle ("Active Communication Channels") routen Inhalt lediglich in eine Richtung: Von dem Geschäftsbetriebssystem an den Enduser. Es findet keine wirkliche User-Interaktion statt. Die Aktiven Kommunikationskanäle ("Active Communication Channels") sind lediglich ein Mittel zum Darstellen von Daten. Ihre hauptsächlichen operativen Gebiete können automatisiertes Nachrichtensenden oder Werbeanzeigen sein. Im Folgenden werden Beispiele von Aktiven Kommunikationskanälen ("Active Communication Channels") abgegeben:

• Ein Kurznachrichtenservice-Betriebssystem bietet Datentransfer über Mobiltelefone und Pager.
• Ein Betriebssystem für automatischen Datentransfer über Telefon kann automatisch vordefinierte und dynamisch erzeugte Telefonnachrichten an jeden bei dem System Registrierten aussenden.
• Ad-OS – Ein Werbeanzeigen-Betriebssystem, das unter Verwendung von Beamern, Videoprojektion oder Fernsehschirmen individuell kundenspezifische Werbeanzeigen zu fest zugeordneten Stellen stellt.
• RTS-OS – Ein Lauftext-Betriebssystem, das Tickermeldungen und Lauftextanzeigen für Börsen-Angebote oder -Meldungen, verwaltet.

Beispiele interaktiver Kommunikationskanäle, die eine User-Interaktion mit dem BOS zulassen, sind:

• w³OS – Das Web-Betriebssystem (w³OS) ist der Schwerpunkt interaktiver Kommunikationstechnologien. Es verwendet XML und die revolutionäre vorstehend beschriebene One-Page-Web-Technologie, um über das Internet auf jedermann zuzugreifen und von jedermann benutzt zu werden.
• PDA-OS – Ein Persönliches Datenmanagement-Betriebssystem, das die Integration von persönlichen digitalen Assistenten und Palmtop-Computern bietet,
• ITV-OS – Ein interaktives Fernseh-Betriebssystem, das interaktives Fernsehen mit dem gesamten System integrieren wird.
• Mail-OS – Ein Mail-Betriebssystem, das große Berichtsmechanismen anbietet, wie Versenden von auto-erzeugten E-Mails, die durch Eskalationsabläufe in dem BOS herausgegeben werden.
• Fax-OS – Ein Fax-Betriebssystem, das auch große Berichts-Features und Empfängermechanismen bereitstellt.
• Telex-OS – Ein Telex-Betriebssystem, das das Gate zu alten Telexsystemen weltweit ist.
• I-OS – Ein Lagerbestands-Betriebssystem, das auf der Grundlage der JINI-Archtektur wirkt und das Haushaltsgeräte wie intelligente Kühlschränke integrieren kann.
• WC-OS – Ein tragbares ("Weararable") Computer-Betriebssystem, das die Integration von miniaturisierten Wearable Computergeräten bietet.

Nun wird das Web-Betriebssystem ausführlicher beschrieben. Das w³OS verwendet vorzugsweise XML und die vorstehend beschriebene One-Page-Web-Technologie, um über das Internet auf jedermann zuzugreifen und von jedermann benutzt zu werden.
31 bietet eine Übersicht des w³OS.
Das w³OS ("Web (w³)-Betriebssystem") ist ein Gate zu dem Internet und sein Eingabe- und Ausgabe-Medium zu Web-Browsern. Basierend auf aktueller Internet-Technologie mit Hypermedien-Elementen und Web-Protokollen verwendet das w³OS sie auf eine neue dem Konzept des One-Page-Web folgende Weise. Das w³OS verwirklicht das Ziel einer Website ohne festgelegte Seiten – sondern mit nur "einer" virtuellen Seite, die mit neuem und veränderlichem Inhalt immer und immer wieder erzeugt und zusammengestellt wird – mittels vier Basismodule innerhalb des w³OS-Systems:

• Dem Web-Server, der als Eingangsstelle zu dem System wirkt;
• Der Web-Sicherheits-Schnittstelle ("Web Security Interface (WSI)"), dem systeminternen Puffer, der das System gegen die und zu der Außenseite (den Web-Server] abschirmt;
• Den Anforderungsabwickler ("Request Dispatcher") in Verbindung mit einem w³OS Ein-Gate zu dem BOS;
• Dem Seitenerstellungselement ("Page Composer"), der dynamische Webeseiten erstellt.

Selbstverständlich arbeitet das w³OS in enger Interaktion mit dem BOS. Im Kontext des Drei-Tier-Systems baut das w³OS die Darstellungsschicht auf und kann als die (End-)User-Schnittstelle betrachtet werden. Das w³OS selbst erzeugt in Kombination mit dem BOS einen Anforderungs-/Erwiderungs-Zyklus. Einer der wesentlichen Aspekte dieses Zyklus von Datenfluss ist, dass er unidirektional ist, d.h. er kann nur mit einer vordefinierten Folge von Modulen und Stationen laufen gelassen werden, die angetroffen werden müssen, gleichgültig welche Grenzbedingungen auftreten mögen. Diese Einweg-Verarbeitung ist strikt, d.h. es gibt keinen Stopp dazwischen, kein auslassen von Schritten, keine Umgehungen. Es bestehen nur eine Eingangsstelle und nur ein Ausgang. Dieses Konzept stellt sicher, dass kein böswilliges Eindringen möglich ist, sei es in der Mitte der Ablaufkette oder von hinten.
Zusätzlich dazu ist die WSI verantwortlich für die gründliche Überprüfung jeglicher Eingabe noch am Eingang zu dem Zyklus. Das Standby-Modul befindet sich in der Web-Sicherheitsschnittstelle, ebenso der Antworten-Aufbewahrer ("Response Keeper"). Beide werden zusammen mit den anderen Modulen nachstehend erläutert.
Die "erste" Web-Schnittstelle des Systems besteht aus einem Web-Server. Dies kann irgendeiner der handelsüblichen sein, der eine Java Servlet-Maschine unterstützt. Eine andere Möglichkeit ist ein besonderer Java Web-Server. Das System sollte mindestens IIS oder Apache als Web-Server verwenden und irgendwelche Servlet-Maschinen als Adapter zu der Java-Umgebung des Systems. Alternativ dazu kann ein systemspezifischer Java Web-Server wegen der unbegrenzten Steuerung und Konfiguration des Servers ein Maximum an Sicherheit noch auf der Web-Server-Ebene bieten. Dieser integrierte Web-Server stellt eine allein operierende Web-Lösung dar.
Die Manager-Applikation (nahtlos in das System integriert) ermöglicht eine standorttransparente Verwaltung des Web-Servers; man kann mannigfaltige Sicherheitseinstellungen konfigurieren, wie IP-Adressenfilterung, Ablehnmaßnahmen oder Service-Gegenmaßnahmen, oder Protokollierfunktionen, oder Ausführungseinstellungen.
26 zeigt eine schematische Darstellung des vorstehend beschriebenen Web-Server-Konzepts.
27 ist eine schematische Darstellung des Konzepts eines unidirektionalen Datenflusses aus Sicherheitsgründen. Wie ersichtlich, geht eine externe Anforderung (Pfeil 1) über den Web-Server 271 in das System ein, woraufhin eine Nachricht (Pfeil 2) an die Sicherheitsschnittstelle 272 übergeben wird. Andererseits wird die externe Anforderung in einem Haltemodul 276 in Wartestellung gesetzt (Pfeil 3), während andererseits eine Nachricht (Pfeil 4) an einen Anforderungsabwickler ("Request Dispatcher") 273 übergeben wird. Der Anforderungsabwickler ("Request Dispatcher") erzeugt eine interne Anforderung und sendet sie an das BOS (Pfeil 5), wo sie wie vorstehend ausführlich beschrieben verarbeitet wird. Die interne Erwiderung von dem BOS wird an einen Pager Composer 275 ausgegeben (Pfeil 6), woraufhin eine externe Antwort erzeugt wird (Pfeile 7, 8, 9). Wie durch den großen Pfeil 277 angezeigt, besteht eine Einweg-Schleife, die keinerlei Möglichkeit des Zurückverfolgens oder dergleichen bietet.
Die Web-Sicherheitsschnittstelle 272 ist die "zweite" Schnittstelle hinter dem Web-Server 271 und der Servlet und wirkt als Barriere zwischen den inneren Modulen des Systems und der mit dem Web-Server beginnenden Außenseite. Die WSI ist die tatsächliche Schnittstelle zu dem System, was auch durch die Untermodule und Klassen der WSI aufgezeigt wird (siehe 28):

• RavenSpace-Schnittstelle ("RavenSpaceInterface"). Diese Klasse ist die einzige Verbindung der WSI zu dem Web-Server und der Servlet. Sie wird für Eingabe und Ausgabe benutzt.
• Anforderungsempfänger ("RequestReceiver"). Diese zweite Klasse der WSI wirkt als zentraler Absorber bzw. Aufnehmer für alle in das System eingehenden Anforderungen. Diese Anforderungen können entweder Anforderungen für vollkommen neue Daten oder nachfolgende Anforderungen sein, d.h. Anforderungen, die automatisch als Folge einer vorherigen Antwort geschossen werden. Ein Beispiel hierfür sind in eine Webseite integrierte Bilder: Sie können nicht zusammen mit der Haupt-HTML-Seite an den Browser des User gesendet werden, sondern werden durch Links angefordert, die in dieser Seite eingebettet sind. Der Browser kann diese in diese Seite geschriebenen Links erfassen und wird selbstständig eine zweite Anforderung für jedes Bild senden. Der Anforderungsempfänger ("RequestReceiver") kann unterscheiden zwischen Anforderungen für Seiten und in bereits gelieferte Seiten einzubettende Anforderungen für Daten. Des Weiteren überprüft der Anforderungsempfänger ("RequestReceiver") für jede Anforderung und jeden User, ob Zugriff auf das System gewährt oder aus einer Vielfalt von Gründen vom Überschreiten der erlaubten maximalen Anzahl von User-Sessionen bis zur User-Session-Zeitsperre abgelehnt wird.
• Anforderungscontainer ("RequestContainer"). Diese Klasse enthält entweder die anfängliche Anforderung, die außer Kraft bzw. suspendiert werden muss (somit scheint die Verbindung zu dem System aus der Sicht eines Users blockiert zu sein) oder für eine nachfolgende Anforderung, wie vorstehend beschrieben, muss ein vordefiniertes Antwortobjekt gefunden werden.
• Standby-Modul. Diese Klasse repräsentiert das "Haltemodul" und ist das Hauptelement zum "Unterbrechen bzw. Abbrechen" der Verbindung von dem User zu dem System, während eine Anforderung bearbeitet wird. Das Standby-Modul suspendiert den Anforderungsausführungs-Thread, obwohl die Inhalte der Anforderungen weiter in das System hineingereicht worden sind und tatsächlich noch "am Leben" sind.
• Antwortenaufbewahrer ("ResponseKeeper"). Der Antworten-Aufbewahrer ("ResponseKeeper") enthält diese zusätzlichen Daten, die nicht gleichzeitig mit der tatsächlichen Seite an den Browser des Users gesendet werden können; dies trifft z.B. auf Bilder oder andere Elemente zu, die nicht direkt innerhalb der HTML-Seite eingebettet werden können. Der Antwortenaufbewahrer ("ResponseKeeper") befindet sich in der WSI, damit nachfolgende Anforderungen bereits an dieser Stufe zurückgehalten werden und nicht weiter in das System hineingereicht werden müssen.

Während der Anforderungsempfänger ("RequestReceiver") Anforderungen, die nachweislich gültig und akzeptabel sind, an den Anforderungsabwickler ("RPDispatcher" auf der Klassenebene) übergibt, besteht eine andere Klasse, WSI-Fabrik ("WSIFactory") genannt, die Antworten empfängt, die von der BOS und dem Seitenerstellungselement ("Page Composer") zurückkommen (siehe 28). Der grundlegende Gedanke hinter dem w³OS wird hier in der WSI verwirklicht: die Verbindung zwischen User und System "abzubrechen", sobald eine Anforderung zur Verarbeitung durch das System bereit ist. Im Gegensatz zu aktuellen handelsüblichen Lösungen, die eine dynamische Erzeugung von Webseiten zu erzielen versuchen (ohne die Granularität und User-Spezifität des Systems der Erfindung zu erreichen), erhalten das vorliegende System und das w³OS den Thread jeder Anforderung nicht "am Leben", während sie in dem System ausgeführt und verarbeitet und die Antwort erzeugt wird. Vielmehr wird die logische Verbindung zwischen dem Browser des Users und den inneren Modulen des Systems getrennt. Während herkömmliche Applikationen eine inhärente Möglichkeit des Verfolgens des Ausführungsflusses bis tief in das Programm und die Geschäftslogik zu hegen, untersagt dies das System der Erfindung, indem es eine ständig aktive und wie erwartete (dennoch untätige) Ausführung der Anforderung lediglich simuliert. In der Tat werden alle wichtigen Daten der Anforderung und die Sessionsdaten an das nächste Modul in einem separaten Thread übergeben, während die ursprüngliche Anforderung in einem suspendierten Stadium in einer neutralen Zone aufbewahrt wird: Dem Standby- oder Halte-Modul, das, in der WSI befindlich, keine Verbindung zu dem Kernsystem hat.
Nachdem die Anforderung in den gesamten Applikationslogik- und System-Modulen verarbeitet worden ist, wird es in Form einer Antwort wieder zurück bei der WSI ankommen. Die WSI-Fabrik ist das Eingangs-Gate für diese zweite Hälfte der Ausführung einer Anforderung. Mittels der einzigartigen Sessions-ID, die der anfänglichen Anforderung und ihrem Duplikat zugewiesen worden ist, wobei das Duplikat überall zu den Kernsystemteilen gesendet worden ist, kann die WSI-Fabrik die suspendierte anfängliche Anforderung ermitteln und sie "wieder aufwecken". An diesem Punkt wird die Verbindung von dem User zu dem System "wiederhergestellt" und die Antwort zu ihr übertragen. Die anfängliche Antwort wird aktiviert, als ob die Antwort durch sie selbst erzeugt worden wäre; Die RavenSpace- Schnittstelle (RavenSpaceInterface") sendet die Anforderung an den Aufrufen zurück, als ob dies eine unmittelbare Rücksendung wäre.
Da die Datenquelle (die Quelle für die Antworten völlig aus der Schnittstelle, die für den Web-Server und den Klientenbrowser sichtbar ist, ausgekoppelt ist, ist es ebenfalls möglich, die Ressourcen direkt zu verbinden. Der übliche Weg für einen Browser Objekte zu empfangen, die nicht in die HTML-Textdatei eingebettet werden können ist, dass diese Dateien und Elemente durch eine Referenz in der HTML-Datei bezeichnet werden und der Web-Server die gewünschten Daten aus einer Diskette herunterladen kann. Gebräuchliche Web-Browser bilden automatisch nachfolgende Anforderungen an eine HTML-Seite, die Schritt für Schritt alle eingebetteten und mit Verweisen versehenen Elemente abfragen.
Was das System der Erfindung betrifft, werden alle Applikationsdaten in dem EIC gespeichert (möglicherweise auf verschiedenen Computern) und der Web-Server hat keinerlei Zugriff auf irgendwelche Daten. Es ist offensichtlich, dass dies eine äußerst wichtige Verbesserung bei der Sicherheit ist, da der Web-Server nicht als Tor zum Eindringen ("Hacking") in Applikationsumgebungen und ihre Festplatten wirken kann. Wie aber können Dateien und Binärdaten für nachfolgende Anforderungen bereitgestellt werden? Eine Möglichkeit besteht darin, dass separate systeminterne Anforderungen zu erzeugen, die die XML-/HTML-Daten nicht abfragen, sondern nur die gesuchte bestimmte Datei oder den gesuchten bestimmten Bezugswert, dies würde aber eine gewaltige Anzahl von Anforderungen nur für jeweils ein Element bedeuten. Stattdessen löst die WSI dieses "Problem" vorzugsweise durch temporäres Lagern dieser Dateien und mit Verweisen versehenen Daten ausschließlich für die vorhergehende HTML-Anforderung bei dem WSI-Antwortenaufbewahrer.
Es bestehen zwei grundlegende Flüsse von Ereignissen in der Web-Sicherheitsschnittstelle, die die Features dieses Moduls besser zu erläutern helfen:

• Empfangen und Verarbeiten von Anforderungen für Webseiten ("allgemeine" Anforderungen)
• Empfangen und Verarbeitung von Anforderungen für Dateien und andere Daten, die in Webseiten eingebettet werden sollen. Diese Anforderungen werden automatisch durch Web-Browser bei Empfang von Webseiten mit Referenzen ("Medien"-Anforderungen) geschossen.

Ganz gleich welche dieser zwei Anforderungstypen an der RavenSpace-Schnittstelle ("RavenSpaceInterface") ankommt (durch einen aufrufenden Servlet übergeben), sie werden unverzüglich an den Anforderungsempfänger ("RequestReceiver") weitergeleitet. Dieses Modul wiederum startet das Analysieren der Anforderung. Jede Anforderung verwendet einen Identifikator, der den Typ der Anforderung beschreibt. Für jegliche Anforderung wird zuerst die Sessions-ID überprüft.
Diese (externe) Sessions-ID ist eine verschlüsselter einzigartiger Identifikator für jede Anforderung, die den User-Namen und den Zeitstempel der letzten vorhergehenden Anforderung dieser Session enthält.
Der Anforderungsempfänger ("RequestReceiver") enthält eine Liste aller gegenwärtig eingeloggten User und ihre Sessionen (eine neue Session wird bei jedem Login erzeugt und wann immer der User Bowser-Sessionen "abzweigt", d.h. neue Browser-Fenster aus bestehenden öffnet). Mittels des Zeitstempels kann der Anforderungsempfänger ("RequestReceiver") feststellen, ob die Anforderung gültig ist und für diese Session dieses bestimmten Users akzeptiert werden darf. Für jeden User besteht eine Obergrenze gleichzeitiger Sessionen; Die WSI sorgt dafür, dass neue Logins und Abzweigungen diese Begrenzung nicht überschreiten. Aus dieser Perspektive verwirklicht die WSI grundlegendes Sessionsmanagement, da sie ebenfalls automatisch Sessionen beendet (d.h. akzeptiert Folgeanforderungen nicht), wenn die Zeitsperre erreicht ist.
Allgemeine Anforderungen
Wenn der Anforderungsempfänger ("RequestReceiver") ein Login, Logout oder eine andere generische Anforderung erfasst, erzeugt es ein Anforderungscontainer-Objekt ("RequestContainer object"), der die anfängliche Anforderung speichert. Zur selben Zeit wird dieser Anforderungscontainer ("RequestContainer") an die RavenSpace-Schnittstelle ("RavenSpaceInterface") zurück gesendet, die Inhalte dieser Anforderung werden ausgelesen und der Kommunikationsschnittstelle der WSI übergeben, die diese systeminterne Anforderung an den Anforderungsabwickler ("Request Dispatcher") (siehe 0) sendet. Dieser spätere Fluss von Daten ist in einem völlig separaten Ausführungs-Thread enthalten und ist von dem Anforderungscontainer ("RequestContainer") unabhängig. Die RavenSpace-Schnittstelle ("RavenSpaceInterface") ruft automatisch getResponse() auf dem zurückgesendeten Anforderungscontainer ("RequestContainer") auf, was den Container veranlasst, sich selbst in dem Standby-Modul zu speichern (unter einem bestimmten Schlüssel, einer Anforderungs-ID) und dann einen "Suspend"-Modus einzugeben.
Wenn das Seitenerstellungselement ("Page Composer") (siehe 0) den HTML- oder XML-Ausgabe-/Antwort-String erzeugt hat, sendet es die Antwort als ein RpResponse-Objekt an die WSI zurück. Die WSI-Fabrik ("WSIFactory") akzeptiert diese Mitteilung und erzeugt einen neuen Thread innerhalb des WSI. Das Standby-Modul wird mit der Anforderungs-ID abgefragt und kann auf diese Weise den anfänglichen Anforderungscontainer ("RequestContainer") ermitteln, der mit diesem Schlüssel gespeichert worden ist. Der HTML- oder XML-/XSL-Teil der Antwort kann unverzüglich an die ursprüngliche Anforderung, die in dem Anforderungscontainer ("RequestContainer") gespeichert ist, übermittelt werden. Danach ist der Suspend-Status des Anforderungscontainers ("RequestContainer") beendet. Der Anforderungscontainer ("RequestContainer") läuft dann noch in dem ersten Thread, der die RavenSpace-Schnittstelle ("RavenSpaceInterface") aufrief; getResponse() von diesem Anforderungscontainer ("RequestContainer") kann zu der RavenSpace-Schnittstelle ("RavenSpaceInterface") zurückkehren, die wiederum die anfängliche Anforderung ausliest (die nun den Antwort-String enthält) und gibt sie an die Servlet zurück, die die Anforderung initialisierte.
Alle anderen Teile der Antwort, die nicht unverzüglich an die Anforderungscontainer-Anforderung ("RequestContainer/Request") übermittelt werden konnten, sind Datenelemente, die in die erzeugte Seite nicht eingebettet werden konnten. Das Seitenerstellungselement ("Page Composer") verpackt all diese Daten und speichert sie in bestimmten Objekten, die aus dem Antwortobjekt entnommen und in dem Antwortenaufbewahrer-Modul ("ResponseKeeper module") gespeichert werden können. Die Antworten werden unter einem speziellen Schlüssel aufbewahrt, der zu dem "Link" passt, der in die HTML-/XML-Seite anstelle dem üblichem URL, der auf einen Standort of der Festplatte deutet, eingefügt worden ist. Die Anforderungen, die auf diese HTML-/XML-Antwort folgen, fragen mittels des Links/Schlüssels des Antwortenaufbewahrers ("ResponseKeeper") die "Medien"-Daten ab.
Der Fluss von Ereignissen und Daten für "Medien"-Anforderungen ist ziemlich ähnlich dem für "allgemeine" Anforderungen. Diese Anforderungen werden ebenfalls durch den Anforderungsempfänger ("RequestReceiver") analysiert. Wenn die Gültigkeit einer Anforderung belegt worden ist, erfasst der Anforderungsempfänger ("RequestReceiver"), dass sie eine Medienanforderung ist und fragt unverzüglich den Antworten-Aufbewahrer ("ResponseKeeper") ab, ob ein Antwortobjekt für diese Anforderung besteht. Wenn eine positive Antwort zurückgesendet wird, wird ein Anforderungscontainer ("RequestContainer") erzeugt und die Medienanforderung wird ihm zugewiesen. Abweichend von dem vorherigen Fall wird der Inhalt der Anforderung nicht ausgelesen und an den Abwickler ("Dispatcher") in einem separaten Thread gesendet. Stattdessen wird der Anforderungscontainer ("RequestContainer") einfach an die RavenSpace-Schnittstelle ("RavenSpaceInterface") zurückgesendet.
Die Schnittstelle wiederum ruft getResponse() aus dem Anforderungscontainer ("RequestContainer") auf, wie sie es immer tut. Der Anforderungscontainer ("RequestContainer") nimmt wahr, dass seine Anforderung eine Medienanforderung ist und tritt mit dem Antwortenaufbewahrer ("ResponseKeeper") in Verbindung, um das entsprechende Antwortobjekt zu erhalten. Da der Anforderungsempfänger ("RequestReceiver") bereits sichergestellt hat, dass eine solche Antwort existiert, kann der Anforderungscontainer ("RequestContainer") die Antwort auswählen und sie aus dem Antwortenaufbewahrer ("ResponseKeeper") löschen, damit sie kein zweites mal angefordert werden kann. Der Anforderungscontainer ("RequestContainer") kann unverzüglich die Antwort an das Servlet zurücksenden ohne zu dem Standby-Modul zu gehen oder suspendiert zu werden.
Aus der Perspektive der RavenSpace-Schnittstelle ("RavenSpaceInterface") besteht kein Unterschied zwischen allgemeinen und irgendwelchen anderen Anforderungen, da alle in den Anforderungscontainer ("RequestContainer") gestellt werden, der eine Antwort zurücksendet, gleichgültig um was für eine Anforderung es sich handelt.
Nun wird der Anforderungsabwickler ("Request Dispatcher") ausführlicher beschrieben. Während ein Anforderungscontainer ("RequestContainer") mit einer allgemeinen Anforderung in dem Standby-Modul gespeichert und suspendiert wird, werden die anfänglichen Anforderungsdaten zu dem Anforderungsabwickler ("Request Dispatcher") weitergeleitet. Dieses Modul wirkt als weiterer Puffer zwischen Schnittstellen und Kernsystemteilen (BOS). Zusätzlich dazu weist der Abwickler ("Dispatcher") der Anforderung einen internen Sessionsidentifikator zu. Auf diese Weise kann ein voll qualifiziertes Sessionsmanagement bei dem BOS durchgeführt werden.
Der Punkt ist, dass User-Daten nur an der BOS verfügbar sind, da auf alle Datenbanken durch das BOS zugegriffen werden kann und nicht durch irgendein anderes Modul. Auf Grund dieser Erfordernis braucht das w³OS ein Zweiwegmanagement: ein einfaches Management an dem WSI, das entscheidet, welche Anforderungen zu akzeptieren oder abzulehnen sind (bereits vorstehend beschrieben) und ein ausführlicheres Sessionsmanagement, das innerhalb des BOS verwirklicht wird.
Eine weitere Erfordernis des Systems ist es, eine Sichtbarkeit kritischer Daten durch den Enduser zu vermeiden, damit die interne Sessions-ID nicht mit der Antwort an den Browser des Users übergeben wird und ist folglich nicht als ein Parameter von Anforderungen verfügbar. Stattdessen kann die weniger kritische externe Sessions-ID, die lediglich den User-Namen und einen Zeitstempel enthält, auf der internen Sessions-ID abgebildet werden, die der Schlüssel zu allen Sessionsdaten wie eine Anforderungshistorie, User-Sicherheitseinstellungen und so weiter ist. Wie bereits erwähnt, wird all diese Logik in der BOS implementiert.
Der Anforderungsabwickler ("Request Dispatcher") ist mit dem w³OS-Gate des BOS verbunden. Auf diese Weise benutzt das w³OS ein normales Gate der BOS zum Senden von Daten an das Kernmodul von RavenSpace. Das Bos und das CDM werden die Anforderung ausführlicher analysieren. User-Einstellungen werden auf der Grundlage von User-Information, die mit der Anforderung ankommen, spezifiziert. Zusätzlich dazu wird ein Mittel ("Agent") erzeugt und gestartet, um die Anforderung auszuführen. Eine Antwortseite wird zusammengestellt, eine Reihe von BTEs wird eingesetzt, um die Daten, die auf der Seite angezeigt werden müssen, zu erfassen. Für Einzelheiten siehe die vorstehende Beschreibung des BOS.
Nun wird das Seitenerstellungselement ("Page Composer") ausführlicher beschrieben. Sobald das BOS und die Ansichten-BTE ("ViewBTE") alle Daten abgerufen haben, die durch die ursprüngliche Anforderung angefragt worden sind (die Ansichten-BTE ("ViewBTE") hat auch die entsprechenden Daten für das Seitenerstellungselement ("Page Composer") ausgewählt, um es diesem zu ermöglichen, die tatsächliche Seite zusammenzustellen), wird ein RpPageData-Objekt mit allen für die Seite erforderlichen Daten erzeugt. Die Anforderung wird in Kombination mit den RpPageData an das Seitenerstellungselement ("Page Composer") gesendet.
Mit all den Daten, die in den RpPageData enthalten sind, ist das Seitenerstellungselement ("Page Composer") in der Lage, den XML-Dokumentenbaum zu bilden. Die auf die Seite zu placierenden tatsächlichen Daten werden in einer separaten sequentiellen Datenstruktur geliefert. Das Seitenerstellungselement ("Page Composer") kann beide Datenelemente zum Bilden der Seite anpassen. Zusätzlich dazu könnte das BOS Musterblätter und eine XSL-Datei ausgewählt haben, die für den bestimmten User perfekt passen.
Ein wichtiger Vorteil des Seitenerstellungselements ("Page Composer") ist: Es kann jegliche Seite mit mehr oder weniger durch das BOS gegebenen "Hinweisen" und Anweisungen zusammenstellen. Dies bedeutet, das Seitenerstellungselement ("Page Composer") entscheidet nicht, was anzuzeigen ist. Der Grad dessen, wie viel durch das BOS vorgeschlagen und vorgeschrieben wird, kann variieren. Letztendlich ist das Seitenerstellungselement ("Page Composer") in der Lage, all das, was durch das BOS bereitgestellt wird, zusammenzustellen und automatisch zu spezifizieren, wie es anzuordnen und darzustellen ist, selbst wenn nicht alle Einzelheiten vorgegeben werden.
Auf diese Weise kann das Seitenerstellungselement ("Page Composer") dynamisch Seiten erzeugen und sie entsprechend formatieren. Musterblätter und XSL-Dateien sind an dem Seitenerstellungselement ("Page Composer") verfügbar. Der Grad von Unabhängigkeit des Seitenerstellungselements ("Page Composer") kann ausgewählt werden. Auf jeden Fall können viele Einstellungen dynamisch durchgeführt werden, von Fontfarben abhängig von den Einstellungen des Users, Fontgröße und -stil, Hintergrundfarben, Größen von Paragraphen und Bildern und so weiter, sowie Farben abhängig von der Tageszeit und viele mehr.
Wann immer das Seitenerstellungselement ("Page Composer") auf Daten stößt, die nicht in die XML-Datei eingebettet werden können, erzeugt es Antwortobjekte, die später in dem Antwortenaufbewahrer ("ResponseKeeper") an der WSI gespeichert werden können. Zur selben Zeit werden entsprechende "Links", die zu den IDs der Antwortobjekte passen, in das XML-Dokument eingefügt. Sobald alle XML-Strings zusammengestellt und alle tatsächlichen Daten so weit wie möglich eingefügt worden sind, wird das XML-Dokument entweder in einen HTML-String umgesetzt, wobei die entsprechende XSL-Datei verwendet wird, oder sowohl das XML-Dokument als auch die XSL-Datei werden auf einem neu erzeugten RpResponse-Objekt gespeichert. Antwortobjekte mit, mit Verweisen versehenen Elementen werden ebenfalls zu dieser RpResponse gestellt, bevor sie zu der WSI gesendet wird, um an die ursprüngliche Antwort weitergegeben zu werden und die Antworten in dem Antwortenaufbewahrer ("ResponseKeeper") zu speichern.
Das Seitenerstellungselement ("Page Composer (PC)") implementiert das Thread-Konzept, d.h. es besteht ein als Gate zu dem Modul wirkendes Fabrikobjekt. Diese Fabrik erzeugt neue Threads, die die Ausführung der Funktionalität dieses Moduls vornehmen. Im Fall des PC sind dies Seitenerstellungselement-Threads ("PageComposerThreads"), siehe 29.
Für die Kommunikation zwischen BOS (w³OS-AUS-Gate) und PC besteht ein wohlbekanntes Kommunikations-Wrapper-Modell. Infolgedessen besteht eine IRmiServer-Implementierung auf der PC-Seite (in der FIG. nicht angezeigt), die die letztendlich all Daten an die Seitenerstellungselement-Fabrik ("PageComposerFactory") weiterleitet.
Nachdem das BOS/CDM die Abholung von Daten und Ansichten beendet hat, kann die RpRequest mit dem neuen RpPageData-Objekt an den PC übergeben werden. Die konkreten Threads sind Implementierungen der Seitenerstellungselement-Schnittstelle ("PageComposer Interface"), das nur eine Verfahrensschablone aufweist:
interface PageComposer implements Runnable { void composePage (RpRequest req); }
Es ist ausreichend, eine einzige Seitenerstellungselement-Thread-Klasse ("PageComposerThread class") einzuführen, die diese Schnittstelle und ihr Verfahren implementiert.
In der Ansichten-BTE ("View BTE") sind alle Darstellungen für erforderlichen Inhalt und alle notwendigen XML-Strings erfasst worden. Die Ansichten-BTE ("View BTE") behandelt die Ansichten und bestimmt, welche XSL-Datei für Formatierungen zu benutzen ist (d.h. größere Fonts für die Älteren, leuchtendere Farben für Kinder, ...). Schließlich ordnet sie alle abgeholten XML-Teilzeichenfolgen (im Folgenden "Substrings") und alle tatsächlichen Daten zu einer Folge (wobei die Elemente von ihr in einen Vektor zu stellen sind).
Der Vektor kommt bei dem PC an. Nun ist es für den PC eine einfache Aufgabe, die Seite zusammenzustellen. Zuerst erzeugt man zwei Zeiger, wobei einer von ihnen auf das erste Element von vecXmlStrings zeigt, der andere auf das erste Element von vecPageData. Weiterhin benötigt man eine leere XML-Datei (den "XML-Stapel"). Dann wird der folgende Algorithmus verarbeitet: Bringe das Element von vecXmlStrings dahin, worauf der Zeiger gegenwärtig eingestellt ist. Bewahre diesen XML-String (im Speicher) und lege es auf einen Stapel.
{
Denn alle Platzhalter (jeglichen Typs) von diesem XML-String bewirken bzw. führen folgendes durch:
{
Falls es ein Ansichtenplatzhalter ist, erhöhe den vecXmlStrings-Zeiger und verlasse die Schleife.
Falls es ein Inhaltsplatzhalter ist, nimm vecPageData. Betrachte das Element bei dem der Zeiger in dem Moment ist.
{
Für dieses tatsächliche Datenobjekt: Ersetze den (sequentiell) ersten Inhaltsplatzhalter von dem XML-String durch die Darstellung dieses Datenobjekts.
Falls kein erster Platzhalter besteht: Verlasse die Schleife.
Falls dieses Datenobjekt ein Bild oder ein anderer Medientyp ist, die nicht direkt eingefügt werden können, erzeuge einen "Link" (d.h. einen einzigartigen Identifikator) und füge ferner dieses Datenobjekt der zu dem RpResponse-Objekt gehörenden Hash-Tabelle der Antworten hinzu, die eine "Medienanforderung" erfordern. Später kann die WSI das Datenobjekt ermitteln, weil der "Link" zu ihm in dem Antworten-Aufbewahrer ("ResponseKeeper") führt (siehe entsprechende Dokumente).
Erhöhe den vecPageData-Zeiger.
{
{
// Ergebnis: Das nte Datenelement in einer Reihe von Datenelementen wird in die bzw. den nte(n) Lücke/Platzhalter in dem XML-String eingefügt.
Lasse diesen XML-String erscheinen und bette ihn in den nächst unteren XML-String an der Stelle der ersten Ansichtenplatzhalter-Variablen ein, d.h. ersetze diesen Platzhalter durch den XML-Substring (der "endgültige" Daten enthält).
Erhöhe den vecXmlStrings-Zeiger. Fall der Zeiger > lengthOf (vecXmlStrings) dann beende bzw. steige aus.
{
Wenn kein Element übrig ist, sollte die entsprechende Ansicht "beendet" werden, d.h. es sollte kein Platzhalter bestehen, der nicht ersetzt wurde. Mit anderen Worten: Sowohl vecXmlStrings als auch vecPageData müssen vollständig aufgebraucht sein. Falls diese nicht der Fall ist, besteht ein Fehler, der behandelt werden muss.
Es ist naheliegend, dass das CDM die Elemente in dem XML-Strings-Vektor so anzuordnen sind, dass sie wie ein Stapel benutzt werden. Jeder neue XML-String öffnet eine neue Ebene. Sobald wir zu Ansichten "beenden" kommen, d.h. XML-Strings, die grundlegende Daten zwischen ihren Tags benötigen, können wir die Elemente des Seitendatenvektors eins nach dem anderen nehmen (wir müssen uns nur daran erinnern, wo wir vorher in der Folge anhielten, deshalb benötigen wird einen Prozesszeiger).
Folglich muss der PC Datenelemente und XML-Strings einfach verschachteln und stapeln, um letztendlich ein volles XML-Dokument zu bilden. Abhängig von dem konkreten Datenteil muss der PC dies entweder einfügen (Text, Buttons, sogar Verweise) oder für den RpResponse-Vektor für Wiedervorlageantworten (z.B. Bilder, ..., → Bearbeiten von Medienanforderungen) ein Objekt erzeugen.
Wenn z.B. ein Button, wenn gedrückt, zu einer anderen Anforderung führen wird, muss die entsprechende Anforderung für Inhalt verwendet werden. Im Allgemeinen wird diese Information (Link) durch das CDM bereitgestellt. Der PC sollte diesen Link verschlüsseln (was tatsächlich ein Substring der Seriennummer ("SerialNumber"), eine Liste von mehreren Seriennummern ("SerialNumbers") oder eine Ansichten-ID ("ViewID") ist), bevor er in die Ansichten-/XML-Datei eingefügt wird.
Manche zusätzliche Information, die mit jeder nachfolgenden Anforderung ankommen muss (in diesem Fall jede Anforderung nach der Login-Anforderung), ist die (externe Sessions-ID (z.B. mit <input type=hidden name="sessionID" value="SAWAERONY-BAD§$SDF§$BXC">).
Sobald der Prozess des Zusammenstellens der Seiten hinsichtlich XML-Strings und tatsächlicher Daten durchgeführt und das RpResponse-Objekt erzeugt worden ist, muss der PC herausfinden, wie die Seite zu formatieren ist (weil die XML-Datei lediglich aussagt, wie die Daten auf der Seite anzuordnen sind, nicht wie sie anzuzeigen sind). Das RpPageData-Objekt verwendet die Felder iXslId und iSSId, d.h. eine ID für die XSL-Datei zur Verwendung, eine ID für das Musterblatt zur Verwendung.
Dann muss die XML-Datei, die zusammengestellt worden ist, in HTML umgesetzt werden. Wir können dies mittels unserer XSL-Datei und einem Umsetzer erledigen.
Das w³OS weist folgende Eigenschaften und Vorteile auf:

• Absolute Sicherheit, weil die logische Verbindung von dem User zu dem System getrennt wird, während die Anforderung verarbeitet wird.
• Die Webseiten enthalten keine herkömmlichen Verweise und Links, die eine Einsicht in die systeminternen (Disketten-)Strukturen gewähren. Dieses Ziel wird erreicht, weil auf alle Daten eines Systems nur durch das BOS zugegriffen wird, das entscheidet, was als Antwort auf eine Anforderung bzw. an welchen User gestattet ist. Die Granularität von Daten ermöglicht hochdynamische Webseiten in jeder möglichen Hinsicht.
• Das System und das w³OS benötigen keine vorgefertigten HTML-Seiten und -Strukturen, weil alles im laufenden Betrieb dynamisch und mit maximaler Granularität durchgeführt werden kann. Letztendlich bedeutet dies, dass das System nicht mit einer Vielfalt von Seiten arbeitet, sondern nur mit einer Seite (Einseiten-Web).
• Musterblätter und XSL-Dateien zum Formatieren von Seiten können in irgendeiner gewünschten Anzahl definiert und dynamisch ausgewählt werden.

Trotz all dieser innovativen Features sind das System und das w³OS immer noch mit allen gängigen Bowsern kompatibel. Andererseits sind zukünftige Entwicklungen bezüglich dieses Bereichs kein Hindernis, weil mit XML die neueste Technologie bereits eingesetzt worden ist.
Andere Untersysteme
Die visuellen Hilfsmittel bzw. Tools ("VisualTools") stellen ein Untersystem dar, das bearbeitet

• Eingabe von Inhalten;
• Konfiguration und Veränderung von Inhalten;
• Entfernen bzw. Löschen von Inhalten:
• Suchen nach Inhalten;
• Konfiguration von Ansichten für Inhalte;
• Applikation von Ansichten und ihr Füllen mit Inhalt.

All diese Tasks können visuell durchgeführt werden. Die VTools arbeiten eng mit dem CDM zusammen, da sie auf dieser Datenbank funktionieren. Es ist ein Erfordernis, dass nur das CDM Zugriff auf die Datenbanken des Systems hat – deshalb sind die VTools für die Kommunikation mit den Datenbanken auf die CDM-Funktionalität angewiesen.
Die VTools bestehen aus drei grundlegenden Tools:

• Visueller Inhaltsmanager ("VisualContentManager (VCM)", früher "Input Tool, enthält Positionen 1–4, vorstehend)
• Ansichtenerstellungselement ("ViewComposer (VC)") (Position 5, vorstehend)
• Seitenerstellungselement ("PageComposer") (Position 6, vorstehend).

Hiermit kann der visuelle Inhaltsmanager ("VisualContentManager") als eine Applikation zum allgemeinen Verwalten der Inhaltsdatenbanken betrachtet werden. Da die in den User-Datenbanken aufbewahrten User-Datensätze ebenfalls Inhalte sind, kann der visuelle Inhaltsmanager ("VisualContentManager") ebenfalls die User-Daten pflegen. Andererseits ermöglicht das Ansichtenerstellungselement ("ViewComposer (VC)") das Anordnen von Inhalten auf einer Seite auf visuelle Weise. Indem die Drag-and-Drop-Funktionalität lediglich als visueller Inhaltsmanager ("VisualContentManager") verwendet wird, kann das Ansichtenerstellungselement (ViewComposer") Inhalte in der Größe anpassen (oder Halter für Inhalte placieren), um Sätze von Daten für die Bildung einer "Ansicht", d.h. einer Schablone für diesen Satz von Daten, zu gruppieren. Das Ansichtenerstellungselement ("ViewComposer (VC)") schreibt an die durch das Seitenerstellungselement ("PageComposer") benutzten Datenbanken.
Das Seitenerstellungselement ("Page Composer") nimmt unter den VTools eine Art Sonderstellung ein. Mehr oder weniger gehört es eigentlich zu dem w³OS-Paket. Da der PC in der Tat in Gegenseitigkeit von dem VC in hohem Maße abhängt, kann er von einem logischen Gesichtspunkt aus primär als ein Teil der VTools betrachtet werden.
Datenformate für visuelle Hilfsmittel ("VisualTools")
Die visuellen Hilfsmittel ("VisualTools") interagieren stark mit Inhalten und Ansichten. Deshalb hängt die Funktionalität des Designs von der Inhaltsdatenbank ("ContentDataBase") ab.
In dem EIC sollten sich im Grunde mindestens drei Systemdatenbanken befinden:

• die Inhaltsdatenbank ("Content Database")
• die Geschäfts-/Finanz-Datenbank ("Business/Financials Database")
• die Users-/Dockings-Datenbank ("Users/Dockings Database")

Die VTools operieren auf der Grundlage der Inhaltsdatenbank ("ContentDataBase"), wobei sie folgendes erfassen:

• die statischen Inhaltsstammkatalog-Tabellen ("Content Master Catalog tables") (Inhaltstypen, Inhaltsattribute, ...);
• die Inhaltsinformationstabelle ("Content Information Table (CIT)"), die die Seriennummer ("Serial Number") und Meta-Information, wie die Default-Ansicht, enthält;
• die Inhaltstabelle("Content Table (CT)"), die alle Elemente (Darstellungen) dieses Inhalts und Verweise auf Ansichten für diesen Inhalt auflistet;
• die Ansichtentabelle ("ViewTable"), die die Ansichten, XML-Dateien und XSL-Musterblätter, Verweise auf andere Ansichten sowie Ansichtenbeschreibungen enthält.

Beispiel
Ein durch eine bestimmte Seriennummer ("Serial Number") und ID (14532) in der Inhaltsinformationstabelle ("ContentInformationTable (CIT)") definierter Server könnte durch ein Bild, eine Kurzbeschreibung und einen Preis sowie durch einen "Jetzt kaufen ("Buy Now")" Button dargestellt werden. Das Bild ist eine Ansicht des Typs (Ansichten-ID ("ViewID)") 001, die Kurzbeschreibung weist die Ansichten-ID ("ViewID") 008 auf, der Preis-Tag wird durch die Finanz-/Logistik-Datenbank abgefragt, bevor die Auswahl von Ansichten durchgeführt wird. Der "Buy Now" Button wird durch eine bestimmte Seriennummer ("SerialNumber") beschrieben, die in der Inhaltsinformationstabelle mit ID ("Content Information Table with ID (CITID)") 13254 aufgelistet ist.
Die CIT würde wie folgt aussehen:
Die CT würde die folgenden Zeilen, unter vielen anderen, enthalten:
Die CT wird ebenfalls Spalten für CreatorID, Created, Modifier ID und Modified enthalten (wie in der vorstehend gezeigten CIT, aber diese ist aus Platzmangel in dem vorliegenden Dokument weggelassen worden.
Die Ansichtstabelle ("ViewTable") weist eine Anzahl statischer Eingänge für grundlegende Typen ohne Verweisen auf, wie Text, Überschrift, Kurzbeschreibung, Bild, Button, und so weiter, sowie Raum für User-definierte Ansichten (einzelne Summierungen und Seitenansichten).
Im Allgemeinen können Anforderungen für Webseiten zweierlei Typen angehören:

a) Anforderungen von Ansichten, d.h. "gefüllte Ansichten": vordefinierte Seiten mit einem bestimmten Satz von Inhalten; der XML-String muss lediglich Verweise auf Inhalt enthalten; Verweise auf Ansichten sind nur gestattet, wenn der Inhalt durch eine andere BTE vorab abgerufen wird, wie es beispielsweise für Preis-Tags der Fall ist. Anforderungen für Ansichten enthalten lediglich eine Ansichten-ID ("ViewID"); entsprechender Inhalt wird über Inhalts-IDs ("CITID") abgerufen oder vorab abgerufen und einer Ansichten-ID ("ViewID") angepasst. Eine reguläre Anforderung für eine Ansicht nimmt diese Route:
1. Die Ansichten-ID ("ViewID") nachschlagen.
2. Den XML-String betrachten, Wenn Verweise auf Seriennummer bestehen, die Seriennummern und ihre Zusammenstellungsansicht(en) nachschlagen, wie vorstehend beschrieben. Wenn Verweise auf Ansichten bestehen, suchen ob bereits Objekte bestehen, die diesen Typ von Ansicht darstellen.
3. Den Schritt 2 und verschachtelte Anforderungen für Ansichten oder Seriennummern ("SerialNumbers") wiederholen, bis alle offenen Verweise auf grundlegenden Ansichtstypen wie Text, Bilder und so weiter führen.
b) Anforderungen für eine Anzahl von einzelnen Inhalten und/oder Zusammenstellungen sehen wie folgt aus (SerNo = Teil einer Seriennummer ("SerialNumber"), VID = Ansichten-ID ("ViewID"): <SerNo>[,<VID>]|{,<SerNo>[,<VID>]

Eine derartige Anforderung kann deshalb eine oder mehrere Seriennummern ("SerialNumbers") und Ansichten-IDs ("ViewIDs") enthalten, wenn keine Default-Ansicht ("DefaultView") oder eine andere Ansicht als der Default verwendet werden sollte. Wenn eine Anforderung für einen Satz von Seriennummern besteht, können irgendwelche Untergruppen der Seriennummern ("SerialNumbers") Zusammenstellungen bilden. Letztlich wird ein Satz von Ansichten/Zusammenstellungen für die Seriennummern ("SerialNumbers") zurückgesendet und das bzw. die CDM/BTE ermitteln eine Seite, die allen Inhalten entspricht.
Eine Anforderung für eine Seriennummer ("SerialNumber") wird wie folgt behandelt:

1. Die Seriennummern ("SerialNumbers") nachschlagen, die zu dem mit der Anforderung übergebenen Substring passen. Wenn der entsprechende Eintrag in der Inhaltsinformationstabelle ("ContentInformationTable") gefunden wird, nachsehen ob eine Default-Ansichten-ID ("DefaultView ID") besteht.
2. Die mit der Seriennummer ("SerialNumber") übergebene Ansichten-ID ("ViewID"), oder, falls verfügbar, die übertragene Ansichten-ID ("View ID"), um (in der Inhaltstabelle ("Content Table") den durch die Seriennummer ("SerialNumber") definierten tatsächlichen Inhalt nachzuschlagen. Falls keine Ansichten-ID ("ViewID") oder Default-Ansichten-ID ("DefaultViewID") besteht, den ersten Ansichteneintrag in der Inhaltstabelle ("ContentTable") suchen.
3. Irgendeine Ansicht für eine in der Inhaltstabelle ("ContentTable") gespeicherte Seriennummer ("SerialNumber") wird mittels der CITID (die zu der ID in der CIT passt) in Verbindung mit der Ansichten-ID (View ID") gefunden. Falls diese Ansichten-ID ("ViewID") einen grundlegenden Ansichtentyp wie ein Bild bezeichnet, die Definition für diese Ansicht in der Ansichtentabelle ("ViewTable") nachschlagen, den XML-String entnehmen und sowohl den XML-String als auch das tatsächliche Inhaltselement dem Seitenerstellungselement ("PageComposer") übergeben.
4. Falls die ausgewählte Ansicht eher eine Zusammenstellung oder eine User-definierte Ansicht als ein grundlegender Ansichtentyp ist, die Definition der Ansicht in der Ansichtentabelle ("ViewTable") nachschlagen. Den XML-String entnehmen.
• Für alle in dem XML-String enthaltenen Verweise auf grundlegende Ansichtentypen den entsprechenden Eintrag (gleiche Ansichten-ID ("ViewID")) in der CT nachschlagen. Den Platzhalter (den Verweis auf die Ansicht) durch den XML-String dieser Ansicht (Tags für den bestimmten grundlegenden Ansichtentyp) ersetzen. Beides an das Seitenerstellungselement ("Page Composer") übergeben.
• Für alle Verweise auf User-definierte Ansichtentypen die Definition dieser Ansicht in der Ansichtentabelle ("ViewTable") nachschlagen. Ermitteln aktueller Inhalte, die durch die in dieser Position 4 beschriebene Ansicht erforderlich sind; zuerst in der ursprünglichen CT nachsehen.
• Für alle Verweise auf Seriennummern ("SerialNumbers") oder Inhalts-IDs ("Content IDs") den entsprechenden Eintrag in der CIT oder der CT nachschlagen. Falls eine Ansichten-ID ("ViewID") zusammen mit dem Verweis bereitgestellt wird (wie 12323:0054), kann Information direkt aus der CT abgerufen werden (ansonsten muss der Umweg über die CIT genommen werden). Fortfahren wie beschrieben von 3. an.
• Falls es einen ungeklärten Verweis gibt, d.h. einen Verweis mit keinem tatsächlichen Inhalt bei dieser bestimmten Ansichten-ID ("ViewID"), müssen die Daten für diesen Verweis in vorherigen Schritten innerhalb der bzw. des BOS/CDM abgerufen worden sein. Zum Beispiel wird der Preis-Tag des vorstehend erwähnten Servermusters innerhalb der Finanz-/Logistik-Datenbank ("Financial/Logistic database") aufbewahrt. Der tatsächliche Preis wird bereits von dort abgerufen, als sich das BOS-Mittel ("BOS Agent") in dem Finanz-/BOS-Kanal befand. Die Preisdaten müssen einen Identifikator bereitstellen, der es der Ansichten-BTE ("ViewBTE") ermöglicht, die Daten dem Platzhalter zuzuordnen.

Letztendlich müssen alle XML-Abschnitte und Tags und die tatsächlichen Inhalte dem Seitenerstellungselement ("Page Composer") übergeben werden. Es ist die Aufgabe des CDM (d.h. einer BTE), alle XML-Code-Schablonen und die tatsächlichen Daten zu sortieren. An dieser Stelle kann eine entsprechende XSL-Datei ausgewählt werden, um den Anforderungen des Users zu entsprechen (z.B. großer Font für einen 60-jährigen Mann, Hintergrundfarben am Morgen, and so weiter). Ferner muss die BTE in der richtigen Reihenfolge angeordnet werden, d.h. in einer Weise, dass das Seitenerstellungselement ("PageComposer") leicht und rekursiv die Abschlussseite zusammenstellen kann (für Einzelheiten siehe das Seitenerstellungselement-Kapitel ("PageComposer chapter") dieses Dokuments).
Nun wird der visuelle Inhaltsmanager ("VisualContentManager (VCM)") beschrieben.
Der visuelle Inhaltsmanager ("VisualContentManager (VCM)") ist das wesentliche Hilfsmittel zum Pflegen der EIC-Datenbanken. Seine wichtigste Funktionalität ist, bestehende Daten in das Datenmodell zu importieren. Es bestehen zwei verschiedene Annäherungen zum Implementieren dieser Applikation:

• Datenimport-Wizzard
• Selbstzusammenstellen (klassischer) Applikation mit Ausschneiden-und-Einfügen-Konfigurationsfeldern.

Wir werden uns auf die zweite Lösung konzentrieren.
Der visuelle Inhaltsmanager ("VisualContentManager (VCM)") kann die gebräuchlichsten Dateien und Datentypen in das System importieren. Somit ist der visuelle Inhaltsmanager ("VisualContentManager (VCM)") das Tool zum Umwandeln bestehender Daten in Inhalt wie hinsichtlich des gegenwärtigen Systems der Erfindung. Dieser Ablauf ist notwendig, weil die Darstellung von innerhalb des Systems befindlichen Daten von "normalen" unterschiedlich ist. Im Wesentlichen ist deshalb der VCM eine User-Schnittstelle zum Schreiben an die Hauptdatenbanken (Inhalts-DB, "ContentDB") des Systems. Es ist keine Aufgabe des visuellen Inhaltsmanagers ("VisualContentManager (VCM)"), "Ansichten" für Inhalte zu konfigurieren, d.h. Daten zu formatieren. Dies liegt in dem Aufgabengebiet des Ansichtenerstellungselements (ViewComposer (VC)").
Zweitens bietet der VCM die Möglichkeit, bestimmte Attribute irgendeines Inhalts visuell zu verändern. Dies ist dem bzw. der vorstehend beschriebenen Import/Eingabe sehr ähnlich. Der einzige Unterschied ist, dass der User keine Datei öffnet oder neue Daten erzeugt, sondern den gewünschten Inhalt aus der Inhaltsdatenbank ("ContentDataBase") abruft, damit er editiert werden kann.
Es ist nur ein nächster Schritt, dass der Verwalter bzw. Administrator in der Lage ist, einen Inhalt nicht nur zu verändern, sondern ihn auch zu löschen. Außerdem besteht eine weitere in die Editier-/Lösch-Funktion eingebettete Funktionalität: ein Such-Tool. Weil mancher Inhalt durch seine Seriennummer ziemlich codiert ist, muss es ein leistungsstarkes Mittel geben, irgendwelche vorgegebenen Daten durch bestimmte Schlüssel, Attribute oder "Substrings" von diesem Inhalt abzurufen.
Somit ist es naheliegend, dass alle Komponenten des VCM über die Seriennummer ("SerialNumber") funktionieren. Das Eingabe-Tool muss eine gültige Seriennummer ("SerialNumber") erzeugen und alle Tools konfigurieren die Seriennummer ("SerialNumber"), verändern oder suchen sie.
30 zeigt ein Beispiel, wie eine grafische User-Schnittstelle aussehen könnte: auf der linken Seite werden alle bis jetzt (in der Inhaltsdatenbank ("ContentDB")) verfügbaren Inhalte in einem Baum angezeigt. Dies ist möglich, weil der Inhaltsstamm und die Untertypen eine hierarchische Klassifizierung von Inhalten ermöglichen.
Der User (in diesem Fall, der Administrator) kann einen neuen Inhalt einfügen, wobei er den Super-"Ordner" (Inhaltstyp) auswählt und ein neues Nachfolgerelement einfügt. Jeder Inhalt ist ein Blatt in diesem Inhaltsbaum. Knoten und Blätter können umbenannt und gelöscht werden. Mit Drag&Drop-Funktionalität können Inhalte von einem "Unterordner" (oder Unterbaum) zu einem anderen gezogen werden. Was jedoch interessanter ist, ist die Suchfunktion.
Wenn der User den "Such..." Button drückt, wird ihm zuerst ein Fenster präsentiert, worin er zwischen verschiedenen Kriterien wie Datentyp (Abbildung, Text, Überschrift ...), Inhaltstypnamen (Kategorie- oder Unterkategorie-Namen), Sicherheitseinstellungen, Länderanzeiger und irgendein anderes verfügbares Attribut auswählen kann.
Nachdem er seine Suchkriterien ausgewählt hat, kommt der User an einem Fenster mit Comboboxen für die tatsächlichen Inhaltsattribute an. Er muss auch in der Lage sein, nach Spannweiten und Sätze von Daten zu suchen (z.B. alle zwischen 1/1/1999 und 31/3/1999 erzeugten Inhalte, alle Inhalte mit Ländercodes 21–24) sowie nach irgendwelchen möglichen Kombinationen (z.B. in 1998 erzeugter Inhalt mit Sicherheitsstufe 3–5, im Allgemeinen von 12 pm bis 6 pm an Werktagen gültig, mit irgendwelchen speziellen Einstellungen für Einwohner von Schweden). Es kann auch möglich sein, die Suche auf Ansichten für Inhalte auszudehnen (z.B. Inhalt für Leute zwischen 18–25 mit der Ansicht "Cool View 3" – siehe nachstehend für mehr Information über Ansichten).
Um eine Liste möglicher Attribute präsentieren zu können, muss der VCM über eine Tabelle gegenwärtig bekannter Attributen verfügen. Alternativ dazu besteht für den User eine freie Textsuche; er kann einfach nach einem Inhalt mit bestimmten Attributen fragen und bekommt eine Antwort, oder keine, oder möglicherweise das Nächstpassende.
Alle wichtigen Attribute eines bestimmten Inhalts, der jeweils konfiguriert wird, werden in der "Einzelheiten"-Tabelle aufgelistet (oben: "Seriennummereinstellungen ("SerialNumber settings"). Dieser Katalog basiert auf der Seriennummer. Jedoch passen seine Zeilen nicht zu den Eingängen der Seriennummer ("SerialNumber"). Stattdessen stellen sie einen User-freundlicheren Weg des Bearbeitens der in dem Seriennummern-String ("SerialNumber string") enthaltenen Codes und Themen dar. Anstelle codierter Nummern kann der Administrator unter beschreibenden Elementen auswählen. Hier steht wie die wichtigsten Einstellungen gehandhabt werden:

• Der Inhaltsstammtyp ("Content Master Type") und Inhaltsuntertypen ("Content Subtypes") werden implizit mit der Baumsteuerung auf der linken Seite konfiguriert eingestellt. Mit einfachen Drag&Drop-Operationen kann der Administrator leicht Inhalte klassifizieren und Typen konfigurieren.
• Die Aktiv-/Inaktiv-Einstellung kann eingestellt werden zum Signalisieren, dass dieser Inhalt verfügbar und "aktiv" ist oder nicht.
• Die Sicherheits-ID ("Security ID"), bestehend aus Sicherheitsgruppe ("Security Group") und Sicherheitsstufe ("Security Level"), ist eine vierstellige Nummer. Ihre Bedeutung sollte aber für den VCM beschreibender sein. Deshalb könnte auch ein spezielles Fenster bestehen, das auf Einmalklick auf der rechten Seite der Tabelle in der Zeile "Sicherheit" ("Security") erscheint.
• Die Alterseignungs-ID ("Age Suitability ID") kann mit Hilfe eines speziellen Fensters, das erscheint, wenn der User in die rechte Ecke (gekennzeichnet mit "...") der rechten Zelle eines Eintrags in der "Einzelheiten"-Tabelle klickt. Dies ist der auch von anderen Tools (siehe Visueller/Grund-Editor ("Visual/Basic editor"), Zusammen ("Together"); ...) benutzte Weg, um komplexere Eingänge zu bearbeiten.
• Die Bildungsumfangs-Einstellung (Education Range Setting") ist ein vierstelliger, obere und untere Bildungsgrenzen für den Inhalt beschreibender Code.
• Der Sprachen-ID ("Language ID") wird nicht als dreistelliger Code (z.B. "002" für Spanisch), sondern als Text ("Spanisch") angezeigt. Es ist möglich, Kombinationen von Sprachen zu spezifizieren (möglicherweise gibt es einen Text in Englisch und Spanisch).
• Datums-/Zeit-Beginn ("Date/Time Beginning") (12 Stellen), Datums-/Zeit-Ablauf (zwölf Stellen). Für diese Einstellungen sollten dem User die Daten in üblichen Datenformaten (keine 12 zusammengefassten Zahlen) präsentiert werden.
• Länderverfügbarkeitscode ("Country Availability Code"). Ähnlich der Sprachen-ID ("Language ID") kann der User unter einer Liste von Ländern sowie Kombinationen von Ländern auswählen. Das kann natürlich wieder ein separates Fenster erfordern.
• Länderausschlusscode ("Country Exclusion Code"). Siehe Länderverfügbarkeitscode ("Country Availability Code").
• Der Allgemeine Applikationscode ("General Application Code") beschreibt (sehr allgemein), wofür dieses Element am meisten verwendet wird. Man könnte z.B. für Szenarien passende Beschreibungen bieten, wie "Datenbanken" ("Databases"), "Informationstechnologie" ("Information Technology") (für Server), "Information", "Unterhaltung" ("Entertainment") (für Artikel des Zeitungsszenarios), und so weiter. Der User sollte in der Lage sein, unter Beschreibungen wie diesen auszuwählen.
• Historische(s) Erzeugungs-Datum/-Zeit ("Creation Date/Time") (14 Stellen). Historische(s) Ablauf-Datum/-Zeit ("Expiration Date/Time") (14 Stellen). Gleich wie für Datum-/-Zeit-Beginn/-Ende ("Date/Time Beginning/End"), jedoch bis auf Sekunden herunter.
• Der spezielle Sicherheitsschlüssel ("Special Security Key") ist ein siebenstelliger Zugriff auf diesen Inhalt und kann in den VCM über eine Passwort-Textbox eingegeben werden.

Es ist naheliegend, dass alle Attribute und ihre Bedeutung (IDs Codieren wie 000 = Englisch, 001 = Deutsch, ... und so weiter) Meta-Daten sind, die in einer Meta-Datenbank (Inhaltsstammkatalog ("Content Master Catalog") siehe vorstehend) gespeichert werden können.
Ansichten/Darstellungen
Die Elemente, die in der CT gespeichert sind, werden in dem Ansichten-/Darstellungen-Baum ("Views/Representations Tree") angezeigt. Der User kann einen Eintrag von Ansichten/Darstellungen ("Views/Representations") auswählen (Überlassen) und diese Ansicht wird auf der rechten Seite des VCM-Tab-Panes angezeigt. Der User kann ebenfalls neue Ansichten für diesen Inhalt eintragen. Hinzufügen/Importieren von Inhalt kann durchgeführt werden

• Mittels der Toolbox für den VCM (31). Diese Toolbox wird in dem vorstehenden Screenshot nicht angezeigt; jedoch sollte sie gezeigt werden, wann immer der User den VCM-Tab auswählt.
• Mit einer Datei-Dialogbox, die z.B. ein Bild in den VCM-Pane einfügt.
• Mit Cut&Paste-Funktionalität, möglicherweise in Kombination mit der Toolbox. Z.B. kann der User die Textbox auswählen und dann in sie irgendeinen Text einfügen.

Mit Hilfe der Toolbox für den VCM kann der Administrator leicht Buttons, Textfelder, Auswahlboxen, Radio-Buttons, Paragraphen, Überschriften, Bilder und Tabellen erzeugen. All diese können als Teile von Inhalt betrachtet werden. Andere Arten von Kontext können über die Datei-Dialogbox erzeugt und geladen werden. Was immer der User hinzufügt oder importiert, der VCM-Pane bietet die Möglichkeit innerhalb bestimmter Grenzen zu editieren.
Der "Füge Darstellung hinzu"-Button ("Add Representation" button) fügt die spezielle Darstellung dieses Inhalts, der gegenwärtig auf dem VCM-Pane gezeigt wird, dem Ansichten-/Darstellungen-Baum ("Views/Representations Tree") hinzu. Gleichzeitig wird die Darstellung in der Inhaltstabelle ("ContentTable") gespeichert. Die entsprechende Ansichten-ID ("ViewID") (dies ist ein grundlegender Ansichtentyp!) wird im laufenden Betrieb konfiguriert und eingestellt.
Ähnlich verhält es sich mit "Sichern ("Save")". Der einzige Unterschied ist, dass keinen neuen Eintrag in den Ansichten-/Darstellungen-Baum ("Views/Representations Tree") gibt, sondern der gegenwärtig ausgewählte Eintrag aktualisiert wird (auch in der CT!).
Das Ansichtenerstellungselement ("ViewComposer") (siehe 32) ist das Tool zum Konfigurieren von "Ansichten" für Inhalt. Als solches erzeugt die CT Schablonen für Seiten, die durch das w³OS angefordert werden. Die Ansichten werden durch das Seitenerstellungselement ("Page Composer") (PC) analysiert und verarbeitet, damit eine tatsächliche, dynamische Webseite erzeugt werden kann.
Ansichten können gefüllt oder leer sein. Das VC kann jedoch zum Erzeugen von beiden verwendet werden. Im Grunde verwendet es die in 33 dargestellten Frames:

1. Eine DTD-Datei für Ansicht ("View") Nr. 1, 2, 6
2. Eine DTD-Datei für Ansicht ("View") Nr. 3, 4, 5
3. Eine DTD-Datei für Ansicht ("View") Nr. 7
4. Eine DTD-Datei für Ansicht ("View") Nr. 8
5. Eine leere XML-Datei für jede der obigen Ansichten mit lediglich einer Tag-Definition (Tags werden Prioritätszahlen entsprechen, wie sie durch den CDM an das PC in RpPageData übergeben werden)
6. XSL-Datei für jede der obigen Ansichten können in HTML 4.0 dargestellt werden

Der User kann mit Hilfe von in der Frames-Toolbox verfügbaren Frames leere Ansichten erzeugen. Dies ist dieselbe Toolbox wie in der vorherigen Version des VC gezeigt (34). Wie die Toolbox des VCM wird die Frames-Toolbox in dem Schirmbeispiel für das kombinierte VCM-/VC-Tool nicht gezeigt, aber sollte angezeigt werden, wenn der User den VC-Tab auswählt.
Leere Ansichten werden durch wiederholtes Auswählen eines Frames aus der Toolbox und sein (rekursives) Einfügen in bestehende Frames erzeugt. Leere Ansichten sind immer Seitenansichten, d.h. Ansichten, die eine Schablone für eine ganze Webseite darstellen. Sie können nur in der Ansichtentabelle ("ViewTable") gesichert (Button "Sichern" ("Save")), aber keinem Inhalt zugeordnet werden.
Das VC ermöglicht ferner das Erzeugen von Ansichten, die direkt mit Inhalt oder anderen Ansichten verbinden sind. Der User beginnt genauso wie mit leeren Ansichten, i.e. dem Erzeugen von Schablonen. Aber nun brauchen die anfänglichen Frames für die Ansicht keine ganze Webseite zu sein, sondern können kleiner sein, um eine Zusammenstellung, d.h. eine Aggregation von Ansichten, zu erzeugen. Wenn der Frame für die Ansicht erzeugt worden ist (unter Verwendung der Toolbox), kann der User Inhalt und Darstellungen/Ansichten dieses Inhalts auswählen. "End"-Elemente werden in dem Ansichten-/Darstellungen-Baum ("Views/Representations Tree") gezeigt; der User kann einen Eintrag auswählen und ihn in einen Frame auf dem VC-Pane einfügen.
Es besteht immer ein "Startpunkt"-Inhalt, d.h. der User wählt irgendeinen bestimmten Inhalt aus und beginnt dann, eine Ansicht für diesen zu erzeugen. Er kann Ansichten/Darstellungen dieses Inhalts sowie irgendwelche anderen Ansichten/Darstellungen anderer Ansichten einfügen. Auf ähnliche Weise kann es dem User möglich sein, die rechte Maustaste in einem bestimmten Frame auf dem VC-Pane zu drücken und eine Liste aller verfügbaren Ansichten präsentiert zu bekommen. Auf diese Weise kann der User verschachtelte Ansichten erzeugen sowie Ansichten, die "externe" Verweise, d.h. Verweise auf Ansichten von anderem Inhalt enthalten.
Einfach gerade heraus gesagt, gefüllte Seitenansichten, die nicht in Bezug zu irgendeinem bestimmten Inhalt stehen, enthalten nur externe Verweise. Es bestehen zwei Wege für das Speichern von Ansichten:

• Speicherung in der Ansichtentabelle ("ViewTable"). Wenn "Ansicht sichern ("Save View")" gedrückt ist, wird die gegenwärtige Ansicht nur in der Ansichtentabelle ("ViewTable") gespeichert. Alle Verweise auf verschachtelte Ansichten werden relativ gespeichert, alle Verweise auf Inhalte oder konkrete Ansichten/Darstellungen werden mit der Inhalts-ID ("Content ID") und der Ansichten-ID ("ViewID") der CT gespeichert (i.e. als externe, absolute Links gespeichert).
• Speicherung mit einem bestimmten Inhalt. In diesem Fall würde die Ansicht in der CT gespeichert werden. Die Frage ist, zu welchem Inhalt diese Ansicht gehört: Zu der CT des "Startinhalts" oder dem gegenwärtig gezeigten Inhalt und seiner Ansichten-/Darstellungen-Ansicht ("Views/Representations View")? Der Startpunkt wäre logisch, weil der User mit dem Hinzufügen konkreter Ansichten/Darstellungen des ersten Inhalts die Erzeugung begonnen haben kann. Irgendeine Inhaltsauswahl nach dem anfänglichen Inhalt hätte zu absoluten Verweisen/externen Links geführt. Daher können wir den User fragen (nach dem Drücken von "Ansicht zuweisen ("Assign View")", ob er die Ansicht dem gegenwärtigen Inhalt oder dem ersten Inhalt zuweisen möchte. Dem gemäß werden entweder die ersten Verweise absolut oder die neuesten.

Auf jeden Fall erfordern all diese Auswahlvorgänge von Inhalten, Abrufung von Ansichten, Speicherung von Ansichten, ... Kommunikation mit der Datenbank (über das bzw. den BOS/CDM). Das Format dieser Anforderungen und Mitteilungen wird in Kürze beschrieben.
Der User kann mit dem VC nicht nur neue Ansichten erzeugen, sondern auch eine bestehende Ansicht öffnen und ihre Verweise verändern, was in einer neuen Ansicht resultiert. Diese neue Ansicht kann dem Inhalt zugewiesen werden und wird in dem Ansichten-Darstellungs-Baum ("Views/Representations tree") aufgelistet (d.h. in der CT dieses Inhalts gespeichert). Auf ähnliche Weise kann der User eine bestehende Ansicht öffnen und sie ohne Veränderungen dem Inhalt zuweisen.
Noch ein anderes Szenario ist, dass wenn der User einen bestimmten Inhalt öffnen kann, wird/werden ihm die/der Liste/Baum von Ansichten/Darstellungen präsentiert. Er wählt einen Eintrag aus und die Ansicht wird auf dem VC-Pane gezeigt. Er kann nun einen anderen Inhalt auswählen und sieht seinen Ansichten-/Darstellungs-Baum (= CT). Er kann die Ansicht dieser CT zuweisen; die Verweise würden aktualisiert werden, um auf die örtlichen Einträge der CT hinzudeuten. Folgerichtig muss der User gewarnt werden, wenn es fehlende Ansichten/Darstellungen gibt, auf die Bezug genommen werden würde.
Im Folgenden wird eine ausführlichere Beschreibung der Funktionalitäten der visuellen Tools ("VisualTools") abgegeben. Ausgehend von irgendwelchen Anwendungsfällen, die die wichtigsten Szenarien der VTools abdecken, können wir die Tasks der VTools analysieren und letztlich das Datenmodell definieren.
Anwendungsfälle
35 zeigt schematisch Anwendungsfälle für den CDM. Man kann die folgenden Anwendungsfälle für den visuellen Inhaltsmanager ("VisualContentManager (VCM)") identifizieren. Die meisten Anwendungsfälle bestehen aus irgendeiner auf die GUI (graphische User-Schnittstelle ("graphical user interface (GUI)")-Seite wirkenden Aktion und irgendetwas Komplementärem auf der Seite der bzw. des BOS/CDM. Wie wir später sehen werden, benötigt man eine VTools BTE in der BOS.

• Inhalt öffnen ("Open Content"). Dieser Anwendungsfall wird angewendet, wenn der Administrator den Inhaltstypenbaum des bzw. der VCM/VC GUI durchsucht. Der Administrator fragt mehrere Inhaltsstamm- und Unter-Typen ab und kommt schließlich an einem ein tatsächliches Inhaltsobjekt darstellenden Blatt an. Somit besteht der Inhalt-öffnen-Anwendungsfall ("Open Content use case") aus zwei Unterfällen:
• Durchsuchen bzw. Browsen von Inhalt in dem Inhaltstypbaum. Für jede neue geöffnete Baumebene muss die Stammkataloginformation über diese Ebene abgerufen werden. Wann immer irgendein Bereich des Stammkatalogs für die VTools GUI verfügbar ist, wird er im Gedächtnis bewahrt, so dass nachfolgende Tasks der GUI sowohl Beschreibungen von Stammkatalogeinträgen als auch die Codes selbst behandeln können. Der Punkt ist hier, dass die VTools GUI die User-lesbaren Beschreibungen von Inhalt und Inhaltsattributen präsentieren muss. Andererseits werden Inhaltsattribute codiert in der Inhaltsdatenbank gespeichert. Der Inhaltsstammkatalog, der ebenfalls in der Inhaltsdatenbank aufbewahrt wird, bildet Seriennummercodes auf den Beschreibungen ab.
• Öffnen von tatsächlichem Inhalt. In diesem Fall muss die VTools BTE alle Information aus der CT und der CIT abrufen, d.h. die Seriennummer, die Default-Ansichten-ID ("default ViewID") und Beschreibungen der Ansichten müssen an die VTools GUI übermittelt werden.
• Nach Inhalt suchen. Ein sehr spezieller Anwendungsfall behandelt die Suche nach Inhalt. Da die Seriennummer und alle Attribute von Inhalt eine sehr spezielle und detaillierte Suche ermöglichen, ist dieses Tool sehr leistungsstark. Auf Grund der Komplexität der Suchfunktionalität ist sie von dem VCM-Pane getrennt und arbeitet in verschiedenen Fenstern (siehe nachstehend).
• Einzelne Inhaltsattribute editieren. Der Administrator muss in der Lage sein, verschiedene Inhaltsattribute zu editieren. Nachdem "Sichern ("Save")" gedrückt worden ist, werden die Einstellungen mit Hilfe der für das System verfügbaren Teile des Inhaltskatalogs codiert. Auf diese Weise aktualisiert der VCM die Seriennummer. Dann werden diese Daten an den CDM übermittelt und die CT wird entsprechend aktualisiert.
• Inhaltsgruppe aktualisieren. Dies ist der wesentliche Anwendungsfall für das Militär-/Sicherheits-Szenario. Der Administrator kann eine Gruppe von Inhalt durch Bereitstellen eines Teilsatzes von Inhaltsschlüsseln auswählen. Der VCM muss dann eine Mitteilung an den CDM erzeugen, die Attribute aller Einträge in der CT entsprechend zu verändern.
• Neuen Inhalt erzeugen. Der Administrator kann (mittels der VCM Toolbox) neuen Inhalt erzeugen. In diesem Fall muss der VCM die Einstellungen codieren, um eine neue Seriennummer zu erzeugen. Im Allgemeinen kann der Inhaltstyp der neuen Seriennummer auf irgendwelchen bestehenden (und verfügbaren) Inhaltstyp-Codes basieren. An dem CDM müssen neue Datensätze für die CT sowie für die Inhalts-SN-Beschreibungstabelle ("Content SN Description Table") erzeugt werden. Eine neue Inhalts-ID muss ebenfalls erzeugt werden.
• Inhaltsdarstellung hinzufügen. Wenn der Administrator eine neue Darstellung für einen bestimmten Inhalt hinzufügt, müssen die VTools eine Mitteilung erzeugen, die die tatsächlichen Daten an den CDM übergibt. Dort wird die Darstellung in der CIT gespeichert. Falls es die erste Darstellung ist, muss sie in der CT als die Default-Ansicht ("DefaultView") eingestellt werden.
• Inhaltsdarstellung editieren. Der Administrator kann eine Ansicht/Darstellung aus der bzw. dem Liste/Baum in der unteren linken Ecke der VTools GUI auswählen. In dem VCM-Modus wird die Darstellung auf dem VCM-Pane angezeigt. Der User kann das Element verändern oder es durch ein anderes ersetzen. Wenn der Administrator "Füge Darstellung hinzu ("Add representation")" erneut drückt, wird er gefragt, ob er die alte Ansicht/Darstellung wirklich ersetzen will. Wenn ja, verstellt die VTools GUI Einstellungen falls erforderlich (Ansichten-ID & -Typ ("ViewID & Type")) und ersetzt den Ansicht-/Darstellungs-Eintrag. Der Administrator drückt den "Löschen ("Delete")"-Button, die gegenwärtig gezeigte Darstellung wird aus der Liste und der Ansichtentabelle ("View Table") in der Datenbank an dem EIC gelöscht.
• Inhalt löschen. Das VC bietet die Möglichkeit, ausgewählte Inhalte zu löschen. Möglicherweise kann diese Funktionalität auch mit dem Aktualisiere-Inhaltsgruppe-Szenario hinsichtlich "Löschung" als einer sehr speziellen Aktualisierung kombiniert werden. Aber trotzdem kann der Administrator zumindest einen Inhalt "laden" und auswählen, ihn zu löschen. Dann wird der bestimmte Inhalt aus der CT gelöscht und gleichzeitig werden alle Einträge seiner Darstellungen in der CT gelöscht. Falls ausschließlich diesem Inhalt zugeordnete Ansichten (Zusammenstellungen) bestehen, werden sie ebenfalls aus der Ansichtentabelle ("ViewTable") gelöscht.

Anwendungsfälle für das VC
36 zeigt schematisch Anwendungsfälle für das VC. Der Anwendungsfall für das Ansichtenerstellungselement ("ViewComposer") bestehen ebenfalls im Grunde aus irgendeiner auf die GUI wirkende Aktion und zusätzlich einem Fluss von Ereignissen an der bzw., dem BOS/CDM. Das VC könnte ebenfalls die VTools BTE für seine Zwecke nutzen. Der Administrator ist erneut der einzige betroffene Aktor.

• Ansicht erzeugen. Mit dem VC kann der Administrator eine neue Ansicht erzeugen. Das VC bietet einen Satz von Frames, die verschachtelt werden können. Auf diese Weise kann der Administrator komplexe Ansichten rekursiv einrichten.
• Ansicht öffnen/importieren. Während des Prozesses des Erzeugens einer neuen Ansicht können Ansichten, die bereits bestehen und die in der Ansichtentabelle ("ViewTable") gespeichert sind, geöffnet und in einen Frame eingefügt werden (d.h. in eine andere Ansicht einschachtelt werden). Der Administrator kann "Ansicht öffnen" drücken, um einen Ansichten-Browser zu starten, der alle Ansichten zeigt, die in der Ansichtentabelle ("ViewTable") verfügbar sind. An der VTools BTE müssen die Ansichtenbeschreibungen aus der Ansichtentabelle ("ViewTable") abgefragt werden, um sie in dem Browser-Fenster anzuzeigen. Es muss Mitteilungen von der VTools GUI an die BTE zum Anfordern von Beschreibungen geben sowie Mitteilungen zurück, um sie zu übertragen. Wenn das Öffnen einer Ansicht angefordert wird, muss ihr Datensatz abgerufen und an die VTools GUI zurückgesendet werden.
• Ansicht sichern. Wenn der Administrator auf "Ansicht sichern ("Save View")" klickt, wird die gegenwärtig gezeigte Ansicht "codiert", um in der Ansichtentabelle ("ViewTable") gesichert zu werden, d.h. die Verweise auf andere Ansichten werden erfasst und vorbereitet, um in dem XML-String-Feld ("XMLString field") gespeichert zu werden. Beschreibung und XSL-String müssen an die Datenbank gesendet werden; falls für diese Ansicht bereits ein Eintrag in der Ansichtentabelle ("ViewTable") besteht, muss die VTools BTE ihn aktualisieren.
• Ansicht den Inhaltsdarstellungen zuweisen. Wenn der Administrator eine Ansicht verändert oder eine neue erzeugt hat, kann diese Ansicht nicht nur in der Ansichtentabelle gesichert werden, sondern auch als eine Darstellung oder Default-Ansicht eines Inhalts. In diesem Fall kann der Administrator "Ansicht zuweisen ("Assign View")" drücken und ein neuer Eintrag wird in der CT des Inhalts hinzugefügt, der gegenwärtig in dem Inhaltstypenbaum und dem Ansichten-/Darstellungs-Baum unten gezeigt wird. Auf der Seite der VTools BTE bedeutet dies, dass es für eine neue Ansicht/Darstellung dieses Inhalts einen neuen Datensatz gibt. Jegliche Links oder Verweise in der Ansicht müssen angepasst werden, um der CT zu entsprechen.
• Ansicht löschen. Der Administrator kann eine bestimmte Ansicht löschen, wenn sie in dem VC-Pane gezeigt wird. In diesem Fall würde die Ansicht aus der Ansichtentabelle ("ViewTable") entfernt werden, aber für den Administrator wird eine Fehlermeldung angezeigt, falls er eine Ansicht zu löschen versucht, auf die durch andere Ansichten verwiesen wird.

Zum Ausführen der vorstehend erwähnten Anwendungsfälle werden zusätzliche Datenstrukturen verwendet, um die VTools in die Systemumgebung zu integrieren.
Damit die VTools mit der bzw. dem BOS/CDM kommunizieren, wird eine Implementierung von RpSystemMessage: VtoolsSystemMessage eingearbeitet, siehe 37.
Die Mitteilungen, die durch die VTools verwendet und angefordert werden, sind alle Nachfolgerelemente der IRpSystemMessage. Da die VTools direkt mit der bzw. dem BTE/CDM kommunizieren, bestehen keine anderen IRpSystemMessages, die irgendwelche Daten aus den VTools behandeln. Gemeinsame VTools-Systemmitteilungen ("VToolsSystemMessages") sind:

• objReturn-Empfänger ("objReturnAddresse"): entweder IComServer – der VTools-Schnittstellenfall ("VToolsInterface instance") – oder der anfängliche Sender (irgendeine Klasse von VTools GUI). Falls es der IComServer ist (wie in 43 angezeigt), muss die VTools-Schnittstelle ("VToolsInterface") den ursprünglichen Sender kennen bzw. wissen, ansonsten benötigen wir ein zusätzliches Feld, das die "Adresse" diese ursprünglichen Senders enthält (entweder in Form von irgendeiner ID oder des tatsächlichen Klassennamens).
• bAnforderung ("bRequest") zeigt an, ob dies eine Anforderung an die BTE oder irgendeine Antwort ist. "Richtig ("true")" bedeutet, dass dies irgendeine Mitteilung an die BOS/VTools BTE ist, "falsch ("false")" bedeutet, dass dies eine Mitteilung von dort zurück an die VTools GUI Elemente ist. Wir müssen möglicherweise darüber nachdenken, ob dies ausreichend ist, um verschiedene VToolsSystemMessages zu unterscheiden.
• nMitteilungs-ID ("nMessageID"). Dies ist ein eindeutiger, durch die BOS-Registrierungsberechtigung ("BOS Registration Authority") geforderter Identifikator für den "Anforderungstyp", um festzustellen, welches BOS-Mittel ("BOSAgent") diese Nachricht aufrufen muss. Das Vermittlungs- bzw. Agentur-Verfahren getAgentNameForRequestType(intiRequestType) benötigt diese ID.

VTools-Mitteilungen ("VToolsMessages") können in vier grundsätzliche Gruppen klassifiziert werden, die direkt den verwendeten Datentabellen entsprechen. Es ist, weil wenn wir die Tasks in den Anwendungsfällen zusammenfassen, wir die folgenden Hauptdatenflüsse identifizieren können:

• Anforderung für Seriennummernbeschreibungen (aus der Inhaltsstammtabelle ("ContentMasterTable")). Sind Snr-Beschreibungs-VT-Mitteilungen ("SnrDescriptionVTMessages"). Es ist möglich, dass mehrere Seriennummern angefordert werden. Diese Anforderungen werden benötigt, um sukzessiv den Inhaltstypbaum bilden. Außer diesem muss die VTools GUI alle "zusätzlichen Gruppen-" Seriennummern und ihre Bedeutungen kennen bzw. wissen. Deswegen scheint es sinnvoll, dass die VTools all diese Tabellen und Information am Startzeitpunkt abrufen sollten, weil die Daten die ganze Zeit benötigt werden.
• Antworten für diese Anforderungen. Sie können einen (Teil-)Satz von Seriennummern und ihre Beschreibung enthalten. Der Teilsatz deckt ein ganzes Segment in dem Baum von Seriennummern ab. Die VTools GUIs benötigen sowohl den Seriennummern-Schlüssel als auch den -Wert (die -Beschreibung), denn sobald ein neuer Inhalt erzeugt worden ist oder irgendwelche Inhaltsattribute abgeändert worden sind, sollten die VTools nicht beschreibenden Text zurücksenden (an das bzw. den BOS/CDM und schließlich an die Datenbanken), sondern lediglich die veränderte Seriennummer selbst (in einem Inhaltsbeschreibungsobjekt ("ContentDescription object"). Die Ansichten-BTE ("ViewBTE") (oder Seriennummern-BTE ("SerialNumberBTE")?) muss ein der Snr-Beschreibungs-VT-Mitteilung ("SnrDescriptionVTMessage") zuzuweisendes Snr-Beschreibungsobjekt ("SnrDescription object") erzeugen.
• Anforderungen für Inhaltsbeschreibungen (d.h. Inhalts-Information und -Daten über die Darstellungen) werden an das BOS gesendet, wenn der VCM einen tatsächlichen Inhalt anzeigen will. Die Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") enthält die Seriennummer des zurückzusendenden Inhalts (die Nummer ist bekannt, weil sie vorher mit einer SnrDescriptionVTMessage abgerufen wurde).
• Antworten für diese Anforderungen enthalten ein Non-Null-Inhaltsbeschreibungsobjekt ("non-null ContentDescription object"). Im Wesentlichen enthält dieses Rücksendungsobjekt die Attribute des CT-Datensatzes für den bestimmten Inhalt. Außer diesen Daten gibt es einen Vektor mit allen Beschreibungen von Darstellungen für diesen Inhalt (nicht die Daten von Darstellungen selbst!). Das Inhaltsbeschreibungsobjekt ("ContentDescription object") enthält die Seriennummer in Form eines Inhaltsseriennummernobjekts ("ContentSerialNumber object") (siehe 38).
• Andererseits können Inhaltsbeschreibungs-VT-Mitteilungen ("ContentDescriptionVTMessages") auch zum Aktualisieren oder Sichern von Inhalt verwendet werden.
• Wenn eine Suche nach Inhalten durchgeführt wird, müssen wir verschiedene Seriennummern ermitteln, die bestimmten Suchkriterien entsprechen. Die codierten Darstellungen dieser Suchkriterien werden noch an dem VCM erzeugt (dies kann geschehen, da der VCM eine Liste aller Seriennummer-Substrings und ihrer Bedeutungen haben muss, siehe nachstehend). Somit codiert der VCM alle Suchkriterien und bildet eine Seriennummer die zu ihnen passt. Außerdem kann er einen sEnthaltenenText-String ("sContained Text string") bereitstellen, der die Durchführung einer vollständigen Textsuche ermöglicht, d.h. nach irgendeinem Ausdruck in der gesamten Datenbank zu suchen.
• Wenn der Administrator eine bestimmte Darstellung eines Inhalts betrachten möchte, feuert die VTools GUI eine Darstellungs-VT-Mitteilung ("RepresentationVTMessage") ab, die diese Darstellung anfordert. Folglich überträgt sie eine CITID und die ID der CT, damit sie die erforderliche Darstellung ermitteln kann.
• Die Antwort auf eine Darstellungs-VT-Mitteilung ("RepresentationVTMessage") enthält ein Darstellungsobjekt, das wiederum die tatsächlichen Daten enthält.
• Umgekehrt kann die VTools GUI selbst solch eine Darstellung senden (gekapselt durch eine Darstellungs-VT-Mitteilung ("RepresentationVTMessage")), gefüllt mit irgendeinem neu erzeugten Element, das in der Datenbank gespeichert werden muss.
• Der vierte Typ einer VTools-Systemmitteilung ("VToolsSystemMessage") ist die Ansichten-VT-Mitteilung ("ViewVTMessage"). Die Aufgabe dieser Mitteilung ist, Information über Ansichten zu transportieren. Diese Informationen können sein
• Kurzbeschreibungen (Namen) von Ansichten, Wenn beispielsweise der Administrator eine Ansicht öffnen möchte und den Ansichten-Browser startet, muss die VTools GUI von allen verfügbaren Ansichten wissen. Sie würden eine Ansichten-VT-Mitteilung ("ViewVTMessage") an die VTools BTE senden, eine Liste aller Ansichten zurückzusenden.

Kurzbeschreibungen sind Ansichtenbeschreibungsobjekte ("ViewDescription objects"), aber ihre sXmlString Glied-Variable ("sXmlString member variable") ist leer ("null"). Wie vorstehend beschrieben sind diese Ansichten-VT-Mitteilungen ("ViewVTMessages") Anforderungen für Beschreibungen von Ansichten. Die Ansichten-VT-Rückmeldung ("return ViewVTMessage") enthält einen Vektor von Ansichtenbeschreibungen ("ViewDescriptions").

• Vollständige Ansichteninformation. Sobald der Administrator eine bestimmte Ansicht öffnen möchte (indem er sie in dem Ansichten-Browser auswählt), erzeugt die VTools GUI eine Ansichten-VT-Mitteilungsanforderung ("ViewVTMessage request") mit der (kurzen) Ansichtenbeschreibung ("(short) ViewDescription") für diese Ansicht. Der BOS/CDM/VToolsBTE antwortet mit der entsprechenden (vollständigen) Ansichtenbeschreibung ("(full) ViewDescription"), d.h. einschließlich des XML-Strings. Zu beachten: Falls dies zu kompliziert wird und die XML-Strings ohnehin sehr klein sind, könnte eine Alternative sein, mit einer (vollständigen) Ansichtenbeschreibung ("(full) ViewDescription") zu gehen, die bereits mit dem Öffnen des Ansichten-Browsers zurückgesendet wurde.
• Wenn der Administrator mit dem VC eine neue Ansicht erzeugt und den "Ansicht zuweisen ("Assign View") Button gedrückt hat, muss diese Ansicht in der Ansichtentabelle gespeichert werden. Erstens müssen die VTools GUI alle Links in dem Ansichten-XML- String (auch "externe") klären. Dann wird die Beschreibung in der GUI-Liste von Ansichten gespeichert (auf diese Weise kann man das gesamte Bündel von Ansichten so lange speichern bis die VTools abgeschaltet werden, davor bearbeitet man nur örtliche Daten). Drittens sendet die GUI eine Ansichten-VT-Mitteilung ("ViewVTMessage") mit einer (vollständigen) Ansichtenbeschreibung ("(full) ViewDescription") an die VTools BTE, um eine Ansicht an die Ansichtentabelle ("ViewTable") geschrieben zu bekommen. [ZU BEACHTEN: die VTools GUI ist für das Erzeugen von neuen Ansichten-IDs ("ViewIDs") für User-definierte Ansichten verantwortlich.] Viertens muss die VTools BTE auch die Daten der Ansicht in der CT speichern. Zu diesem Zweck sind die CITID und zusätzliche Links Teil des Ansichtenbeschreibungsobjekts ("ViewDescription object"). Falls keine "externen" Links bestehen (Links zu Darstellungen anderer Inhalte), ist der slinks-String leer.
• Falls eine Ansicht gesichert werden sollte, ohne einem Inhalt zugewiesen zu sein (wie eine Darstellung), ist sie entweder eine leere Ansicht oder eine gefüllte Ansicht mit Verweisen auf Inhalte (d.h. ihre Default-Ansicht oder irgendeine ausgewählte Darstellung). In beiden Fällen, wenn der Administrator "Ansicht sichern ("Save view")" drückt, produziert die VTools GUI eine Ansichten-VT-Mitteilung ("ViewVTMessage") mit einer Ansichtenbeschreibung ("ViewDescription") mit leeren nCitid und empty sLinks ("nCitid and empty sLinks"). Die VTools GUI hat eine neue einzigartige Ansichten-ID ("ViewID") für die neue Ansicht erzeugt.

VTools & BOS/CDM-Schnittstellen
Wie werden die VTools-Systemmitteilungen ("VToolsSystemMessages") von VTools-Gui-Klassen an das bzw. den BOS/CDM (und letztlich die BTE) und umgekehrt übergeben? Da die zwei Komponenten getrennt werden könnten oder zumindest in unterschiedlichen Java virtuellen Maschinen ("Java Virtual Machines") laufen könnten, müssen sie über RMI oder andere entfernte Ablaufaufruf-Implementierungen kommunizieren. Wir können das Kommunikations-Wrapper-Prinzip zum Einführen der Inter-w³OS- Kommunikation verwenden. Der VTools-Komponente und der bzw. dem BOS/CDM einschließlich der Gate-Struktur angepasst sieht es aus wie in 39 gezeigt. Auf der linken Seite in 39 kann man sich die VTools-Objekte und -Klassen vorstellen. Wenn sie irgendeine VTools-Systemmitteilung ("VToolsSystemMessage") an das BOS senden möchten, müssen sie mit der VTools-Schnittstelle ("VToolsInterface") in Verbindung treten, die die ICom-Klientenimplementierung ("IComClientImplementation") für die VTools-Komponente ist. Jedoch ist die VTools-Schnittstelle ("VTools-Interface") gleichzeitig auch ein ICOMServer für eingehende VTools-Systemmitteilungen ("VToolsSystemMessages") (im Diagramm nicht gezeigt). Die Klasse, die ihre VTools-Systemmitteilung ("VToolsSystemMessage") an das BOS senden möchte, ruft den VTools-Schnittstellenprozess ("VToolsInterface.process") auf (die VTools-Systemmitteilung ("VToolsSystemMessage")).
In dem Namensraum von BOS wird ein Fall ("instance") von IComServer registriert, der ausschließlich für VTools-Kommunikations-Tasks implementiert ist. Dies ist das VTools-EIN-Gate ("VToolsInGate"), das das BOS-EIN-Gate ("BosInGate") erweitert und den IRmiServer implementiert (falls RMI die Kommunikationstechnik ist). Der (Singleton-)Fall ("(singleton) instance") von dem VTools-EIN-Gate ("VToolsInGate") (bzw. sein Registrierungsschlüssel) ist der VTools-Schnittstelle ("VTools-Interface") bekannt; somit kann sie mit dem VTools-EIN-Gate ("VToolsInGate") in Verbindung treten.
Sobald das VTools-EIN-Gate ("VToolsInGate") die VTools-Systemmitteilung ("VToolsSystemMessage") empfangen hat, ist der Ablauf für alle durch das BOS verarbeiteten RpSystemmitteilungen ("RpSystemMessages") gleich (siehe die durch das BOS-Team bereitgestellte Dokumentation):

1. Die VTools-Systemmitteilung ("VToolsSystemMessage") wird zu dem BosInGate hochgereicht (mit BosIn-Gate(processobjVToolsSystemMessage) und von da wird Agency.getInstance().process(objVToolsSystemMessage) aufgerufen.
2. Innerhalb der Vermittlung bzw. Agentur wird das Verfahren returnAgentName ("VTools-Systemmitteilung ("VToolsSystemMessage")) gestartet. Dabei wird in einer Hash-Tabelle nachgeschlagen. Diese Hash-Tabelle muss Objekte/Mitteilungen des Typs VTools-Systemmitteilung ("VToolsSystemMessage") (oder einfach den Mitteilungs-ID-String) auf dem "VTools-Mittel" ("VToolsAgent") abbilden, das der Rücksendungswert für dieses Verfahren ist.
3. Dann werden dieser String und die anfängliche VTools-Systemmitteilung ("VToolsSystemMessage") der BOS-Fabrik ("BosFactory") übergeben. Die BOS-Fabrik ("BosFactory") erzeugt letztlich einen Fall von VTools-Mittel ("VToolsAgent") (Erweitern des Threads) und weist es der ursprünglichen VTools-Systemmitteilung ("VToolsSystemMessage") zu. Wie dieses VTools-Mittel ("VToolsAgent") im Einzelnen aussieht, wird im nächsten Kapitel beschrieben. Auf jeden Fall wird das VTools-Mittel ("VToolsAgent") an den Anforderungs- Scheduler ("RequestScheduler") übergeben. Nur wenn es dem Thread ermöglicht wird zu laufen, wird er gestartet; ansonsten wird das Ready-to-Run-VTools-Mittel ("ready-to-run VToolsAgent") in eine Warteschlange gestellt.
4. Das VTools-Mittel ("VToolsAgent") ruft Agency.getChannelsForAgent(this) auf. Dieses Verfahren schlägt in einer anderen Hash-Tabelle nach, die die für das VTools-Mittel ("VToolsAgent") relevante Liste von Kanälen zurücksenden kann. Das Rücksendeobjekt ist von dem Typ ChannelSequence with BosTransactionChannel.
5. Das VTools-Mittel ("VToolsAgent") ruft getNextBte(this) auf dem zurückgesendeten Kanal auf. Der BOS-Transaktionskanal ("BosTransactionChannel") wird den Namen der nächsten, für unser VTools-Mittel ("VToolsAgent") hinzuzuziehenden BTE mit seiner bestimmten VTools-Systemmitteilung ("VToolsSystemMessage") zurücksenden. Im Allgemeinen ist dies "VToolsBte".
6. Nun kann das VTools-Mittel ("VToolsAgent") das statische Verfahren VToolsBte.getNextMethod(this) aufrufen. Dies wird eine Beschreibung des Verfahrens (einschließlich Syntax) zurücksenden, das das VTools-Mittel ("VToolsAgent") als nächstes aufrufen muss. Man kann nachstehend eine Beschreibung der VToolsBte-Klasse finden.

Diesen Fluss von Ereignissen notwendigerweise für jedes VTools-Mittel ("VToolsAgent"), das eine der vorstehend vorgestellten VTools-Systemmitteilungen ("VToolsSystemMessages") übertragen kann, die entsprechende Folge von Transaktionskanälen, BTEs und BTE-Verfahren zu finden zeigt, was an dem BOS konfiguriert werden muss, um die Kommunikation zwischen den VTools und der letzten VToolsBTE zum Funktionieren zu bringen:

• Eine Mapping-Tabelle an der BOS-Registrierungsberechtigung ("BOS Registration Authority"), um zu ermitteln, dass alle vier VTools- Systemmitteilungen ("VToolsSystemMessages") ein VTools-Mittel ("VToolsAgent") benötigen.
• Eine Mapping-Tabelle an der BOS-Registrierungsberechtigung ("BOS Registration Authority"), um den nächsten Transaktionskanal für ein VTools-Mittel ("VToolsAgent") zu ermitteln in Bezug auf welche VTools-Systemmitteilung ("VToolsSystemMessage") es überträgt und was ihr Zweck ist.
• Eine Tabelle an jedem Transaktionskanal, der die nächste BTE für jedes VTools-Mittel ("VToolsAgent") in einem bestimmten Stadium zurücksendet (d.h. mit einer bestimmten VTools-Systemmitteilung ("VToolsSystemMessage") und der dazugehörigen Historie und der bis jetzt hereingekommenen BTE).
• Ein Verfahren mit einer Fallentscheidung, die bestimmt, was das nächste Verfahren ist, das durch das VTools-Mittel ("VToolsAgent") aufgerufen werden sollte.

Zurück zu der Kommunikationsstruktur: Sobald das VTools-Mittel ("VToolsAgent") diesen Task beendet hat, wobei der Ausführungskanal ("Execution Channel") übergeben wurde, wird es VToolsOutGate.process(this) aufrufen müssen. Das VTools-AUS-Gate ("VToolsOutGate") weiß durch den objReturnAddressee (oder durch Default), dass der zu kontaktierende IComServer exakt der anfängliche VTools-Schnittstellenfall ("VToolsInterface instance") ist.
Da der Ablauf (VTools-Systemmitteilung ("VToolsSystemMessage") am Anfang (aufgerufen durch irgendein VTools GUI-Objekt) zurückkehrt, wenn die Mitteilung dem VTools-EIN-Gate ("VToolsInGate") übergeben worden ist, bestehen zwei Wege um sicherzustellen, dass die Antwort für die Mitteilung an den Absender zurückkommt:

1. Der VTools GUI Thread, der die Mitteilung sendet, wird an der VTools-Schnittstelle ("VToolsInterface") suspendiert und fortgesetzt, wenn die Antwort ankommt. Selbstverständlich bedeutet dies, dass die VTools-Schnittstelle ("VToolsInterface") keine Singleton-Klasse sein darf.
2. Das VTools GUI Objekt, das die Mitteilung sendet, ruft VToolsInterface.process (die VTools-Schnittstelle ("VToolsInterface") auf, die zurückkehrt, nachdem das VTools-EIN-Gate ("VToolsInGate") zurückkehrt. Das VTools-Objekt ("VTools object") muss sich selbst suspendieren und irgendeinen "EIN-Port" ("IN port") abhören, was ein Verfahren sein kann, das automatisch den Thread fortsetzt. Dieses Verfahren wird durch die VTools-Schnittstelle (VToolsInterface") aufgerufen, wenn die Antwort angekommen ist. In diesem Fall muss das sReturnAddressee-Feld der VTools-Systemmitteilung ("VToolsSystemMessage") einen einzigartigen Identifikator für den anfänglichen Sender enthalten.

Die zweite Lösung wird bevorzugt.
VTools-Mittel ("VToolsAgent")
Das Mittel, das VTools-Systemmitteilungen ("VToolsSystemMessages") durch die bzw. den BOS/CDM führt, ist eine spezielle BTE, die von den drei bereits in dem BOS-Beschreibungspapier erwähnten (w³OS-Mittel ("w³OS Agents"), System-Mittel ("System Agents") und BTE-Mittel ("BTE Agents")) getrennt ist. Trotzdem ist es ein völlig konformes BOS-Mittel ("BOSAgent") (siehe 40).
Für unser VTools-Mittel ("VToolsAgent") sind sowohl sOrigin als auch sDescription "VToolsInterface" re. der String, der den Registrierungsnamen in dem (RMI) Namensraum darstellt. Alle anderen Attribute des VTools-Mittels ("VToolsAgent") sind die gleichen wie für irgendein Mittel.
VTools BTE
Die VTools BTE ist eine von den zwei BTEs, die für "visuelle Tasks ("visual tasks")" verantwortlich sind. Unseres Erachtens können wir diese Tasks in zwei wesentliche Gruppen teilen:

• Konfiguration und Administration von Inhalten und Ansichten (im Grunde sind hier die Tabellen Inhaltstabelle ("Content Table"), Inhaltsinformationstabelle ("Content Information Table") und Ansichtentabelle ("View Table") betroffen). Dies ist der Task der VTools BTE.
• Auslesen von Daten aus den Tabellen, um eine bzw. ein Web-Seite oder -Dokument zu erzeugen. Dies muss durch die in dem nächsten Kapitel beschriebene Ansichten-BTE ("View BTE") durchgeführt werden.

Somit kann die VToolsBTE wie in 41 gezeigt aussehen.
VTools starten
Wenn die VTools gestartet werden, wird eine Snr-Beschreibungs-VT-Mitteilung ("SnrDescriptionVTMessage") an die VTools BTE gesendet zum Abrufen aller Seriennummern-(Meta)-Beschreibungen ("Serial Number (meta) descriptions"), d.h. Einträge aus der Inhaltsstammtabelle ("ContentMasterTable"), für mindestens die erste Ebene von Inhaltstypen (d.h. die ersten sieben Stellen der Seriennummer). Wenn sich der User den Inhaltstypbaum weiter nach unten bewegt, werden mehr Snr-Beschreibungs-VT-Mitteilungen ("SnrDescriptionVTMessages") geschossen, um mehr Daten aus der Inhaltsstammtabelle ("ContentMasterTable") zu erhalten.
Die Snr-Beschreibungs-VT-Mitteilung ("SnrDescriptionVTMessage") kann auch mehrere Schlüsselwertpaare anfordern von allen Reihungswerttabellen ("SequenceValueTables"), d.h. die Tabellen, die die Codes von Seriennummerfeldern über Inhaltstyp hinaus beschreiben (Inhaltstypen werden in der Inhaltsstammtabelle ("ContentMasterTable"), einer sehr speziellen Reihungswerttabelle ("SequenceValueTable") gespeichert, siehe das kommende Inhaltsmodelldokument). Letztlich kann eine Snr-Beschreibungs-VT-Mitteilung ("SnrDescriptionVTMessage") ein oder mehrere Reihungswertobjekte ("SequenceValue objects") mit Daten aus mehreren unterschiedlichen Reihungswerttabellen ("SequenceValue tables") aufweisen.
Die Anforderung kann auch aus Reihungswert-Beschreibungsobjekten ("SequenceValueDescription objects") bestehen – jedoch enthalten diese Objekte hierbei keine Werte, sondern nur einen Satz von Schlüsseln oder einen Schlüssel mit Jokern zum Bezeichnen einer Spannweite in der Tabelle. Die Antwort besteht immer aus der gleichen Snr-Beschreibungs-VT-Mitteilung ("SnrDescriptionVTMessage") mit einem oder mehreren Reihungswert-Beschreibungsobjekten ("SequenceValueDescription objects") mit (wiederum) Vektoren von Schlüsseln (Seriennummer-Reihungscodes) und in einem anderen Vektor ihren Werten = Beschreibungen aus der Inhaltsstammtabelle ("ContentMasterTable") oder anderen Reihungswerttabellen ("SequenceValue tables").
42 zeigt Inhaltscode-Mappings ("ContentCodeMappings").
Codes von Seriennummerreihungen können an der VTools-Seite mittels Inhaltscode-Mappings ("ContentCodeMappings") (siehe 42 – Inhaltscode-Mappings ("ContentCodeMappings") angepasst werden. Die Inhaltscode-Mappings ("ContentCodeMappings") können durch VTools gepflegt werden, um Inhaltseriennummerobjekte ("ContentSerialNumber objects") und ihre Attribute zu bearbeiten.
Laden von Inhaltsinformation und Öffnen von Inhalt
Inhaltsbeschreibungen müssen geladen werden, wenn der Administrator auf einen niedrigsten Knoten in dem Inhaltstypbaum klickt, weil ihre Blätter tatsächliche Inhalte bezeichnen.
Während die VTools für alle inneren Knoten des Inhaltstypbaums Beschreibungen der nächstniedrigen Knotenebene laden müssen (Inhaltsuntertypen – sie werden mittels Snr-Beschreibungs-VT-Mitteilungen ("SnrDescriptionVTMessages") angefordert, die Information aus Reihungswerttabellen ("SequenceValueTables") abrufen), müssen in diesem Fall die VTools eine Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") erzeugen mit Inhaltsbeschreibungsobjekten ("ContentDescription objects"), die die Inhalte zum Öffnen beschreiben (die Inhaltseinträge in der CIT, die zu dem Inhaltsuntertyp gehören). Um zu erklären, dass diese Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") irgendwelche Inhalte zu öffnen hat (und sie nicht zu aktualisieren hat oder sie zu suchen hat), wird das iAction-Feld von ihr mit der Ganzzahlkonstanten für das Öffnen von Inhalten eingestellt (z.B. CONTENT_DECRIPTION_OPEN_CONTENT).
Die VTools senden diese Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") an die BOS/VTools BTE, wo eine entsprechende Datenbankabfrage durchgeführt wird. Das Ergebnis sind Inhaltsbeschreibungen ("ContentDescriptions"), die alle notwendige Information aus der CIT und die Beschreibungen der entsprechenden Einträge der CT ("vecRepresentationsList") enthalten. Sie werden an die in der ursprünglichen Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") enthaltenen VTools zurückgesendet. Die VTools können nun alle Blätter des Knotens anzeigen, der in dem Inhaltstypbaum angeklickt wurde (die Blätter werden mit den Inhaltsbeschreibungs-Strings ("ContentDescription strings" angezeigt).
Wenn der Administrator auf ein Blatt klickt, ist es sehr leicht, diesen bestimmten Inhalt zu öffnen: die VTools müssen lediglich die Beschreibungen (Descriptions") von allen Darstellungen dieses Inhalts in der Ansichten-/Darstellungs-Liste ("View/Representation list") in der unteren linken Ecke anzeigen.
Erzeugen von neuem Inhalt
Das Erzeugen von neuem Inhalt macht die VCM-Panes frei und lässt den Administrator alle Einstellungen editieren. An dieser Stelle kann er die Inhaltseinstellungen editieren und Darstellungen hinzufügen/laden oder sie abändern. Zum Schluss werden der Inhalt und seine Darstellungen in der Datenbank gespeichert, wenn der Administrator "Sichern ("Save")" gedrückt hat.
Editieren von Inhalt und seine Sicherung
Siehe "Neuen Inhalt erzeugen ("Creating new content")" ab "Editiereinstellungen ("edit settings")". Der User/Administrator kann die Einstellungen des Inhalts mittels der Inhaltseinzelheitentabelle editieren.
Editieren der Darstellungen-Liste
Der Administrator kann neue Darstellungen laden (wie bestehende Bilder – sie werden auf dem VCM-Pane angezeigt), oder neue Darstellungen erzeugen (wie Felder, Überschriften und so weiter, mit der Toolbox). Jede Darstellung kann auf der rechten Seite (auf dem VCM-Pane) editiert werden und danach der Darstellungen-/Ansichten-Liste dieses Inhalts hinzugefügt werden. Der Administrator kann die Darstellungen-Liste durch Sichern des Inhalts sichern.
Inhalt löschen
Wenn ein Inhalt gelöscht wird, empfängt der Administrator eine Warnmeldung. Wenn er OK sagt, werden der Inhalt und all seine Darstellungen gelöscht.
Inhalt suchen
Das System weist die Funktionalität des Suchens nach einer bzw. einem bestimmten Gruppe oder Cluster von Inhalt auf. Dies ist eine sehr wichtige Funktion des gesamten Systems, da sie Suchaktionen von sehr hoher Granularität ermöglicht. Wir möchten dies zeigen. Später gibt es eine Suchfunktionalität über Webseiten, d.h. der Enduser kann eine Liste von Schlüsselwörtern eingeben und wird sehen, welche Inhalte zu ihnen passen. Diese Suchaktionen sind jedoch vorformatiert, d.h. es gibt bereits einen Button, der genau diese Abfrage abfeuert.
An der VTools-Seite wird eine Suche dargestellt, die viel detaillierter ist. Wir bieten dem Administrator die Möglichkeit einer Suche bis auf die Granularität jedes einzelnen Inhaltsdetails herunter.
Ein Dreistufenablauf ist für den Administrator erkennbar:

1. An dem VCM kann der Administrator aus dem Menü "Suchen ... ("Search ...")" auswählen und ihm wird ein Fenster mit Ankreuzfeldern gezeigt, die anzeigen, nach welchen Inhaltsattributen gesucht werden sollte.
2. Nachdem die Schlüsselattribute ausgewählt worden sind, präsentieren wir dem Administrator ein Fenster mit Dropdown-Boxen mit allen möglichen Werten für die Schlüssel. Um dies durchführen zu können, verfügen die VTools über Listen von 1) allen Inhaltstypen und ihren Beschreibungen, und 2) allen Seriennummer-Substrings/-Reihungen (Codes für Reihungen 15–51, siehe Dokument Seriennummer ("Serial Number")) und ihren Werten (d.h. alle Reihungswerttabellen, siehe Seriennummer ("Serial Numbers"), S. 12). Für Attribute mit Spannweiten bietet das Fenster je 2 Comboboxen, ein "Aus: ("From:")", ein "An: ("To:")^„
3. Wenn der Administrator seine Schlüsselwerte ausgewählt hat, wird die Suche gestartet. VTools formuliert eine Abfrage (die eigentlich eine Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") ist, die an die BOS/VTools BTE gesendet wird). Diese Abfrage bringt Inhaltsbeschreibungen ("ContentDescriptions") für alle Inhalte zurück, die den Suchkriterien entsprechen.

ad 1. Das erste Fenster mit Ankreuzfeldern sollte so konzipiert sein, dass es eine Vorauswahl von Attributen bietet, die später ausgewählt werden können. Es ist sinnvoll, die Masse von Ankreuzfeldern, die möglich sein können, zu gruppieren. Zusätzlich dazu könnte man die Anzahl von Auswahlmöglichkeiten wie folgt reduzieren (Gruppen/Auswahlmöglichkeiten):

a. Allgemeine Inhaltsattribute
a. Inhaltstypen
2. Grundsätzliche Inhaltsattribute
a. Allgemeine Sicherheits-ID
b. Spezielle Sicherheits-ID
c. Datum/Zeit Beginn und Ablauf (Spannweitenattribut)
d. Länderverfügbarkeit
e. Länderausschluss
f. Alterseignung
3. Objektive Inhaltsattribute
a. Ursprungsland
b. Historische(s) Erzeugungs- und Ablauf-Datum/-Zeit (Spannweitenattribut)
c. Allgemeine Applikations-ID
d. Zusätzliche Applikations-IDs
4. Subjektive Inhaltsattribute
a. Bildungsumfang (Spannweitenattribute)
b. Spaßindex
c. Gelassenheitsindex

Da wir nun alle Codes und Beschreibungen von allen Seriennummerattributen kennen bzw. wissen, können wir dem User eine Combobox für jedes Attribut bieten, das alle möglichen Werte enthält. Zum Beispiel listet die Länderverfügbarkeitscode-Box ("Country Availability Code box") alle Länder und alle Kombinationen von Ländern auf, die dem System als Seriennummerattribute bekannt sind.
Für die "Allgemeinen Inhaltsattribute (General Content Attributes")", die alle Haupt- und Unter-Schlüssel umfassen, können am Ende 14 Boxen bestehen, die je nach jedem Vorgänger gefüllt sind. Dies bedeutet, je nachdem, was in der Hauptschlüsselbox ausgewählt wird (z.B. Computerhersteller), wird die zweite Box (Unterschlüssel 1) entsprechend geladen, d.h. mit den Namen aller verfügbaren Computerhersteller. Sobald der User dort z.B. Compaq auswählt, wird die dritte Box mit den Unterkategorien von Compaq auf ebene 1 geladen, was {Produkte, Firma, Internes, ...} sein kann, und so weiter.
Wenn der Administrator alle Einstellungen durchgeführt hat, kann er unten im Fenster "Suchen ("Search")" drücken. Die VTools erzeugen eine Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage"), deren Inhaltsbeschreibungsobjekt ("ContentDescription object") eine Seriennummer enthält, die zu allen ausgewählten Kriterien passt. Wir können die Seriennummer aufbauen, weil wir die Codes für alle Werte, die ausgewählt worden sind, kennen bzw. wissen. Alle ausgewählten Kriterien anzupassen bedeutet, dass alle bereitgestellten Attributwerte eingestellt sind und der Rest ist aufgefüllt mit 0'n. An der VTools BTE wird ein SQL mittels der Inhaltsbeschreibung ("ContentDescription") formuliert. Die CIT wird eine Anzahl von Inhaltsbeschreibungen zurücksenden, d.h. die CITID und die Beschreibung des Inhalts, seine vollständige Seriennummer und möglicherweise auch die Default-Ansicht. Diese werden an die VTools GUIs zurückgegeben, die die Liste von Ergebnissen speichern. Es wäre großartig, wenn diese Liste dem User angezeigt werden könnte, so dass er eines auswählen und OK drücken kann und schließlich dieser Inhalt in das VCM-Fenster geladen wird, so dass er aktualisiert und betrachtet werden kann.
Es besteht ein Aspekt zu dieser Suche: In der vorstehend beschriebenen Form haben wir eine einfache UND-Suche, d.h. wir suchen nach allen Inhalten, die Attribut 1 und Attribut 2 und so weiter aufweisen. Möglicherweise könnten wir einen zusätzlichen ODER-Button haben, der zu dem "ODER"-Modus schaltet. Selbstverständlich sind wir selbst dann nicht in der Lage, komplexe Abfragen zu formulieren (dieses UND jenes UND (NICHT das ODER NICHT WENIGER ALS das ODER GRÖSSER ODER GLEICH ALS das)) ... Ein drittes Fenster ist möglich, das wieder alle ausgewählten Werte auflistet und dem User die Möglichkeit bietet, sie mit UND, ODER, NICHT, GRÖSSER, WENIGER, ... Konstruktionen zu kombinieren. Für jeden UND-Satz von Attributen kann man ein Inhaltsbeschreibungsabfrage-Objekt ("ContentDescription query object") senden, für jeden ODER-Satz benötigt man andere Inhaltsbeschreibungen ("ContentDescriptions"). Für alle NICHT-Attribute benötigt man inverse Codes, somit ist ein anderer Weg, einen Flag in dem Inhaltsseriennummernobjekt ("ContentSerialNumber object") für diese Attribute zu haben. Ähnliche Flags könnten auch für GRÖSSER, WENIGER und so weiter verwendet werden.
Editieren/Aktualisieren von Gruppen von Inhalten
Das Editieren von Gruppen von Inhalten ist eine Art Erweiterung der Veränderung von bestehenden Inhalten. Es wird auch für das Szenario Nr. 2 erforderlich sein. Editieren besteht aus a) einer Suche und b) einer Aktualisierung des Ergebnisses der Suche.
Wenn eine Inhaltsgruppenaktualisierung durchgeführt wird, kann der Administrator "Aktualisiere Inhaltsgruppe ... ("Update Content Group ...")" aus den VCM-/VC-Menüs auswählen und ihm wird zuerst das gleiche Fenster vorgelegt wie für den Suchfall. Er kann auswählen, welcher welchen Kriterien entsprechende Inhalt aktualisiert werden sollte. Das zweite Fenster ist ebenfalls das gleiche: hierbei kann der Administrator auswählen, welche Attribute gültig sein und für das Bündel von Inhalten eingestellt werden sollten, die aktualisiert werden müssen. Es ist ferner möglich, diese beiden Schritte auszulassen, was besagt, dass das folgende Update alle Inhalte betrifft.
An der Stelle wo in dem Suchanwendungsfall die tatsächliche Suche gestartet wird, erscheint hier in dem Update-Fall erneut ein Fenster, das dem ersten des Suchprozesses ähnlich ist. Nun kann der Administrator auswählen, welche Attribute verändert und aktualisiert werden sollten. Nach dem Abhaken dieser Attribute wird dem Administrator ein weiteres Fenster präsentiert, das die Möglichkeit bietet, zusätzlich einen neuen Wert einzugeben. Somit hat man zwei "Seiten" für jedes Attribut, eine für das Anzeigen der zu suchenden Werte ("alte Werte"), die andere für möglichen Ersatz ("neue Werte"). Nur Werte, die in den Reihungswerttabellen ("SequenceValueTables") aufgelistet sind, sind gestattet, d.h. Werte mit Schlüsseln, die dem System bekannt sind.
Wenn man alle Inhalte aktualisieren möchte, die mit irgendeinem Thema, z.B. "Krise am Persischen Golf ("Golfkrise")", zu tun haben, kann man eine neue Sicherheits-ID verwenden.
Im ersten Schritt würde man nach allen Inhalten der Unterkategorie (Inhaltstyp-Unterschlüssel Nr. ?) "Krise am Persischen Golf ("Golfkrise")" "suchen" oder dem Allgemeinen Applikationscode ("General Application Code"), der "Krise am Persischen Golf ("Golfkrise")" bezeichnet.
Auf der Grundlage dieser Auswahl kann man in den Schritten 3 und 4 auswählen, dass die Allgemeine Sicherheits-ID ("General Security ID") von, angenommen, 5 (durchschnittliche Sicherheit) in 9 (maximale Sicherheit) verändert werden sollte.
Dies kann durchgeführt werden durch

1) Senden einer Inhaltsbeschreibungs-VT-Mitteilung ("ContentDescriptionVTMessage") an das BOS mit einem (UND-Kombinationen von Attributen) oder mehreren (ODER-Kombinationen) Inhaltsbeschreibungsobjekten ("ContentDescription objects"), die ein Muster für zu suchende Seriennummern enthalten.
2) Im Inneren der VTools BTE bekommt man die Rücksendung aus der Datenbank: alle Inhalte für das Update. An der VTools BTE werden alle Seriennummerreihungen des vorher zurückgesendeten Suchergebnisses überschrieben (Inhalte für das Update) und die Inhaltsdaten werden an die CIT zurückgeschrieben.
3) Die Inhaltsbeschreibungsobjekte ("ContentDescription objects") für die Rückmitteilung an die VTools sind alle veränderte Inhalte.

Ansichten-BTE ("View BTE")
Die Ansichten-BTE ("View BTE") ist für verantwortlich für das Ermitteln des bzw. der entsprechenden Layouts und Anzeige für jede beliebige Anforderung. Äußerst allgemein gesprochen wird das w³OS eine Anforderung für eine Seite an das BOS senden. Das w³OS ist dafür konzipiert, nachzuschlagen was angefordert ist, Preise und Produktbeschreibungen zurückzusetzen, Eskalations-Mittel ("-Agents") zu veranlassen, mit externen Schnittstellen zu kommunizieren, ..., alles auf der Grundlage einer Seitenanforderung. Letztlich muss an das Seitenerstellungselement ("Page Composer") eine Ergebnisseite gesendet werden, die alle Elemente, die angezeigt werden müssen, auf einer Seiten anordnet.
Was immer in der BOS und den Kanälen ("Channels") stattgefunden hat, bevor das w³OS-Mittel ("w³OSAgent") an der Ansichten-BTE ("View BTE") ankommt, ist irrelevant. Der einzige Task der Ansichten-BTE ("ViewBTE") ist, was immer an sie übergeben wird zu einer für das Seitenerstellungselement ("Page Composer ("PC")") brauchbaren Ausgabe zu verarbeiten.
Wir können die folgenden an das Ansichten-BTE ("ViewBTE") übergebenen allgemeinen Daten unterscheiden:

1. Ansichten-IDs ("View IDs"). Anforderungen mit nichts anderem als einer Ansichten-ID sind Anforderungen für "gefüllte" Ansichten. Ausgehend von einer Ansicht können wir mehrere "fest programmierte", d.h. absolute Verweise auf Seriennummern ermitteln, wie als nächstes beschrieben.
2. Seriennummernverweise ("SerialNumber references"): Entweder eine einfache Seriennummer (wird das System veranlassen, automatisch die Default-Ansicht (DefaultViewID-Feld in der CIT) zu benutzen) oder eine Seriennummer UND eine Ansichten-ID (in diesem Fall nicht die Default-Ansichten-ID sondern die benutzen, die übergeben wird). Wir benötigen immer eine Ansichten-ID, weil ein reines Inhaltsobjekt ("Content object") in keinerlei Weise dargestellt werden kann. Ein Inhalt weist immer eine oder mehrere Darstellungen auf. Diese Darstellungen sind Datensätze/Zeilen der CT. Jede von diesen weist eine ID auf (einzigartig in CT). Zusätzlich weisen alle Einträge der CT ein Feld "CITID" auf, das die ID ihrer Inhalts-Meta-Daten in der CIT abbildet. Zum Schluss kann das w³OS-Mittel ("w³OSAgent") bei seiner Ankunft an der Ansichten-BTE ("View BTE") einen ganzen Satz von Seriennummern oder nur eine Ansichten-ID ("ViewID") aufweisen.

43 zeigt eine Ansichten-BTE. Im Grunde hat die Ansichten-BTE ("View BTE") die folgenden Aufgaben, im Allgemeinen:

• Nachschlagen einer Ansicht durch die Ansichten-ID ("ViewID"), um ihren XML-String zu entnehmen
• Nachschlagen von Seriennummern, um ihre Default-Ansicht oder irgendeine Darstellungsansicht zu erhalten, um letztlich tatsächliche Darstellungsdaten zu erhalten

Letztendlich resultiert jede Aktion der Ansichten-BTE ("View BTE") in dem Erhalt des XML-Strings irgendeiner Ansicht. Im Grunde findet eine Eskalation im Inneren der Ansichten-BTE ("View BTE") statt. Beginnend mit irgendeiner Seriennummer kann die Ansichten-BTE ("View BTE") folgendes ermitteln

• Verweise auf andere Seriennummern, oder
• Verweise auf Ansichten mit Verweisen auf Darstellungen des anfänglichen Inhalts, oder
• Verweise auf Ansichten mit anderen Seriennummern als Verweise

Beginnend mit einer Ansichten-ID ("ViewID") kann es nur Verweise auf Seriennummern geben, jedoch andererseits können sie wiederum Verweise auf andere Ansichten und/oder Seriennummern haben, wie vorstehend beschrieben. Insgesamt haben wir dabei zyklische und rekursive Strukturen.
44 zeigt Beziehungen zwischen Inhalt, Beziehung und Ansichten.
Die Eingangsstellen sind hier, wie bereits erwähnt, entweder eine Seriennummer oder eine Ansichten-ID. Jedenfalls wird ein Baum aus dem bzw. der anfänglichen Inhalt oder Ansicht erzeugt. Die "Suche" endet, wenn wir an eine CT kommen, in der entweder alle Verweise gefunden werden können (d.h. die Ansicht enthält nur Verweise auf in diesem Datensatz gespeicherte Daten) oder wenn irgendein Verweis auf einen grundlegenden Ansichtenfall (z.B. irgendein tatsächliches Bildelement) in der CT hinweist. Man kann sich auch die Verweise, Beziehungen und Schachtelungen von Ansichten als einen Baum vorstellen. Es existiert irgendeine Wurzel, die Knoten sind Ansichten und die Blätter sind tatsächliche Datenelemente. Dieser Baum ist der gleiche, der später zum Zusammenstellen der Seite verwendet wird. Es geht darum, dass auf dem Weg von der Wurzel zu den Blättern auch XML-Substrings bestehen.
In der Zusammenfassung haben wir immer als Ergebnis jeder Anforderung, sei es für irgendeine(n) Inhalt oder Ansicht:

• einen Satz XML-Strings
• einen Satz grundlegender Ansichtenfälle, z.B. Bilddaten, Textdaten, Überschriften-Strings, ...

Wir werden immer auf dem Weg von der Eingangsstelle nach unten XML-Strings aufnehmen. Wenn es Verweise gibt, die innerhalb eines Paars von Tags enthalten sind, werden sie geklärt und werden zu einer anderen Ansicht führen (mit einem anderen XML-String) oder einer anderen Darstellung, die folgendes ist:

• entweder eine Zusammenstellungsansicht, die grundlegende Typen enthält (der Ansichteneintrag für diese grundlegenden Darstellungen müssen nachgeschlagen werden, da wir vereinbart haben, einen vollständigen XML-String bis hinunter zu den grundlegenden Typen zu haben), oder
• einfach einen grundlegenden Typ (für diesen Typ müssen wir den XML-String in der Ansichtentabelle ("ViewTable") nachschlagen.

Letztlich beenden wir immer an irgendeiner CT.
Lassen Sie uns von nun an die Seriennummer oder die Ansichten-ID, die der Ansichten-BTE ("ViewBTE") übergeben wird, eine Direktive ("Directive") nennen. Eine Direktive ("Directive") kann sein eine Seriennummer, eine Seriennummer mit einer Ansichten-ID (bezeichnend nicht die Default-Ansicht, sondern die übergebene zu nehmen), eine CITID der CT oder ein Paar aus CT ID/CITID, oder eine Ansichten-ID ("ViewID"), oder ein Paar aus ViewID/CT ID.
Die Struktur der Ansichten-BTE ("View BTE") ist wie folgt:
Wenn die Ansichten-BTE ("View Bte") eine Direktive empfängt ("followDirective"), beginnt sie, die Eingangsstelle nachzuschlagen. Von da an bewegt sie sich die Verweise der Beziehung drei hinunter. Hier ist der Fluss von Ereignissen:
Die anfängliche Direktive ("Directive") kommt an der Ansichten-BTE ("View BTE") an zusammen mit einem leeren RpPageData-Objekt ("RpPageData object") und der RpSystemmitteilung ("RpSystemMessage"), die das Mittel ("Agent") initialisiert hat.
Dies ist der iterative prozess den die Ansichten-BTE ("ViewBte") durchläuft:

1. Die Direktive ("Directive") analysieren
2. Falls es eine Seriennummer oder eine Inhaltsinformationstabellen-ID ("ContentInformationTable ID (=CITID in CT)") oder ein Paar von Inhaltstabellen-ID/CITID ("ContentTable ID/CITID pair") ist, klassifiziert es letztlich irgendeine Darstellung (Seriennummer wird auch zu einer Darstellung führen).
a. Falls es eine Seriennummer ist, muss die Ansichten-BTE ("View Bte") die Seriennummer nachschlagen und die Sicherheitseinstellungen der Sicherheitscode-Reihung überprüfen, die in der Seriennummer enthalten ist (eine Abfrage durchführen mit "... wo <security_part_of_serial_number> = security_id_value_of_user ...").
b. Falls es ein Eintrag in die CT ist (bezeichnet durch CT ID, möglicherweise in Kombination mit einer CITID), in dem Spezielle-Sicherheits-ID-Feld ("ExtraSecurityIDField") dieses Datensatzes der CT nachschlagen. Die Sicherheitseinstellung des Users (die mit der Sicherheitsstufe der bzw. des Direktive/Datensatzes verglichen werden muss) kann aus der w³OS-Mitteilung ("w³OSMessage") abgerufen werden. Sobald diese Sicherheitsüberprüfungen durchgeführt sind, fortfahren:
a. Falls der Verweis als eine Direktive verwendet werden kann (Sicherheitsfeigabe OK), schlage ihn nach. Falls es eine Seriennummer ohne spezielle Ansichten-ID ("extra ViewID") ist, steuere zu der Zeile dieser Seriennummer in der CIT und verwende die Default-Ansichten-ID ("DefaultViewID"). Falls eine übergeben Ansichten-ID ("ViewID") existiert, benutze sie. Die Ansichten-ID ("ViewID") und die CITID werden zu einem bestimmten Datensatz in der CT führen. Falls einen spezielle Sicherheitseinstellung ("ExtraSecurity setting") existiert, verfahre mit ihr, wie vorstehend beschrieben: vergleiche sie mit den Sicherheitseinstellungen des Users.
i. Falls sie gültig ist, überprüfe die Ansichten-ID ("ViewID") der Darstellung. Verwende diese Ansichten-ID ("ViewID") als eine neue Direktive und fahre mit 3. fort. Nach der Rückkehr von dort, fahre fort.
ii. Falls sie nicht gültig ist, füge die CT ID einer Fehlermeldungsdarstellung in der CT (möglicherweise existieren separate Einträge in der CT, die Fehlermeldungen und Fehlerbilder sind, ...) dem vecPageData-Vektor der RpPageData an und kehre zurück.
b. Falls die Sicherheitseinstellungen anzeigen, dass diese Direktive nicht verwendet werden darf, füge die Fehlermeldung CT ID auch der vecPageData an.
3. Falls es eine Ansichten-ID ("ViewID") ist, schlage die Ansichtendefinition in der Ansichtentabelle nach. Lese den XML-String ab und füge ihn dem vecXmlString-Vektor der RpPageData an. Der Platzhalter ist später an dem Seitenerstellungselement ("Page Composer") notwendig, um tatsächliche Daten an den richtigen Platz in dem XML-Dokument zu stellen. Jede Platzhaltervariable wird durch tatsächliche Daten ersetzt.
a. Falls in dem XML-String Verweise enthalten sind: Für alle Verweise in dem XML-String FÜHRE DURCH:
i. Falls es einen Verweis auf eine Seriennummer gibt, ist die Platzhaltervariable ein Inhaltsplatzhalter. Fahre mit 2. fort. Nach der Rückkehr fahre mit dem nächsten Verweis fort.
ii. Falls es einen Verweis auf eine andere Ansicht innerhalb des XML-Strings gibt, ersetze den Verweis durch einem Ansichtenplatzhalter. Dann fahre mit 3. auf dem Verweis fort. Dann fahre mit dem nächsten Verweis fort.
b. Falls in dem XML-String keine Verweise enthalten sind: Gehe einen Schritt zurück zu dem Ursprung des Verweises, der zu dieser Ansicht geführt hat. Dies muss ein Datensatz in der CT sein. Für alle Tags in dem XML-String dieser Ansicht FÜHRE DURCH in der Reihenfolge der Tags von links nach rechts: Überprüfe ob (in der CT) ein grundlegender Ansichtenfall innerhalb derselben CITID-Gruppe existiert, dessen Typ zu dem Tag passt.
i. Falls ja, füge die CT dem Ende des vecPageData-Vektors des RpPageData-Objekts hinzu. Fahre fort.
ii. Falls nicht ist dies ein Fehler! (Füge die Fehlermeldungs-CT-ID dem Vektor hinzu).

Der Algorithmus beendet, wenn es keine Verweise auf Ansichten oder Seriennummern mehr gibt. Dies wird in Schritt 3.b. sein. Die Ergebnisse dieses Ablaufs sollten wie folgt sein: Schritt für Schritt und die spätere Hierarchie innerhalb der Seite nach unten (dies ist immer eine Baumstruktur) kommt die Ansichten-BTE ("View BTE") letztlich zu den XML-Strings und Datensätzen in der CT mit tatsächlichen Datensätzen hinunter. Am Ende gibt es zwei gefüllte Vektoren:

• VecXmlStrings, die alle XML-Substrings enthalten, die gefunden worden sind, beginnend an der Wurzel (Tiefe erster Ordnung von allen für die Seite erforderlichen XML-Strings).
• VecPageData, die die CT IDs von all diesen Zeilen/Datensätzen enthalten, die tatsächliche Daten enthalten, die in der späteren Seite verwendet werden.

Es ist wichtig, dass die Ordnung von beiden Vektoren richtig und entsprechend ist. Wir haben keine 1:1 Beziehung zwischen den Elementen von Vektor 1 und Vektor 2, wir haben zum Beispiel eine Ansicht mit Verweisen auf drei Seriennummern: Es gibt einen XML-String, aber die drei Seriennummern führen zu drei Darstellungen, d.h. Einträgen in der CT. Folglich bestehen drei Elemente von vecPageData, die zu einem Element von vecXmlStrings gehören.
Außer dem Ermitteln aller XML-Strings und Links aller tatsächlichen Daten, muss die Ansichten-BTE ("View BTE") auch bestimmen, welche XSL-Datei später an dem PC zu verwenden ist. Wir werden je nach Alter, Bildungsniveau, Heimatland, ... mehrere XSL-Dateien für mehrere User-Gruppen haben. Trotzdem passt jede XSL zu jeder XML-Datei, die aus den XML-Strings, die mit den Ansichten gespeichert werden, hergestellt und zusammengestellt werden können. Die Ansichten-BTE ("View BTE") wählt abhängig von dem User-Profil aus, welche XSL-Datei zu verwenden ist. Die Ansichten-BTE ("View BTE") kann darüber hinaus ein zu verwendendes Musterblatt festlegen. Auf jeden Fall schreibt die Ansichten-BTE ("View BTE") mindestens an das iXslID-Feld der RpPageData. Diese zum Unterscheiden von XSL-Dateien für verschiedene User-Gruppen verwendeten IDs werden aus der Ansichten-BTE ("View BTE") und dem PC definiert. Später werden wir diese Information aus der BTE zu dem PC ausbreiten müssen (falls wir eine GUI an der BTE-Seite haben, wo der Administrator neue XSL-Dateien für eine User-Gruppe erzeugen kann) oder in einem Schritt mit der RavenManager-Applikation für den PC.
Sobald die Ansichten-BTE ("ViewBte") mit einer bestimmten Direktive beendet ist, sendet sie die gefüllten RpPageData an des Mittel ("Agent") zurück, der zu der Inhalts-BTE ("ContentBte") weitergehen muss. Diese ? TE wird alle Elemente der vecPageData analysieren und jede CT ID durch die tatsächlichen Daten, die dort gespeichert sind, ersetzen. Der Grund warum die Ansichten-BTE ("ViewBte") tatsächliche Daten nicht abrufen darf ist, dass der Zugriff auf echte Inhaltsdaten irgendeiner speziellen BTE vorbehalten sein muss, die nur diese Funktionalität hat.
45 zeigt die Ansichten-BTE ("ViewBte"), das w³OS-Mittel ("w³OSAgent") und die Direktive ("Directive").
Manager
Eine Managementkonsole ("Management Console") ist für das Starten und Herunterfahren des BOS verantwortlich. Der CDM kann auch durch die Managementkonsole gesteuert und konfiguriert werden, die ohnehin alle administrativen Tasks übernimmt. Insbesondere Installation und Konfiguration (sowie Deinstallation) der Geschäftstransaktionsmaschinen ("Business Transaction Engines (BTE)") werden über den Manager gehandhabt. Irgendwelche auftretenden Fehler werden, sofern möglich, geschluckt, so dass das System unter jeder Bedingung stabil bleibt. Ausnahmemeldungen werden jedoch protokolliert und können später ausgewertet werden.
46 gibt eine schematische Übersicht der Managementkonsole ("Management Console") wieder.
Der Manager ist die zentrale Steuer- bzw. Kontroll-Einheit für den Systemadministrator zum Konfigurieren und Überwachen des gesamten Systems.
Der Manager arbeitet als ein Behälter von Steuer- bzw. Kontrollfeldern für alle Module und Plugins. Er ist das einzige Framework der GUI und fügt diese Funktionalitäten hinzu: Verwaltungszugriff-Steuerung bzw. -Kontrolle, Koordination des Steuer- bzw. Kontroll-Feldes verschiedener Komponenten. Für jede Komponente, die durch die Managementkonsole ("Management Console") konfigurierbar wird, wird eine Java-Schnittstelle ("ManagementServer") zum Ermöglichen von Management konzipiert. Die Komponente verwendet eine spezialisierte Klasse (z.B. WebServerManagementServer) zum Implementieren dieser Schnittstelle.
47 zeigt die Kommunikationsarchitektur ("Communication Architecture") des Managers.
Hier definieren wir lediglich die Schnittstelle 1 in der FIG., die Definition und Implementierung der Schnittstelle 2 bleibt dem einzelnen Komponentenentwickler überlassen.
Szenariobeschreibung
Hier können wir eine Szenariobeschreibung darüber abgeben, wie das Konzept arbeitet.

1. In der Plattform, worin die Komponente residiert, wird der RMI-Registrierungsserver gestartet mit LocateRegistry.createRegistry(1099) Zu Beachten: Hier werden wir die Dienstprogramm-RMI-Registrierung nicht mehr verwenden.
2. Starten des Managementservers ("ManagementServer"), üblicherweise nach der Initialisierung, er sollte sich selbst unter einem fest zugeordneten RMI-Namen (z.B. Webserver ("WebServer")) durch einen Code wie WebServerManagementServer obj = new WebServerManagementServer(); Naming.bind("//localhost/WebServer", obj); registrieren, um dem RavenManager freizugeben, den entfernten Managementserver ("ManagementServer") zu verwenden.
3. Um nun den RavenManager zu betreiben, wird irgendein Code wie mserver = (ManagementServer)Naming.lookup("//hostname/WebServer"); verwendet, um einen Verweis auf den Managementserver abzurufen (z.B. WebServerManagementServer).
4. Der RavenManager ruft das process() Verfahren dieses Servers auf, um einen Manager für diesen Managementserver zu erhalten. manager = (IRavenManager) mserver.process(new Integer(1)); Zu beachten: Hier aus den nachstehenden Gründen kein JPanel mehr zurücksenden. Erstens um diese zu komplexe Rückfrage nach einer dynamischen GUI und interaktiven Antwort bei den Administratoren zu vermeiden. Zweitens um die Funktionen des UI zwischen Management-Tasks zu trennen.
5. Der RavenManager ruft das initialize() Verfahren auf, um ein Steuer- bzw. Kontroll-Feld zu bilden, einen neuen Thread zu starten, um irgendeinen periodischen Task durchzuführen (falls erforderlich). manager.initialize(mserver);
6. Nun kann der RavenManager den Namen, die Beschreibung, Serverstatusinformation und das Steuer- bzw. Kontroll-Feld aus dem Manager erhalten. manager.getControlPanel(); manager.getDescription(); manager.getName();

48 zeigt schematisch die Kommunikationsschnittstellen ("Communication Interfaces")
Im Grunde konstruiert jeder Managementserver ("ManagementServer") einen Manager ("manager"), wenn entfernt aufgerufen, sendet er diesen Manager ("manager") an den Manager ("Manager") zurück. Wenn der Administrator den Status dieser Komponente konfigurieren oder überwachen möchte, sendet der Manager ("manager") ein Steuer- bzw. Kontroll-Feld zurück, durch welches der Administrator auf interaktive Weise diese Komponente konfigurieren und überwachen kann. Der Manager ("Manager") kann fest zugeordnete Server durch Aufrufen irgendwelcher Verfahren dieses Managers ("manager") starten und stoppen.
Namenskonventionen der Managementserver ("ManagementServers") und Manager
Für jede Komponente in dem System wird es zum Zweck des entfernten Managements einen Managementserver ("ManagementServer") und Manager ("Manager") geben. Um die Namensgebung klar und einheitlich zu machen, ist es möglich, folgende Namenskonventionen zu verwenden: für XXXKomponente (z.B. Web-Server) wird unter Verwendung des RMI/CORBA Kommunikatormodells der Managementserver ("ManagementServer") XXXRmiManagementServer/XXXCorbaManagementServer (z.B. WebRmiManagementServer/WebCorbaManagfementServer) sein. Wohingegen der Manager ("Manager") XXXRmiManager/XXXCorbaManager (z.B. WebRmiManager) sein wird.
Die Verschlüsselungsmaschine ("Encryption Engine")
Eine Verschlüsselungsmaschine ("Encryption Engine") ist das Modul, das dem gesamten System Verschlüsselung und Schlüsselmechanismen bereitstellt. Sie ist äußerst flexibel und erweiterbar auf die Weise, dass die verwendeten Algorithmen zu jeder Zeit für leistungsstärkere Implementierungen in der Zukunft ausgewechselt werden können.
Alle Kommunikation zwischen den Systemkomponenten wird vorzugsweise verschlüsselt.
Die Kommunikationsschnittstellen ("Communication Interfaces")
Das System ist ein verteiltes System, das RMI-Kommunikation zwischen allen seinen Komponenten verwendet.
Die Weise auf die es implementiert wird, ist ebenfalls sehr flexible. Die Kommunikationsschnittstellen verwenden Kommunikations-Wrapper, die die zu Grunde liegende Technologie vollständig kapselt. Es ist kein Problem RMI durch CORBA zu jeder Zeit zu ersetzen.

Claims

Verfahren zum Darstellen von Daten, die in einer Datenspeichervorrichtung (2) auf einem Datenserver (3) gespeichert sind, für einen Anwender, wobei der Anwender auf dem Datenserver über ein Netzwerk zugreift, wobei im Prozess zwischen dem Zugriff auf den Server und dem Darstellen der Daten zumindest ein Datenpfad verwendet wird, über den Kontrolldaten, die mit der Auswahl von Daten assoziiert sind, gesendet werden, wobei der zumindest eine Datenpfad unidirektional ist.
Verfahren nach Anspruch 1, gekennzeichnet durch die Schritte: – Herstellen einer Verbindung mit einem Anwender über ein Kommunikationsmodul (1); – Empfangen einer den Anwender identifizierenden Anwender-Identifikation; – Übertragen der Identifikation an ein Eingabemodul (4), das dafür ausgelegt ist, Daten vom Kommunikationsmodul nur zu empfangen, aber nicht Daten an das Kommunikationsmodul zu senden; – Übertragen der Identifikation und/oder Daten, die durch Prozessieren der Identifikation erhalten werden, an ein Datenauswahlmodul (5), wobei das Datenauswahlmodul (5) so ausgelegt ist, dass es Daten von dem Eingabemodul (4) nur empfängt, aber nicht so, dass es Daten zum Eingabemodul (4) sendet, um auf die Datenspeichervorrichtung (2) zuzugreifen und zu bestimmen, welche Daten in der Datenspeichervorrichtung dem Anwender auf Basis der vom Eingabemodul (4) empfangenen Informationen präsentiert werden sollen.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Kommunikationsmodul (1) nach Herstellen der Verbindung eine Auswahlseite an den Anwender überträgt und dadurch, dass beim Schritt des Übertragens der Identifikation an das Eingabemodul (1) zusätzliche Daten übertragen werden, die mit einer Auswahl auf der Auswahlseite assoziiert sind.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das Datenauswahlmodul (5) die zu präsentierenden Daten zusammen mit Daten überträgt, die mit der Anzeigevorbereitung der zu präsentierenden Daten assoziiert ist, an ein Seitenvorbereitungsmodul (6), das dafür ausgelegt ist, Daten nur vom Datenauswahlmodul (5) zu empfangen, aber nicht Daten an das Datenauswahlmodul (5) zu senden, und welches dann die darzustellenden Daten in Form einer Anzeigenseite vorbereitet.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Seitenvorbereitungsmodul (6) die darzustellenden Daten zusammen mit Informationen, die mit ihrer Anzeige assoziiert sind, an das Kommunikationsmodul (1) überträgt, welches dann die vorbereitete Seite an den Anwender überträgt.
Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass während eines Schrittes der Datenauswahl das Datenauswahlmodul (5) die Anwender-Identifikation an einen entfernten zweiten Server überträgt und von dem zweiten entfernten Server mit für den durch die Identifikation identifizierten Anwender auszuwählenden Daten assoziierte Informationen empfängt.
Verfahren gemäß Anspruch 1, gekennzeichnet durch Versehen des Datenservers mit einer 3-Tier-Software-Architektur, bei der ein erster Tier zumindest eine Datenbank umfasst, die zu präsentierende Daten enthält, ein zweiter Tier ein oder mehrere Module zur Implementierung von Applikationslogik zur Verarbeitung von Daten und zum Zugriff auf die Datenbank in dem ersten Tier umfasst und ein dritter Tier ein oder mehrere Module für externe Kommunikation und Verarbeitung von Daten zur Anzeige umfasst.
Verfahren nach Anspruch 7, gekennzeichnet durch Versehen des dritten Tiers mit einer Mehrzahl von Kommunikationsmodulen, wobei jedes Modul so ausgelegt ist, dass es einem entsprechenden Netzwerk einen Kommunikationskanal bereitstellt.
Verfahren gemäß Anspruch 8, dadurch gekennzeichnet, dass die Mehrzahl von Kommunikationsmodulen aktive Module zum Herstellen aktiver Kommunikationskanäle zum Senden von Daten in das jeweilige, mit dem entsprechenden aktiven Modul verbundene Netzwerk und interaktive Module zum Herstellen interaktiver Kommunikationskanäle zum Senden von Daten zu und Empfangen von Daten aus den mit dem jeweiligen interaktiven Modul verbundenen jeweiligen Netzwerk umfasst.
Verfahren nach Anspruch 7, gekennzeichnet durch Versehen des zweiten Tiers mit einer Software-Architektur, welche Softwareelemente zum Verarbeiten von Datentransaktionen von Softwareelementen trennt, die Applikationslogik implementieren.
Verfahren gemäß Anspruch 10, dadurch gekennzeichnet, dass die Softwareelemente zum Prozessieren von Datentransaktionen eine grundlegende Transaktions-Architektur bilden und die Softwareelemente, welche Applikationslogik implementieren, Plugins sind, die dafür ausgelegt sind, in die grundlegende Transaktions-Architektur eingeklinkt zu werden.
Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass Datentransaktionen mittels Agenten durchgeführt werden, auf denen die Applikationslogik implementierenden Softwareelemente Tasks durchführen.
Verfahren nach einem der Ansprüche 7 bis 12, gekennzeichnet durch Versehen des zweiten Tiers mit einem Gattermodul, das so ausgelegt ist, dass alle Nachrichten an den zweiten Tier das Gattermodul passieren müssen.
Verfahren nach einem der Ansprüche 7 bis 13, gekennzeichnet durch Versehen des dritten Tiers mit einem Netzwerk-Interaktionsmodul für interaktive Kommunikation zu einem Kommunikationsnetzwerk, über welches Anwender des Kommunikationsnetzwerkes Anfragen bezüglich Daten senden, wobei das Netzwerk-Interaktionsmodul externe Anfragen vom Kommunikationsnetzwerk empfängt, eine mit der externen Anfrage assoziierte interne Anfrage generiert, die interne Anfrage an den zweiten Tier vor Verarbeitung der internen Anfrage weiterleitet, die externe Anfrage suspendiert, bis eine interne Antwort auf die interne Anfrage empfangen ist und eine externe Antwort auf die externe Anfrage erzeugt, nachdem die interne Antwort erhalten worden ist.
Verfahren nach Anspruch 14, gekennzeichnet durch Versehen des Netzwerk-Interaktionsmodules mit – einem Netzwerkservermodul zum Empfangen der externen Anfragen vom Kommunikationsnetzwerk und Senden der externen Antworten in das Kommunikationsnetzwerk, – ein mit dem Netzwerkservermodul verbundenes Sicherheitsmodul zum Empfangen externer Anfragen aus dem Netzwerkservermodul, wobei das Sicherheitsmodul ein Haltemodul zum Halten suspendierter externer Anfragen umfasst, und – ein Anfragenabwicklermodul, das mit dem Sicherheitsmodul verbunden ist, zum Erzeugen der internen Anfragen auf Basis von externen Anfragen und zum Weiterleiten der internen Anfragen an den zweiten Tier, wobei der Informationsfluss vom Sicherheitsmodul zum Anfragenabwicklermodul und vom Anfragenabwicklermodul zum zweiten Tier unidirektional ist.
Computerprogrammprodukt, das ein Computerprogramm umfasst, ausgelegt für das Durchführen des Verfahrens eines der Ansprüche 1 bis 15, wenn auf einem Computer ausgeführt.
Datenserver (3) zum Präsentieren von Daten, die in einer Datenspeichervorrichtung (2) auf dem Datenserver (3) gespeichert sind, einem Anwender über ein Netzwerk, wobei der Datenserver (3) in solch einer Weise ausgelegt ist, dass im Prozess zwischen Zugreifen auf den Server und Präsentieren der Daten zumindest ein Datenpfad verwendet wird, über welchen mit der Auswahl von Daten assoziierte Kontrolldaten gesendet werden, wobei der zumindest eine Datenpfad unidirektional ist.
Datenserver nach Anspruch 17, gekennzeichnet durch – ein Kommunikationsmodul (1) zum Herstellen einer Verbindung mit einem Anwender, das dafür ausgelegt ist, eine den Anwender identifizierende Anwenderidentifikation zu empfangen; – ein Eingabemodul (4) zum Empfangen der durch das Kommunikationsmodul (1) übertragenen Identifikation, wobei das Eingabemodul (4) dafür ausgelegt ist, Daten vom Kommunikationsmodul (1) nur zu empfangen, aber nicht, Daten an das Kommunikationsmodul (1) zu senden; – ein Datenauswahlmodul (5) zum Empfangen der Identifikation und/oder von durch Prozessieren der Identifikation abgeleiteten Daten, wobei das Datenauswahlmodul (5) so ausgelegt ist, dass es Daten vom Eingabemodul (4) nur empfängt, aber nicht Daten an das Eingabemodul (4) sendet, um auf die Datenspeichervorrichtung (2) zuzugreifen und zu bestimmen, welche Daten in der Datenspeichervorrichtung (2) dem Anwender, basierend auf der vom Eingabemodul (4) empfangenen Information, zu präsentieren sind.
Datenserver nach Anspruch 18, dadurch gekennzeichnet, dass das Kommunikationsmodul (1) so ausgelegt ist, dass es eine Auswahlseite an den Anwender überträgt, nachdem die Verbindung hergestellt ist, und so ausgelegt ist, dass beim Schritt des Übertragens der Identifikation an das Eingabemodul (4) zusätzliche Daten übertragen werden, die mit einer durch den Anwender auf der Auswahlseite gemachten Auswahl assoziiert sind.
Datenserver nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass das Datenauswahlmodul (5) dafür ausgelegt ist, die zu präsentierenden Daten zusammen mit den mit der Anzeigevorbereitung der zu präsentierenden Daten assoziierten Daten an ein Seitenvorbereitungsmodul (6) zu übertragen, das so ausgelegt ist, dass es Daten von dem Datenauswahlmodul (5) nur empfangen kann, aber nicht Daten an das Datenauswahlmodul (5) senden kann, und das dafür ausgelegt ist, dann die zu präsentierenden Daten in Form einer Anzeigenseite vorzubereiten.
Datenserver nach Anspruch 20, dadurch gekennzeichnet, dass das Seitenvorbereitungsmodul (6) dafür ausgelegt ist, die zu präsentierenden Daten zusammen mit den mit ihrer Anzeige assoziierten Informationen an das Kommunikationsmodul (1) zu übertragen, das dafür ausgelegt ist, dann die vorbereitete Seite an den Anwender zu übertragen.
Datenserver nach einem der Ansprüche 18 bis 21, dadurch gekennzeichnet, dass das Datenauswahlmodul (5) dafür ausgelegt ist, die Anwender-Identifikation an einen entfernten zweiten Server zu übertragen und vom zweiten entfernten Server Informationen zu empfangen, mit Daten assoziiert sind, die für den durch die Identifikation identifizierten Anwender auszuwählen sind.
Datenserver nach Anspruch 17, gekennzeichnet dadurch, dass er eine 3-Tier-Software-Architektur aufweist, bei der ein erster Tier zumindest eine Datenbank umfasst, die zu präsentierende Daten enthält, ein zweiter Tier ein oder mehrere Module zur Implementierung von Applikationslogik zur Verarbeitung von Daten und zum Zugriff auf die Datenbank in dem ersten Tier umfasst und ein dritter Tier ein oder mehrere Module für externe Kommunikation und Verarbeitung von Daten zur Anzeige umfasst.
Datenserver nach Anspruch 23, dadurch gekennzeichnet, dass der dritte Tier eine Mehrzahl von Kommunikationsmodulen umfasst, wobei jedes Modul so ausgelegt ist, dass es einem entsprechenden Netzwerk einen Kommunikationskanal bereitstellt.
Datenserver gemäß Anspruch 24, dadurch gekennzeichnet, dass die Mehrzahl von Kommunikationsmodulen aktive Module zum Herstellen aktiver Kommunikationskanäle zum Senden von Daten in das jeweilige, mit dem entsprechenden aktiven Modul verbundene Netzwerk und interaktive Module zum Herstellen interaktiver Kommunikationskanäle zum Senden von Daten zu und Empfangen von Daten aus den mit dem jeweiligen interaktiven Modul verbundenen jeweiligen Netzwerk umfasst.
Datenserver nach Anspruch 23, dadurch gekennzeichnet, dass der zweite Tier eine Software-Architektur umfasst, welche Softwareelemente zum Verarbeiten von Datentransaktionen von Softwareelementen trennt, die Applikationslogik implementieren.
Datenserver gemäß Anspruch 26, dadurch gekennzeichnet, dass die Softwareelemente zum Prozessieren von Datentransaktionen eine grundlegende Transaktions-Architektur bilden und die Softwareelemente, welche Applikationslogik implementieren, Plugins sind, die dafür ausgelegt sind, in die grundlegende Transaktions-Architektur eingeklinkt zu werden.
Datenserver nach Anspruch 26 oder 27, gekennzeichnet durch Agenten, die so ausgelegt sind, dass Datentransaktionen mittels der Agenten durchgeführt werden, auf denen die Applikationslogik implementierenden Softwareelemente Tasks durchführen.
Datenserver nach einem der Ansprüche 23 bis 28, dadurch gekennzeichnet, dass der zweite Tier ein Gattermodul umfasst, das so ausgelegt ist, dass alle Nachrichten an den zweiten Tier das Gattermodul passieren müssen.
Datenserver nach einem der Ansprüche 23 bis 29, dadurch gekennzeichnet, dass der dritte Tier ein Netzwerk-Interaktionsmodul für interaktive Kommunikation zu einem Kommunikationsnetzwerk umfasst, über welches Anwender des Kommunikationsnetzwerkes Anfragen bezüglich Daten senden, wobei das Netzwerk-Interaktionsmodul so ausgelegt ist, dass es externe Anfragen vom Kommunikationsnetzwerk empfängt, eine mit der externen Anfrage assoziierte interne Anfrage generiert, die interne Anfrage an den zweiten Tier vor Verarbeitung der internen Anfrage weiterleitet, die externe Anfrage suspendiert, bis eine interne Antwort auf die interne Anfrage empfangen ist und eine externe Antwort auf die externe Anfrage erzeugt, nachdem die interne Antwort erhalten worden ist.
Datenserver nach Anspruch 30, dadurch gekennzeichnet, dass das Netzwerk-Interaktionsmodul umfasst – einem Netzwerkservermodul zum Empfangen der externen Anfragen vom Kommunikationsnetzwerk und Senden der externen Antworten in das Kommunikationsnetzwerk, – ein mit dem Netzwerkservermodul verbundenes Sicherheitsmodul zum Empfanger externer Anfragen aus dem Netzwerkservermodul, wobei das Sicherheitsmodul ein Haltemodul zum Halter suspendierter externer Anfragen umfasst, und – ein Anfragenabwicklermodul, das mit dem Sicherheitsmodul verbunden ist, zum Erzeugen der internen Anfragen auf Basis von externen Anfragen und zum Weiterleiten der internen Anfragen an den zweiten Tier, wobei der Informationsfluss vom Sicherheitsmodul zum Anfragenabwicklermodul und vom Anfragenabwicklermodul zum zweiten Tier unidirektional ist.