-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft allgemein Computer und Computernetzwerke
und im Besonderen eine Netzwerkvorrichtung zum Validieren von Dokumenten.
-
Stand der
Technik
-
Im
Zuge des zunehmenden Erfolgs von Computernetzwerken oder Computernetzen
in Bezug auf deren Funktion als Speicher- und Datenweiterleitungssysteme,
wie etwa dem Internet, erfahren derartige Systeme bzw. Netzwerke
ein enormes Wachstum im Zuge der explosionsartigen Zunahme des Verkehrs
bei transaktionsbasierten, unternehmenskritischen Anwendungen, seitens
der Eigentümer
bzw. Betreiber von Webseiten und auf Unternehmensservern. Anwendungsserver
und andere Verarbeitungsknoten können
mit der Verantwortlichkeit zur Ausführung einer Vielzahl von Funktionen überfordert
bzw. überladet
sein, darunter die Erzeugung von Verbindungen zu entfernten Servern
oder Client-Systemen, das Verschlüsseln und Entschlüsseln übertragener
Informationen bzw. Daten, das Verarbeiten der empfangenen Daten
oder Transaktionsdaten (z.B. Aufträge, Webseitenaufrufe, etc.),
das Formatieren von Daten bzw. Informationen für Anzeige- oder Verarbeitungszwecke,
etc. Zur Behandlung des hohen Datenaufkommens und der zunehmend
komplexen Anzahl von Aufgaben, die für Anwendungsserver erforderlich
sind, handelte es sich bei der traditionellen Lösung darum, dass mehr Server
und mehr Netzwerkbandbreite zugekauft wurden, wobei dies jedoch mit übermäßigen Kosten
verbunden sein kann.
-
Die
Sprache XML bzw. eXtensible Markup Language V. 1.0 wurde vom World
Wide Web Consortium (W3C) am 10. Februar 1998 angenommen. XML stellt
eine strukturierte Syntax für
den Datenaustausch bereit. XML ist eine Dokumentenauszeichnungssprache
wie auch die Sprache HTML (HTML als englische Abkürzung von
Hyper-Text Markup Language). In XML werden die tatsächlichen
Daten von der Präsentation
bzw. Darstellung der Daten getrennt, im Gegensatz zu HTML, welche
diese beiden Elemente kombiniert bzw. verknüpft. Die meisten Dokumentenauszeichnungssprachen,
wie etwa HTML, sind feststehende Dokumentenauszeichnungssprachen.
Das heißt,
die feststehenden Dokumentenauszeichnungssprachen (einschließlich HTML)
weisen eine Reihe fester Tags bzw. Identifizierungskennzeichnen
zur Erstellung eines Dokuments auf. Im Gegensatz dazu definiert
XML keine feste Reihe bzw. Gruppe von Tags, vielmehr definiert XML
lediglich eine Syntax bzw. ein strukturiertes Format, durch das Benutzer
ihre eigene Gruppe von Tags definieren bzw. festlegen können. Zurzeit
gibt es eine Reihe von XML-basierten Sprachen (z.B. WML, CXML, CBL), die
unter Verwendung der XML-Syntax ihre eigene Gruppe von XML-Tags
definieren.
-
Der
XML-Standard erfordert es lediglich, dass ein empfangenes Dokument
geprüft
werden muss, um zu bestätigen,
dass es die grundlegende Syntax und das Format von XML erfüllt (d.h.
es wird bestimmt, ob das Dokument „ordnungsgemäß gestaltet" ist). Darüber hinaus
ermöglicht
der XML-Standard auch die Validierung eines Dokuments, wobei es
sich um eine strengere Prüfung
handelt, die dazu dient, zu bestimmen, ob die Struktur oder die
Grammatik des XML-Dokuments der Struktur entspricht, die gemäß der jeweiligen
XML-basierten Sprache erforderlich ist. Die XML-Spezifikation setzt
dies zwar nicht voraus, allerdings weisen zahlreiche Anwendungsserver
oder andere Verarbeitungsknoten, die XML-Dokumente verarbeiten,
einen validierenden XML-Prozessor auf (oder einen validierenden
XML-Parser), um
die XML-Anwendungsdaten hinsichtlich ihrer Validität im Vergleich
zu einer Validierungsvorlage zu überprüfen. Die
Validierung ist wichtig, da sie sicherstellen kann, dass die Anwendungsdaten
(z.B. Transaktionsdaten) in dem XML-Dokument in dem richtigen Format
bereitgestellt werden und durch den Anwendungsserver richtig interpretiert
werden.
-
Die
aktuelle XML-Verarbeitung umfasst für gewöhnlich den Empfang eines XML-Dokuments durch
einen XML-Anwendungsserver von einer Quellanwendung sowie die folgende
vollständige
Verarbeitung des Dokuments und die optionale Bereitstellung einer
Antwort an die Quellanwendung. Ein XML-Dokument wird für gewöhnlich durch
drei Schritte verarbeitet:
- 1) Es wird geprüft, ob das
Dokument „ordnungsgemäß gestaltet" ist.
- 2) Eine optionale Validierungsprüfung wird vorgenommen, um zu
gewährleisten,
dass die Syntax und Grammatik einer bestimmten Validierungsvorlage
entsprechen.
- 3) Das traditionelle Parsing (Syntaxanalyse) des Inhalts auf
dessen Bedeutung und Anwendung auf die relevante Domäne (z.B.
Verarbeitung der Anwendungsdaten oder der Transaktionsdaten).
-
Der
zweite Schritt der Validierung kann sowohl auf Seiten eines Prozessors
als auch hinsichtlich der abgelaufenen Zeit sehr rechenintensiv
sein. Zur Validierung eines Dokuments muss eine XML-Anwendung entweder
eine Validierungsvorlage irgendwo aus dem Netzwerk abrufen oder
sie muss die Validierungsvorlage aus dem XML-Dokument selbst parsen
bzw. analysieren (oder identifizieren) (wenn die Validierungsvorlage
in dem XML-Dokument
bereitgestellt ist). Wenn der Anwendungsserver die Validierungsvorlage
aufweist, muss er die Anwendungsdaten parsen und prüfen, ob
diese mit den Regeln für
die Validierungsvorlage übereinstimmen.
Als Folge dessen kann die Last bzw. Aufgabe der Ausführung der
Dokumentenvalidierung die Anzahl der Dokumente oder Transaktionen,
die durch den Anwendungsserver oder den Verarbeitungsknoten verarbeitet
werden müssen,
deutlich reduzieren.
-
Zusammenfassung
der Erfindung
-
Vorgesehen
ist gemäß einem
ersten Aspekt der vorliegenden Erfindung eine Netzwerkvorrichtung
gemäß dem gegenständlichen
Anspruch 1.
-
Vorgesehen
ist gemäß einem
zweiten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen
Anspruch 7.
-
Bevorzugte
Merkmale der vorliegenden Erfindung sind in den Unteransprüchen definiert.
-
Kurze Beschreibung
der Zeichnungen
-
Die
vorstehenden Ausführungen
und ein besseres Verständnis
der vorliegenden Erfindung werden aus der folgenden genauen Beschreibung exemplarischer
Ausführungsbeispiele
sowie aus den Ansprüchen
deutlich, wenn diese in Verbindung mit den beigefügten Zeichnungen
gelesen werden, die alle Bestandteil der vorliegenden Erfindung
sind. Die vorstehenden und nachstehenden geschriebenen sowie veranschaulichten
Offenbarungen fokussieren sich zwar auf die Offenbarung exemplarischer
Ausführungsbeispiele
der Erfindung, jedoch wird hiermit festgestellt, dass dies nur den
Zwecken der Veranschaulichung und der beispielhaften Darstellung dient,
und wobei die Erfindung diesbezüglich
nicht beschränkt
ist. Der Umfang der vorliegenden Erfindung ist lediglich durch die
Definition der anhängigen Ansprüche beschränkt.
-
Zum
Beispiel werden einige Techniken der Erfindung in Bezug auf eine
XML-Nachricht und die XML-Verarbeitung veranschaulicht und beschrieben. Der
Einsatz einer XML-Nachricht
und die XML-Verarbeitung werden nur zur Erläuterung und Beschreibung der
Techniken der Erfindung angewendet. Die Erfindung ist nicht auf
XML oder ähnliche
Sprachen beschränkt,
vielmehr ist sie auf Nachrichten anwendbar, die in einer Vielzahl
strukturierter Formate oder Sprachen bereitgestellt werden.
-
Es
folgt eine kurze Beschreibung der Zeichnungen. In den Zeichnungen
zeigen:
-
1 ein
Blockdiagramm eines Netzwerksystems gemäß einem Ausführungsbeispiel;
-
2 ein
Flussdiagramm der Funktionsweise eines Validierungsbeschleunigers
gemäß einem Ausführungsbeispiel;
-
3 ein
Flussdiagramm einer beispielhaften Funktionsweise eines Validierungsbeschleunigers
gemäß einem
Ausführungsbeispiel;
-
4 ein
Flussdiagramm einer Funktionsweise eines Validierungsbeschleunigers
gemäß eines
weiteren Ausführungsbeispiels;
und
-
5 ein
Blockdiagramm einer Netzwerkvorrichtung gemäß einem weiteren Ausführungsbeispiel.
-
Genaue Beschreibung
der Erfindung
-
Gemäß einem
Ausführungsbeispiel
ist eine Netzwerkvorrichtung zwischen einem Netzwerk und einer Mehrzahl
von Verarbeitungsknoten (z.B. Webservern, Anwendungsservern, XML-Servern, Routern,
Switches oder anderen Vorrichtungen) bereitgestellt. Die Netzwerkvorrichtung
weist einen Validierungsbeschleuniger zur Vorabvalidierung von Dokumenten
auf.
-
Gemäß einem
Ausführungsbeispiel
wird eine Nachricht empfangen, die Validierungsanweisungen und Anwendungsdaten
aufweist. Eine Validierungsvorlage kann entweder inline (z.B. in
dem Dokument als Teil der Validierungsanweisungen) oder als eine externe
Validierungsvorlage bereitgestellt werden. Wenn das Validierungsdokument
extern ist, kann die Vorlage von einem Netzwerk abgerufen werden (oder
von einem entfernten Server bzw. einem Remote Server), und es kann
lokal in einem Cache-Speicher
für eine
zukünftige
Verwendung gespeichert werden, um die Validierungsgeschwindigkeit
zu verbessern. Das Dokument wird danach auf der Basis der Vorlage
validiert, und die Validierungsanweisungen werden danach aus dem
Dokument entfernt. Das vorab validierte Dokument wird danach an
einen Verarbeitungsknoten oder einen Anwendungsserver gesendet.
-
Da
die Validierungsanweisungen (einschließlich der internen Validierungvorlage
und/oder eines Zeigers auf eine externe Vorlage) aus dem Dokument
entfernt worden sind, validiert der Anwendungsserver das Dokument
nicht und nimmt an, dass das Dokument gültig ist. Auf diese Weise kann
die aufwändige Aufgabe
der Dokumentenvalidierung von dem Anwendungsserver auf eine Netzwerkvorrichtung
abgeladen werden, wie etwa einen Validierungsbeschleuniger.
-
Gemäß einem
weiteren Ausführungsbeispiel kann
die Netzwerkvorrichtung weitere Funktionen oder Blöcke aufweisen,
wie etwa einen Sicherheitsbeschleuniger, einen auf Inhalten basierten
Nachrichtendirektor und/oder einen Lastverteiler.
-
In
Bezug auf die Abbildungen, in denen die gleichen Elemente mit den
gleichen Bezugsziffern bezeichnet sind, zeigt die Abbildung aus 1 ein Blockdiagramm
eines Netzwerksystems gemäß einem
Ausführungsbeispiel.
Gemäß der Abbildung
aus 1 kann eine Vielzahl von Clients über ein
Netzwerk bzw. Netz, wie etwa das Internet 130, mit einem Datenzentrum 135 gekoppelt
bzw. verbunden werden. Die Clients können zum Beispiel einen Server aufweisen 110,
der ein Anwendungsprogramm 112 aufweist, einen Computer 120 (wie
etwa einen Personalcomputer oder einen Laptop), der einen Webbrowser 122 aufweisen
kann, und eine kabellose Vorrichtung 132, wie etwa einen
Personal Digital Assistant (PDA) oder ein schnurloses Telefon oder
ein Mobiltelefon. Die kabellose Vorrichtung 132 kann über entsprechende Übermittlungsabschnitte 134 bzw. 136 mit
dem Internet 130 oder mit einem Datenzentrum 135 gekoppelt
werden. Die Übermittlungsabschnitte 134 und 136 können jeweils
einen oder mehrere kabellose Überrmittlungsabschnitte
(z.B. einen Mobilfunk- oder einen anderen Übermittlungsabschnitt) oder
einen kabelgebundenen Übermittlungsabschnitt
aufweisen. Jeder der Clients, darunter der Server 110,
der Computer 120 und die Vorrichtung 132, kann
Nachrichten über
das Internet 130 senden und empfangen und eine Vielzahl
verschiedener Protokolle oder Transportmethoden verwenden.
-
Das
Datenzentrum 135 wird zum Senden, Empfangen, Verarbeiten
und Ausführen
einer umfassenden Vielzahl von Nachrichten und Anforderungen bereitgestellt,
wie etwa von geschäftlichen
Transaktionen, Aufträgen
bzw. Bestellungen, Aktienkursen oder Aktienhandelstransaktionen
und anderen Informationen bzw. Daten. Das Datenzentrum 135 weist mehrere
Verarbeitungsknoten (z.B. Server) auf, darunter der Server 150,
der Server 160 und der Server 170 zur Behandlung
der verschiedenen Aufträge bzw.
Bestellungen, geschäftlichen
Transaktionen und sonstigen Anforderungen.
-
Gemäß einem
Ausführungsbeispiel
tauschen die Clients und die Objekte des Datenzentrums 135 Nachrichten
aus, welche durch ein Anwendungsprogramm (wie etwa einen XMP-Prozessor)
zu verarbeitende Anwendungsdaten aufweisen. Die Anwendungsdaten
in der Nachricht können
geschäftliche
Transaktionsdaten aufweisen, die eine oder mehrere Transaktionen
beschreiben oder betreffen. Gemäß einem
Ausführungsbeispiel
können
die in einer Nachricht bereitgestellten Anwendungsdaten in vorteilhafter
Weise als XML-Daten (z.B. als ein XML-Dokument) bereitgestellt werden
oder in einem anderen strukturierten Format oder einer anderen Dokumentenauszeichnungssprache,
um den Datenaustausch zu erleichtern. Die XML-Daten in den Nachrichten
entsprechen vorzugsweise dem gemäß dem XML-Standard erforderlichen
Format oder der entsprechenden Syntax. Ein Dokument, das Tag-Formate
verwendet (z.B. Anfangs-Tags, End-Tags) und eine sonstige Syntax
(z.B. zur Auszeichnung von Daten), die dem XML-Standard entspricht,
wird als ein „ordnungsgemäß gestaltetes" XML-Dokument bezeichnet.
-
In
erneutem Bezug auf die Clients aus der Abbildung aus 1.
kann es sich bei dem Anwendungsprogramm 112 um ein geschäftliches
Programm oder ein Programm zur Bestandsverwaltung, zur Verwaltung
von Aufträgen
oder anderen geschäftlichen
Transaktionen handeln. Zum Beispiel kann das Anwendungsprogramm
automatisch und elektronisch detektieren, dass der Bestand unter
einen Schwellenwert gefallen ist, und es kann automatisch eine Bestellung
an den Server eines Lieferanten bzw. Zulieferers an dem Datenzentrum 135 erzeugen und übermitteln,
um eine Lieferung weiterer Waren bzw. Teile anzufordern. Der Server 110 kann
zum Beispiel eine Business-to-Business
(B2B) Transaktion einleiten, indem eine elektronische Bestellung
an den entfernten Server des Zulieferers bzw. des Lieferanten an
dem Datenzentrum 135 gesendet wird.
-
Als
ein weiteres Beispiel kann der Webbrowser 122 Webseiten,
geschäftliche
Daten oder andere Daten von einem entfernten Server (der an dem
Datenzentrum 135 angeordnet ist) anfordern. Der Webbrowser 122 kann
auch Bestellungen, geschäftliche Transaktionen
oder andere geschäftliche
Daten an einen entfernten Server senden oder schicken, der an dem
Datenzentrum 135 angeordnet sein kann. Die kabellose Vorrichtung 132 kann
Informationen oder Daten in Bezug auf Bestellungen, geschäftliche Transaktionen,
Webseiten, Aktienkurse, Spielstände bzw.
Spielergebnisse und dergleichen von einem oder mehreren entfernten
Servern (wie etwa von an dem Datenzentrum 135 angeordneten
Servern) empfangen.
-
Gemäß einem
Ausführungsbeispiel
kommunizieren der Server 110, der Computer 120 und
die kabellose Vorrichtung 132 jeweils mit einem oder mehreren
entfernten Servern (z.B. den Servern 150, 160 und 170)
oder tauschen mit diesen Daten aus, indem XML-Daten (d.h. Anwendungsdaten oder Daten zu
geschäftlichen
Transaktionen, die gemäß dem XML-Standard
codiert oder formatiert sind oder gemäß einer oder mehreren XML-basierten
Sprachen) gesendet und empfangen werden.
-
Gemäß einem
vorteilhaften Ausführungsbeispiel
weist das Datenzentrum 135 ferner einen Validierungsbeschleuniger 142 auf,
um empfangene Nachrichten vorab zu validieren, bevor die Nachrichten
zu einem der Anwendungsserver oder Verarbeitungsknoten gesendet
werden. Gemäß einem
Ausführungsbeispiel
wird der Validierungsbeschleuniger 142 als eine Netzwerkvorrichtung
bereitgestellt. Mit anderen Worten kann der Validierungsbeschleuniger 142 gemäß einem
Ausführungsbeispiel
zwischen ein Netzwerk 130 und eine Mehrzahl von Verarbeitungsknoten
oder Anwendungsserver (z.B. die Server 150, 160 und 170)
gekoppelt werden. Die Bereitstellung des Validierungsbeschleunigers 142 als
eine Netzwerkvorrichtung (d.h. getrennt von den Anwendungsservern)
ermöglicht
das Abladen der rechenintensiven Aufgabe der Dokumentenvalidierung
von den Anwendungsservern auf den Validierungsbeschleuniger 142.
Alternativ kann eine Mehrzahl von Validierungsbeschleunigern 142 bereitgestellt
werden, wobei ein Validierungsbeschleuniger 142 für einen
oder mehrere Anwendungsserver oder sonstige Verarbeitungsknoten
bereitgestellt wird.
-
Wie
dies bereits vorstehend im Text beschrieben worden ist muss ein
XML-Dokument geprüft
werden, um sicherzustellen, dass es die Grundsyntax und das Format
von XML erfüllt
(d.h. um zu bestimmen, ob das Dokument „ordnungsgemäß gestaltet" ist). Darüber hinaus
ermöglicht
es der XML-Standard optional, dass ein Dokument validiert wird,
wobei es sich bei einer sorgfältigeren
bzw. strengeren Prüfung
handelt, um zu bestimmen, ob die Struktur oder die Grammatik des
XML-Dokuments der
Struktur oder Grammatik entspricht, die durch die jeweilige XML-basierte
Sprache erfordert wird. XML ermöglicht
eine Validierung eines Dokuments im Vergleich zu einer Validierungsvorlage. Eine
Validierungsvorlage definiert die Grammatik und Struktur des XML-Dokuments
(einschließlich
erforderlicher Elemente oder Tags, etc.).
-
Es
gibt zahlreiche Arten von Validierungsvorlagen, wie zum Beispiel
die Dokument-Typ-Definition (DTD) in XML oder ein Schema. Diese
beiden Validierungsvorlagen werden als Beispiele verwendet, um einige
Merkmale gemäß Ausführungsbeispielen zu
erläutern.
Viele andersartige Validierungsvorlagen sind ebenfalls möglich. Ein
Schema ist einer DTD ähnlich,
da es die Grammatik und die Struktur definiert, der das Dokument
entsprechen muss, um gültig zu
sein. Ein Schema kann jedoch spezifischer sein als eine DTD, da
es auch die Möglichkeit
aufweist, Datentypen zu definieren (z.B. Zeichen, Ziffern, ganze
Zahlen, Gleitkomma oder individuell gestaltete Datentypen). Im Gegensatz
zu einer DTD (gemäß den aktuellen
Standards) kann zudem für
eine ordnungsgemäße Gestaltung
ein Schema erforderlich sein. Somit können sowohl die Anwendungsdaten
als auch das Schema geparst und hinsichtlich der Basissyntax (oder
der ordnungsgemäßen Gestaltung)
geprüft
werden. Somit wird für
zumindest einige Anwendungen erwartet, dass Schemas zukünftig häufiger eingesetzt
werden als DTDs.
-
Wie
dies bereits vorstehend im Text ausgeführt ist, ist gemäß dem XML-Standard
eine Validierung eines empfangenen Dokuments im Vergleich zu einer
Validierungsvorlage optional. Wenn ein Dokument im Vergleich zu
einer bestimmten Validierungsvorlage validiert werden soll, so weist
das XML-Dokument am Anfang des Dokuments Validierungsanweisungen
(oder einen Validierungscode) auf. Ein Beispiel für Validierungsanweisungen
kann eine Dokumententyperklärung
sein, wie dies in XML allgemein bekannt ist. Ein weiteres Beispiel
ist ein Schema (oder ein Verweis auf ein externes Schema). Gemäß dem aktuellen
XML stellen die Validierungsanweisungen (z.B. die Dokumententyperklärung oder
ein Schema, etc.) einen optionalen Bereich des Dokuments dar, der
die Struktur, die Elementtypen, Attribute, etc. der Validierungsvorlage
erklärt.
Damit ein Dokument gültig
ist, müssen
die Struktur und die Grammatik der Anwendungsdaten in dem Dokument der
durch die Validierungsvorlage definierten Struktur und Grammatik
entsprechen (wenn das Dokument Validierungsanweisungen enthält). Die
Validierungsvorlage kann innerhalb (oder in dem) des Dokuments und/oder
außerhalb
des Dokuments bereitgestellt werden.
-
Die
Abbildung aus 2 zeigt ein Diagramm einer beispielhaften
Nachricht gemäß einem
Ausführungsbeispiel.
Die in der Abbildung aus 2 dargestellte beispielhafte
Nachricht weist ein XML-Dokument 210 auf. Das XML-Dokument 210 weist XML-Anwendungsdaten 220 auf
(z.B. etwa geschäftliche
Transaktionsdaten) sowie Validierungsanweisungen 215.
-
Die
Anwendungsdaten 220 stellen die Anwendungsdaten dar, die
durch einen Anwendungsserver verarbeitet werden. Die Anwendungsdaten 220 können zum
Beispiel geschäftliche
Transaktionsdaten aufweist, wie etwa eine Aufstellung der zu kaufenden
Artikel, der Preise, der Mengen oder anderer spezifischer Details
einer Transaktion oder eine Anforderung von Informationen (z.B.
eine Anforderung eines Aktienkurses oder von Transaktionsdetails).
-
Gemäß einem
Ausführungsbeispiel
zeigt das Vorhandensein einer oder mehrerer Validierungsanweisungen 215,
dass das Dokument validiert werden kann (oder sollte), bevor die
Anwendungsdaten 220 auf der Basis einer Validierungsvorlage
verarbeitet werden können,
die in den Validierungsanweisungen 215 bereitgestellt oder
durch diese identifiziert wird. Gemäß einem Ausführungsbeispiel
kann das Vorhandensein von Validierungsanweisungen anders ausgedrückt anzeigen,
dass die Anwendungsdaten vorab an einer Netzwerkvorrichtung (wie
etwa dem Validierungsbeschleuniger 142) validiert werden
sollten, bevor die Daten an einen Anwendungsserver zur weiteren
Verarbeitung weitergeleitet werden. Um dem Anwendungsserver anzuzeigen,
dass das Dokument (oder die Anwendungsdaten) validiert worden ist
bzw. sind, können
die Validierungsanweisungen aus dem Dokument entfernt werden und/oder
es kann eine Anzeige (wie etwa ein Hinweis oder eine Anweisung in
den Daten oder ein in die Nachricht eingefügtes Feld) bereitgestellt werden,
um anzuzeigen, dass die Anwendungsdaten oder die Nachricht validiert
worden sind bzw. ist (d.h. vorab validiert). Gemäß dem aktuellen XML ist die
Dokumentenvalidierung optional (z.B. durch den Anwendungsserver), selbst
wenn Validierungsanweisungen 215 vorhanden sind. Es ist
jedoch möglich,
dass in Zukunft eine Validierung (in XML oder in anderen Sprachen)
erforderlich ist.
-
Wenn
das Dokument für
eine Dokumentenvalidierung (d.h. um eine Dokumentenvalidierung zu ermöglichen)
einer Validierungsvorlage zugeordnet werden soll (Dokument-Typ-Definition, Schema, etc.),
so weist das Dokument für
gewöhnlich
eine oder mehrere Validierungsanweisungen 215 auf. Die Validierungsanweisungen 215 stellen
die Validierungsvorlage (oder die Dokument-Typ-Definition) bereit
oder sie identifizieren sie, welche wiederum die Dokumentenstruktur
und die Grammatik definiert (z.B. Elemente, Attribute), welchen
die Anwendungsdaten 220 des Dokuments 210 entsprechen
müssen. Die
Validierungsvorlage kann eine interne Komponente und/oder eine externe
Komponente aufweisen.
-
In
dem dargestellten Beispiel (z.B. für XML) werden die Validierungsanweisungen 216 (oder
eine Validierungsvorlage) als eine Dokumententyperklärung bereitgestellt.
Die Validierungsanweisungen 215 beginnen mit der DOCTYPE-Aussage
zum Dokumententyp „<DOCTYP schweinezuverkaufen...", die anzeigt, das
eine Validierungsvorlage gegeben ist, die in dem Dokument bereitgestellt
werden kann (d.h. als interne Komponente 219) oder außerhalb des
Dokuments (d.h. als eine externe Komponente, die als „schweine.dtd" identifiziert ist).
In dem vorliegenden Beispiel stellen die Validierungsanweisungen 215 somit
eine interne Komponente 219 einer Validierungsvorlage bereit
sowie einen externen Komponentenbezeichner 217, der eine
externe Komponente identifiziert.
-
Die
interne Komponente 219 und die externe Komponente (nicht
abgebildet) bilden gemeinsam die Validierungsvorlage für dieses
Dokument (d.h. zum Validieren der Anwendungsdaten 220 für das Dokument 210).
Wenn eine Validierung vorgenommen wird, bewirkt gemäß einem
Ausführungsbeispiel das
Vorhandensein der Aussage DOCTYPE (oder andere Validierungsanweisungen)
für gewöhnlich, dass
eine Anwendung oder ein Anwendungsserver die Anwendungsdaten 220 in
der Nachricht im Vergleich zu der Validierungsvorlage validiert.
-
Die
interne Komponente 219 der Validierungsvorlage definiert,
das ein gültiges
schweinezuverkaufen-Dokument die folgenden Elemente aufweisen muss:
Typ, durchschnittliche Gewichtung, Menge und Preis/hog, etc. Dabei
handelt es sich lediglich um ein Beispiel.
-
In
dem vorliegenden Beispiel identifiziert der Bezeichner „schweine.dtd" ein externes Objekt
oder eine Datei; die eine externe Komponente der Validierungsvorlage
darstellt. Die externe Komponente kann sich an einem entfernten
Server oder einer anderen Position auf der Basis des externen Komponentenbezeichners 217 befinden.
Die externe Komponente der Validierungsvorlage (identifiziert als „schweine.dtd") kann zusätzliche
Anforderungen bzw. Voraussetzungen hinsichtlich der Struktur oder Grammatik
der Anwendungsdaten 220 des Dokuments 210 aufweisen.
Der externe Komponentenbezeichner 217 kann als die vollständige Adresse
bereitgestellt werden oder als relative Adresse oder Zeiger (z.B.
im Verhältnis
zu der Adresse oder der Position der Quelle oder des Ursprungsknotens
der Nachricht). Zum Beispiel kann der in den Validierungsanweisungen 215 aufgeführte Bezeichner „schweine.dtd" tatsächlich auf
die „schweine.dtd" externe Komponente 217 verweisen,
die (zum Beispiel) wie folgt angeordnet sein kann: oasis.xml.org/landwirtschaft/tiere/schweine.dtd.
Wie dies bereits vorstehend im Text beschrieben worden ist, zählen zu
Beispielen für
Validierungsvorlagen eine Dokument-Typ-Definition (z.B. für XML), ein Schema, etc.
-
Die
Abbildung aus 3 zeigt ein Flussdiagramm einer
beispielweisen Funktionsweise eines Validierungsbeschleunigers gemäß einem
Ausführungsbeispiel.
In dem Block 310 empfängt
der Validierungsbeschleuniger 142 eine Nachricht. Die Nachricht
kann über
jeden Weg/Transport oder jedes Protokoll erfolgen, wie etwa das
Transmission Control Protocol (TCP), das File Transfer Protocol
(FTP), das Simple Mail Transfer Protocol (SMTP), das Wireless Application
Protocol (WAP, das zum Senden und Empfangen von Daten bzw. Informationen über kabellose
Vorrichtungen verwendet werden kann), das Hypertext Transfer Protocol
(HTTP), etc. Die algemeinen Lehren und die Funktionsweise gemäß der Erfindung
sind von keinem speziellen Transport oder Protokoll abhängig, sondern
vielmehr transportunabhängig.
-
In
dem Block 315 wird durch den Validierungsbeschleuniger 142 eine
Validierungsvorlage erhalten, um das Dokument oder die Nachricht
zu validieren (z.B. zum Validieren der Anwendungsdaten 220 in
dem Dokument 210). Dies kann zum Beispiel zuerst das Bestimmen
umfassen, ob Validierungsanweisungen in dem Dokument oder der Nachricht
enthalten sind. Wenn Validierungsanweisungen enthalten sind, bestimmt
der Validierungsbeschleuniger 142, ob die Validierungsvorlage
für das
Dokument als eine interne Komponente und/oder eine externe Komponente
bereitgestellt wird, und zwar auf der Basis der Syntax einer oder
mehrerer Aussagen in den Validierungsanweisungen 215.
-
Wenn
die Validierungsvorlage in dem Dokument bereitgestellt wird (d.h.
als eine interne Komponente), so wird die Validierungsvorlage von
dem Fest des Dokuments geparst oder getrennt. Wenn die Validierungsanweisungen 215 einen
externen Komponentenbezeichner 217 bereitstellen, so ruft
der Validierungsbeschleuniger 142 die externe Komponente ab
bzw. erhält
diese (z.B. von einem entfernten Server oder Knoten).
-
In
dem Block 320 aus 3 validiert
der Validierungsbeschleuniger 142 zumindest einen Teil
der Nachricht (z.B. werden die Anwendungsdaten 220 validiert),
indem die Struktur und die Grammatik der Anwendungsdaten 220 mit
der Struktur und der Grammatik verglichen werden, die durch die
Validierungsvorlage definiert sind oder von dieser vorausgesetzt
werden.
-
Wenn
das Dokument oder die Nachricht in dem Block 325 gültig sind,
so entfernt der Validierungsbeschleuniger 142 (vorzugsweise
alle) die Validierungsanweisungen, einschließlich etwaiger Aussagen, die
bewirken können,
dass das Dokument validiert wird (z.B. eine DOCTYPE Aussage), etwaiger interner
Komponenten der Validierungsvorlage und etwaiger Referenzen bzw.
Verweise oder Bezeichner in Bezug auf externe Komponenten der Validierungsvorlage.
-
In
dem Block 330 wird das validierte Dokument (mit entfernten
Validierungsanweisungen) zur Verarbeitung zu einem Anwendungsserver
oder einem anderen Verarbeitungsknoten gesendet.
-
Durch
Validierung des Dokuments und folgendes Entfernen der Validierungsanweisungen
(einschließlich
der Validierungsvorlage oder Bezeichner auf diese) prüft jedes
Anwendungsprogramm oder jeder Anwendungsserver, das bzw. der das
Dokument empfängt,
nur, ob das Dokument „ordnungsgemäß gestaltet" (auf Englisch: „well formed") ist (oder die grundlegende
Syntax von XML erfüllt).
Aufgrund des Fehlens der Validierungsanweisungen kann der Anwendungsserver
das Dokument nicht validieren, und er nimmt an, dass das Dokument
oder die Anwendungsdaten gültig
ist bzw. sind. Auf diese Weise kann die Aufgabe der Durchführung der
Dokumentenvalidierung von dem Anwendungsserver auf den Validierungsbeschleuniger 142 verlagert
werden.
-
Die
Abbildung aus 4 zeigt ein Flussdiagramm, das
die Funktionsweise eines Validierungsbeschleunigers gemäß einem
weiteren Ausführungsbeispiel
veranschaulicht. Eine Nachricht, wie etwa ein XML-Dokument 402,
wird empfangen. In der Raute 404 prüft der Validierungsbeschleuniger,
ob Validierungsanweisungen in dem Dokument vorhanden sind. Wenn
dies nicht der Fall ist, wird das Dokument aus dem Validierungsbeschleuniger 142 unverändert ausgegeben,
da keine Validierung vorgenommen werden kann, Block 424.
-
Wenn
Validierungsanweisungen in dem Dokument 402 enthalten sind,
bestimmt der Validierungsbeschleuniger 142 als nächstes,
ob sich die Validierungsvorlage in (oder inline) dem Dokument befindet,
Raute 406. Wenn dies der Fall ist, so wird das Dokument
auf der Basis der internen Validierungsvorlage in dem Block 414 validiert.
-
Wenn
sich die Validierungsvorlage nicht in (oder inline) dem Dokument
befindet (was anzeigt, dass die Vorlage als eine externe Komponente
vorhanden sein sollte), so bestimmt der Validierungsbeschleuniger 142 danach,
ob die Validierungsvorlage (z.B. eine externe Komponente) in dem
Cache gespeichert ist, Raute 408. Der Validierungsbeschleuniger 142 weist
einen Hochgeschwindigkeitsspeicher oder einen lokalen Vorlagen-Cache-Speicher 420 auf,
in dem eine oder mehrere Validierungsvorlagen (wie zum Beispiel
die Datei „schweine.dtd") gespeichert werden
und später
abgerufen werden kann. Wenn die Validierungsvorlage in dem Cache 420 vorhanden
ist, so wird die Validierungsvorlage in dem Block 418 abgerufen
und in dem Block 414 zur Validierung des Dokuments verwendet.
-
Wenn
die Validierungsvorlage nicht in dem Vorlagen-Cache-Speicher 420 enthalten
ist, ruft der Validierungsbeschleuniger 142 die Validierungsvorlage
aus dem Netzwerk ab (z.B. von einem entfernten Server), Blöcke 410 und 405.
Die abgerufene Validierungsvorlage wird danach in dem Block 412 zu
dem Vorlagen-Cache-Speicher 420 hinzugefügt (oder
darin gespeichert). Das Dokument wird danach in dem Block 414 validiert.
-
Nachdem
das Dokument (oder die Nachricht) in dem Block 414 validiert
worden ist, werden die Validierungsanweisungen (einschließlich etwaiger
interner Validierungsvorlagen- oder externer Validierungsvorlagenbezeichner)
aus dem Dokument gelöscht
bzw. entfernt, Block 422. Der Validierungsbeschleuniger 142 gibt
danach das vorab validierte Dokument oder die vorab validierte Nachricht
an einen der Anwendungsserver oder Verarbeitungsknoten (z.B. einen
der Server an dem Datenzentrum 135) zur Verarbeitung aus.
-
Alternativ
(oder zusätzlich
zum Entfernen der Validierungsanweisungen) kann eine Anzeige der Nachricht
hinzugefügt
werden, die dem Anwendungsserver anzeigt, dass die Anwendungsdaten oder
die Nachricht bereits validiert worden sind bzw. ist (d.n. per Vorab-Validierung).
Diese Vorab-Validierungsanzeige
kann zum Beispiel als ein Feld in der Nachricht bereitgestellt werden,
als eine Anweisung oder ein Hinweis in den Anwendungsdaten selbst oder
unter Verwendung einer anderen Technik. In der XML-Spezifikation
gibt es neben Element-Tags und Daten zum Beispiel ein Element, das
als Verarbeitungsanweisungs-Tag bekannt ist, das ein „Escape Hatch" bereitstellt, das
es ermöglicht,
dass für
eine Anwendung spezifische Informationen bzw. Daten in ein XML-Dokument eingebettet
werden können.
Verarbeitungsanweisungen gelten nicht als Bestandteil des Zeichendateninhalts
eines XML-Dokuments, vielmehr werden sie immer durch den Parser
an die XML-Anwendung weitergeleitet. Das Format lautet <?...?> für das Verarbeitungsanweisungs-Tag.
Gemäß einem
Ausführungsbeispiel
kann somit nach der Entfernung der Validierungsanweisungen (oder
der DTD oder des Schemas oder des Verweises darauf) der folgende
Hinweis oder das Anweisungs-Tag nahe dem Anfang des Dokuments (oder
an anderer Stelle) hinzugefügt
werden: <? validiert
durch Intel? >.
-
Durch
Vorab-Validierung des Dokuments und folgendes Entfernen der Validierungsanweisungen
aus dem Dokument (und/oder Hinzufügen einer Anzeige für die Vorab-Validierung
des Dokuments oder der Nachricht) wird der aufwändige Schritt der Validierung
aus dem Anwendungsserver auf eine Netzwerkvorrichtung, eine Netzwerkeinheit
oder ein anderes System abgeladen (das zum Beispiel als der Validierungsbeschleuniger 142 bezeichnet
werden kann).
-
Darüber hinaus
ist ein lokaler Cache 420 vorgesehen, um eine dynamische
Cache-Speicherung der zuletzt verwendeten (oder üblichsten) Anordnung von Validierungsvorlagen
vorzunehmen. Somit weist jedes Dokument, das eine Validierung erfordert,
für gewöhnlich eine
interne Validierungsvorlage (oder in dem Dokument) auf oder weist
einen Verweis oder Zeiger (z.B. einen Universal Resource Identifier
oder URL) auf, um eine externe Vorlage zu identifizieren. Der lokale
Cache wird abgerufen oder angefragt, um zu bestimmen, ob die erforderliche
Vorlage lokal gespeichert wird. Wenn dies nicht der Fall ist, wird
die Vorlage aus dem Netzwerk abgerufen und danach zur späteren Verwendung
lokale im Cache gespeichert. Dies ermöglicht es dem Validierungsbeschleuniger 142,
die Zeit oder Latenz für
die Validierung eines Dokuments signifikant zu reduzieren, da eine Vorlage
nur einmal von dem Netzwerk abgerufen werden muss. Danach wird die
Vorlage intern oder inline bereitgestellt oder kann aus dem lokalen
Cache abgerufen werden.
-
Gemäß einem
Ausführungsbeispiel
kann der Cache mit einer festen Größe als Nutzungs-basierter Stapel
bzw. Stack implementiert werden, so dass Validierungsvorlagen, auf
die häufiger
zugegriffen wird, automatisch weniger häufig verwendete Vorlagen aus
dem Stapel schieben, wenn dieser überläuft. Gemäß einem Ausführungsbeispiel
kann ein LRU-Algorithmus
(für die
letzte Verwendung) eingesetzt werden, um die zuletzt verwendeten
Validierungsvorlagen in dem lokalen Cache zu halten und um die weniger
häufig
verwendeten Vorlagen zu entsorgen (oder in einen anderen Speicher
zu verschieben, wie etwa einen RAM-Speicher oder ein Festplattenlaufwerk).
Auf diese Weise kann die Zeit für
den Abruf oder das Erhalten einer externen Komponente der Validierungsvorlage
(oder einer externen Validierungsvorlage) erheblich reduziert werden.
-
In
erneutem Bezug auf die Abbildung aus 4 wird das
Dokument in dem Block 414 validiert. Wenn das Dokument
gültig
ist wird das vorab validierte Dokument (gemeinsam mit der Anzeige
der Vorab-Validierung) an einen Anwendungsserver weitergeleitet.
Wenn das Dokument hingegen ungültig ist
(d.h. es stimmt nicht mit der Struktur und Grammatik überein,
welche die Validierungsvorlage voraussetzt), so gibt es verschiedene
Möglichkeiten.
Das ungültige
Dokument kann an einen Anwendungsserver weitergeleitet werden (ohne
Löschen
der Validierungsanweisung und ohne Hinzufügen einer Anzeige der Vorab-Validierung).
Alternativ kann die ungültige Nachricht
blockiert oder nicht an einen Server weitergeleitet werden. Ob blockiert
oder weitergeleitet kann der Validierungsbeschleuniger 142 eine
Nachricht an den ursprünglichen
Knoten (oder Sender) senden, dass die Nachricht oder das Dokument
ungültig
ist.
-
Wie
dies bereits vorstehend im Text beschrieben worden ist, kann eine
Anzeige für
die Vorab-Validierung einem Dokument oder einer Nachricht hinzugefügt werden,
nachdem die Nachricht oder die Daten validiert worden ist bzw. sind.
Diese Anzeige für
die Vorab-Validierung kann eine implizite Form fehlender (oder entfernter)
Validierungsanweisungen darstellen (d.h. wenn das Fehlen der Validierungsanweisungen
anzeigt, dass das Dokument gültig
ist oder validiert worden ist). Alternativ kann die Anzeige für eine Vorab-Validierung
in Form einer ausdrücklichen
Aussage oder Anzeige vorgesehen sein (z.B. einer Aussage, einer
Anweisung oder eines Hinweises, die bzw. der der Nachricht oder
dem Dokument hinzugefügt
wird), die anzeigt, dass die Nachricht oder die Anwendungsdaten
validiert ist bzw. sind.
-
Der
Validierungsbeschleuniger 142 wurde vorstehend beschrieben,
dass er die Validierung unter Verwendung einer Validierungsvorlage
vornimmt, wobei der Validierungsbeschleuniger 142 in einem anderen
Ausführungsbeispiel
lediglich das Dokument parst und bestimmt, ob die Anwendungsdaten in
dem Dokument ordnungsgemäß gestaltet
sind (d.h. die grundlegenden Voraussetzungen hinsichtlich der Syntax
und des Formats für
die Sprache erfüllen).
Eine Anzeige für
eine Vorab-Validierung kann danach hinzugefügt werden, um dem Anwendungsserver
anzuzeigen, dass die Nachricht oder das Dokument ordnungsgemäß gestaltet
ist (z.B. die erforderliche Syntax erfüllt).
-
Die
Abbildung aus 5 zeigt ein Blockdiagramm, das
eine Netzwerkvorrichtung gemäß einem weiteren
Ausführungsbeispiel
veranschaulicht. Gemäß einem
Ausführungsbeispiel
kann die Netzwerkvorrichtung 505 einen oder mehrere der
in der Abbildung aus 5 abgebildeten Blöcke aufweisen.
Zum Beispiel kann zusätzlich
zu dem Validierungsbeschleuniger 142 eine Netzwerkvorrichtung 505 einen Sicherheitsbeschleuniger 515,
einen Inhalts-basierten Nachrichtendirektor 545 und/oder
einen Lastverteiler 550 aufweisen. Alternativ können alle
vier Komponenten in einer Netzwerkvorrichtung 505 bereitgestellt
werden oder jede beliebige Teilkombination.
-
Der
Sicherheitsbeschleuniger 515 ist zur Verschlüsselung
abgehender Nachrichten und/oder zum Entschlüsseln eingehender Nachrichten
verwendet werden, die von dem Netzwerk 130 empfangen werden.
Gemäß einem
Ausführungsbeispiel handelt
es sich bei den Sicherheitsbeschleuniger 515 um einen Secure
Sockets Layer (SSL) Beschleuniger, der von der Intel Corporation
erhältlich
ist. Der Sicherheitsbeschleuniger 515 ermöglicht das
Abladen von Aufgaben in Bezug auf die Sicherheit von den Anwendungsservern
an den Sicherheitsbeschleuniger 515.
-
Der
Inhalts-basierte Nachrichtendirektor 545 (z.B. ein XML-Direktor) wird bereitgestellt,
um empfangene Nachrichten an einen der Verarbeitungsknoten oder
Anwendungsserver zu leiten bzw. zu richten, und zwar auf der Basis
des Inhalts der Anwendungsdaten in der Nachricht, einschließlich geschäftlicher Transaktionsdaten.
Die Anwendungsdaten (einschließlich
geschäftlicher
Transaktionsdaten) können
in vorteilhafter Weise als eine XML-basierte Sprache bereitgestellt
werden.
-
Der
Lastverteiler 550 wird bereitgestellt, um den Verkehr oder
die Nachrichten unter einem oder mehreren Servern oder Verarbeitungsknoten
innerhalb des Datenzentrums 135 zu verteilen, und zwar auf
der Basis von einem oder mehreren Lastverteilungsalgorithmen, wie
etwa einem Round Robin- oder einem anderen Algorithmus.
-
Wenn
der Lastverteiler 550 und der Nachrichtendirektor 545 gemäß einem
Ausführungsbeispiel
gemeinsam verwendet werden, kann der Nachrichtendirektor 545 eine
Umschaltentscheidung auf der Basis des Inhalts der Anwendungsdaten
(einschließlich
geschäftlicher
Transaktionsdaten) treffen. Der Lastverteiler 550 kann
danach die Nachricht auf einen Server oder Knoten umschalten, und
zwar auf der Basis (teilweise) der Umschaltentscheidung. Alternativ
kann der Nachrichtendirektor 545 eine Umschaltentscheidung
treffen und danach lediglich die Nachricht an einen bestimmten Server
oder Knoten leiten bzw. weiterleiten.
-
Hierin
werden verschiedene Ausführungsbeispiele
der vorliegenden Erfindung speziell veranschaulicht und/oder beschrieben.
Hiermit wird jedoch festgestellt, dass Modifikationen und Abänderungen der
vorliegenden Erfindung durch die vorstehenden Lehren abgedeckt sind
und den Definitionen der anhängigen
Ansprüche
entsprechen, ohne dabei von dem beabsichtigten Umfang der Erfindung
abzuweichen.