PatentDe  


Dokumentenidentifikation DE60127247T2 23.08.2007
EP-Veröffentlichungsnummer 0001279115
Titel NETZWERKEINRICHTUNG ZUR DOKUMENTENGÜLTIGKEITSERKLÄRUNG
Anmelder Intel Corp., Santa Clara, Calif., US
Erfinder MARLATT, David, San Diego, CA 92114, US;
ABJANIC, John, San Diego, CA 92129, US
Vertreter Hauck Patent- und Rechtsanwälte, 80339 München
DE-Aktenzeichen 60127247
Vertragsstaaten AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LI, LU, MC, NL, PT, SE, TR
Sprache des Dokument EN
EP-Anmeldetag 03.04.2001
EP-Aktenzeichen 019231166
WO-Anmeldetag 03.04.2001
PCT-Aktenzeichen PCT/US01/10917
WO-Veröffentlichungsnummer 2001084358
WO-Veröffentlichungsdatum 08.11.2001
EP-Offenlegungsdatum 29.01.2003
EP date of grant 14.03.2007
Veröffentlichungstag im Patentblatt 23.08.2007
IPC-Hauptklasse G06F 17/22(2006.01)A, F, I, 20051017, B, H, EP

Beschreibung[de]
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 210entsprechen 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.


Anspruch[de]
Netzwerkvorrichtung, die zwischen ein Netzwerk und eine Mehrzahl von Verarbeitungsknoten oder Anwendungsserver gekoppelt ist, wobei die Netzwerkvorrichtung einen Validierungsbeschleuniger (142) umfasst:

a. zum Validieren mindestens eines Teils einer Nachricht;

b. um Validierungsanweisungen aus der Nachricht zu entfernen, bevor die Nachricht an einen Anwendungsserver (150-170) oder einen anderen Verarbeitungsknoten übermittelt wird; und

c. um in der Nachricht eine Anzeige bereitzustellen, dass mindestens ein Teil der Nachricht validiert worden ist, wobei das Fehlen von Validierungsanweisungen in der Nachricht die Anzeige bereitstellt, dass die Nachricht bereits validiert worden ist oder nicht validiert werden muss.
Netzwerkvorrichtung nach Anspruch 1, wobei der Validierungsbeschleuniger einen XML-Validierungsbeschleuniger zum Validieren von XML-Nachrichten umfasst. Netzwerkvorrichtung nach Anspruch 1, wobei der Validierungsbeschleuniger ferner einen lokalen Cache zum Speichern von Validierungsvorlagen umfasst. Netzwerkvorrichtung nach einem der vorstehenden Ansprüche, wobei das Netzwerk folgendes aufweist:

(i) einen Sicherheitsbeschleuniger;

(ii) einen auf Inhalten basierten Nachrichtendirektor, der mit dem Sicherheitsbeschleuniger oder dem Validierungsbeschleuniger gekoppelt ist, wobei der auf Inhalten basierte Nachrichtendirektor eine Umschaltungs- oder Routingentscheidung hinsichtlich einer empfangenen Nachricht auf der Basis der in der empfangenen Nachricht enthaltenen Transaktionsinformationen trifft;

und

(iii) einen Lastverteiler, der mit dem auf Inhalten basierten Nachrichtendirektor gekoppelt ist, um die Nachricht an einen einer Mehrzahl von Verarbeitungsknoten oder Anwendungsservern auf der Basis der Umschaltungsentscheidung zu leiten oder umzuschalten.
Netzwerkvorrichtung nach Anspruch 4, wobei die Transaktionsinformationen in XML bereitgestellte Geschäftstransaktionsinformationen umfassen, und wobei der auf Inhalten basierte Nachrichtendirektor einen XML-Direktor umfasst, um eine Routing- oder Umschaltungsentscheidung zum Leiten einer empfangenen Nachricht auf der Basis des. Inhalts der XML-Daten zu treffen. Netzwerkvorrichtung nach Anspruch 4, wobei der Sicherheitsbeschleuniger einen SSL-Beschleuniger umfasst. Verfahren zum Empfangen einer Nachricht mit Validierungsanweisungen an einer Netzwerkvorrichtung, die zwischen ein Netzwerk und eine Mehrzahl von Verarbeitungsknoten oder Anwendungsserver gekoppelt ist, wobei das Verfahren folgendes umfasst:

a) das Validieren mindestens eines Teils der Nachricht;

b) das Entfernen der Validierungsanweisungen aus der Nachricht, bevor die Nachricht zu einem Anwendungsserver (150-170) oder einem Verarbeitungsknoten gesendet wird;

und

c) das Bereitstellen einer Anzeige in der Nachricht, dass zumindest ein Teil der Nachricht bereits validiert worden ist, wobei das Fehlen von Validierungsanweisungen anzeigt, dass die Nachricht bereits validiert worden ist oder nicht validiert werden muss.
Verfahren nach Anspruch 7, wobei das Bereitstellen das Hinzufügen einer Anzeige zu der Nachricht umfasst, die anzeigt, dass die Nachricht bereits validiert worden ist oder nicht validiert werden muss. Verfahren nach Anspruch 7, wobei das Verfahren ferner folgendes umfasst:

das Erhalten einer Validierungsvorlage für die Nachricht auf der Basis der Validierungsanweisungen; und

das Validieren mindestens eines Teils der Anwendungsdaten auf der Basis der Validierungsvorlage.
Verfahren nach Anspruch 9, wobei das Erhalten einer Validierungsvorlage das Analysieren einer internen Validierungsvorlage aus den Validierungsnachrichten in der Nachricht aufweist. Verfahren nach Anspruch 9, wobei das Erhalten einer Validierungsvorlage das Erhalten einer externen Validierungsvorlage von einem Netzwerk auf der Basis eines externen Bezeichners umfasst. Verfahren nach Anspruch, implementiert als ein Computerprogramm. Verfahren nach einem der vorstehenden Ansprüche, wobei die Nachricht eine XML-Nachricht umfasst.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com