-
Die vorliegende Erfindung bezieht
sich auf ein entferntes und sicheres Steuern einer Netzwerkvorrichtung
unter Verwendung einer Anwendungsschnittstellentechnologie auf einer
höheren
Abstraktionsebene als eine bytebetriebene Schnittstelle, die verwendet
wird, um die Vorrichtung fernzusteuern, wodurch eine sichere entfernte
befehlsbetriebene Benutzerschnittstelle zum Steuern der Vorrichtung
bereitgestellt wird. Insbesondere bezieht sich die vorliegende Erfindung
auf eine Verwendung einer Markup-Sprache, um eine Anwendungsschnittstelle
zum Steuern von Netzwerkvorrichtungen, beispielsweise Netzwerktest-/-überwachungsvorrichtungen
zu definieren, um eine sichere entfernte befehlsbetriebene Benutzerschnittstelle
zu liefern.
-
In der Regel verwenden Netzwerkbedienpersonen
Netzwerktest/-überwachungsvorrichtungen
(Testvorrichtungen), um eine Datenkommunikation (einen Datenverkehr)
eines zu testenden Netzwerks zu testen/überwachen. Die Testvorrichtungen
können
lokal über
eine lokale befehlsbetriebene Schnittstelle und/oder eine graphische
Benutzerschnittstelle mit einer Dateneingabe von einer Tastatur
und/oder einer Anzeige gesteuert werden. Die Netzwerkbedienpersonen
können
die Testvorrichtungen außerdem
fernsteuern, indem sie eine durch einen Verkäufer (Hersteller) der Testvorrichtungen
bereitgestellte Anwendungsprogrammierungsschnittstelle (API – application
programming Interface) verwenden. Insbesondere verwenden die Netzwerkbedienpersonen
(d. h. Kunden der Testvorrichtungen) die API, um Testsoftwareanwendungen
bezüglich
des Netzwerkverkehrs zu entwickeln/erstellen, indem sie über die
API Testvorrichtungsbefehle austauschen, die die Testvorrichtungen
fernsteuern, um verschiedenarti ges Testen/Überwachen/Messen durchzuführen. Jedoch
eignen sich die typischen API-Technologien nicht für ein Steuern
von Test- und Meßgeräten, da
die Netzwerkbedienperson in der Regel die Testgeräte über ein
zu testendes Netzwerk, beispielsweise das Internet, weit verstreut,
was eine Entwicklung und Unterhaltung einer zunehmend komplexen
Testsoftware erfordert. Ferner sind die Testvorrichtungen in der
Regel unterschiedlich, beispielsweise aufgrund verschiedener Testvorrichtungsverkäufer, was
die Komplexität
der Testsoftware erhöht.
Ferner ist eine API-Versionsgebung
durch den Testvorrichtungsverkäufer
schwierig, wodurch Testvorrichtungsaktualisierungen durch den Verkäufer vereitelt
werden. Aufgrund einer derartigen erhöhten Komplexität ist eine
Fehlersuche bei Softwareanwendungen auf der Basis der API nicht
leicht.
-
Eine geschlossene (proprietary) Sockelschnittstelle,
CORBA (Common Object Request Broker Architecture) und Standardbefehle
für programmierbare
Instrumente (SCPI – Standard
Commands for Programmable Instruments) sind die typischen API-Technologien.
Da die geschlossene Sockelschnittstelle statisch und geschlossen
ist, ist es schwierig, an ihr eine Versionsgebung zu vollziehen,
sie mit Kunden gemeinsam zu verwenden und an ihr eine Fehlersuche
durchzuführen.
Insbesondere ist typische API auf der Basis der Sockelschnittstelle
bytebetrieben (d. h. die Sockelschnittstelle ist nicht befehlsbetrieben),
was erfordert, daß die
Netzwerkbedienpersonen unter Verwendung der Sockelschnittstelle
komplexe Softwaretestanwendungen entwickeln und eine Wissensbasis
von Testvorrichtungsbefehlen, die nicht ohne weiteres durch Benutzer
lesbar sind, erwerben müssen.
Insbesondere bezieht sich der Begriff „bytebetrieben" auf eine Kommunikation,
die zum Kommunizieren binäre
Strukturen eines feststehenden Formats verwendet. Ferner erhöht ein Erhöhen von
verteilten Testvorrichtungen die Komplexität der Testvorrichtungen beträchtlich,
indem die bytebetriebenen entfernten Schnittstellen verwendet werden.
Deshalb erhöht
eine Sockelschnittstelle-API Netzwerkanalysekosten, da hierfür eine API-Expertise
erforderlich ist.
-
CORBA bietet nur eine sehr geringe
Unterstützung
in Bezug auf eine Versionsgebung und kann für die Netzwerkbedienpersonen
zu komplex sein. Wenn man beispielsweise ein Problem einer Fehlersuche
unterzieht, ist es schwierig, zwischen einem Kundensoftwarefehler
(Netzwerkbedienperson-Softwarefehler) und einem API-/Befehlsfehler
zu unterscheiden. Ferner liefert CORBA keine ausreichende Sicherheit.
SCPI unterstützt
ebenfalls keine Versionsgebung oder eine dynamische Torzuweisung
und verwendet eine komplexe Befehlsstruktur, die für die Netzwerkbedienpersonen
schwierig zu verwenden ist. Ferner liefert auch SCPI keine ausreichende
Sicherheit.
-
Es ist die Aufgabe der vorliegenden
Erfindung, ein Konzept zu schaffen, das es ermöglicht, eine Netzwerkvorrichtung
unter Verwendung einer Anwendungsschnittstellentechnologie fernzusteuern,
die leicht zu implementieren und einer Versionsgebung zu unterziehen
ist und die sicher und kostengünstig
ist.
-
Diese Aufgabe wird durch Verfahren
gemäß den Ansprüchen 1,
3 oder 12, durch ein System gemäß Anspruch
5 sowie durch eine Testvorrichtung gemäß Anspruch 10 gelöst.
-
Gemäß einem Aspekt der vorliegenden
Erfindung zum Definieren einer Anwendungsprogrammierungsschnittstelle
zum Fernsteuern einer durch eine andere Schnittstelle gesteuerten
Testvorrichtung kann die Erfindung erreicht werden, indem Befehle
und Parameter auf einer höheren
Abstraktionsebene als die Schnittstelle definiert werden und indem
XML-Dokumente (einschließlich jeglicher
Ableitungen der XML-Sprache,
beispielsweise SOAP) auf der Basis der Befehle und der Parameter
erzeugt werden, wodurch eine Anwendungsprogrammierungsschnittstelle
zum Steuern der Testvorrichtung bereitgestellt wird.
-
Ferner entsprechen XML-Dokumentelemente
den Befehlen und den Parametern.
-
Gemäß einem weiteren Aspekt der
vorliegenden Erfindung zum Steuern von Testinstrumenten durch ein
Netzwerk kann die Erfindung erreicht werden, indem eine erweiterbare
selbstdokumentierende Sprache verwendet wird, die verwendet wird,
um Daten zu beschreiben, um eine Anwendungsprogrammierungsschnittstelle
zum Steuern der Testinstrumente durch das Netzwerk zu liefern.
-
Ferner ist XML die selbstdokumentierende
Sprache.
-
Gemäß einem weiteren Aspekt der
vorliegenden Erfindung zum Schaffen eines Systems, das Testvorrichtungen
in einem Netzwerk steuert, kann die Erfindung durch Clientcomputer
erreicht werden, die sich über das
Netz in Kommunikation mit den Testvorrichtungen befinden und Anwendungen
zum Steuern der Testvorrichtungen auf der Basis von XML-Dokumenten erzeugen,
die den Testvorrichtungen eine Anwendungsprogrammierungsschnittstelle
bereitstellen, die die XML-Dokumente über das Netzwerk an die Testvorrichtungen übertragen
und ansprechend auf die übertragenen
XML-Dokumente Daten
von den Testvorrichtungen empfangen.
-
Ferner enthalten empfangene XML-Dokumente
die Daten von den Testvorrichtungen, und ferner wird ein FTP-Protokoll
verwendet, um die Daten von den Testvorrichtungen wiederzugewinnen.
-
Ferner liefert zumindest ein XML-Dokumentaustausch
zwischen einem Clientcomputer und einer Testvorrichtung eine Benutzerauthentifizierung.
-
Ferner entsprechen die XML-Dokumentaustausche
zwischen den Clientcomputern und den Testvorrichtungen Testsitzungen, und
die XML-Dokumente sind verschlüsselt,
was eine Sicherheit der Testsitzung schafft.
-
Gemäß einem Aspekt der vorliegenden
Erfindung zum Liefern einer Testvorrichtung, die sich in Kommunikation
mit einem Netzwerk befindet, kann die Erfindung durch einen programmierten
Prozessor in der Testvorrichtung, welcher über das Netzwerk Befehle empfängt, die
in XML-Dokumenten beschrieben sind, der der Testvorrichtung eine
Anwendungsprogrammierungsschnittstelle bereitstellen, der die Befehle
ausführt
und der ansprechend auf die Ausführung
der Befehle über
das Netzwerk Daten überträgt.
-
Gemäß einem Aspekt der vorliegenden
Erfindung zum Definieren einer Anwendungsprogrammierungsschnittstelle
zum Fernsteuern von Rechenvorrichtungen in einem Netzwerk kann die
Erfindung erreicht werden, indem ein Funktionsprotokoll, das Benutzerschnittstellenfunktionen
der Rechenvorrichtung entspricht, auf der Basis einer Markup-Sprache,
definiert wird und indem eine Interaktion mit den Rechenvorrichtungen durchgeführt wird,
indem Dokumente mit den Rechenvorrichtungen ausgetauscht werden,
wobei die Dokumente gemäß der Markup-Sprache
und dem Funktionsprotokoll erstellt werden.
-
Bevorzugte Ausführungsbeispiele der vorliegenden
Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden
Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Funktionsblockdiagramm eines Netzwerktest/-überwachungsvorrichtungssteuersystems gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
2 Markup-Sprache-Quellcodes
von Anwendungsprogrammierungsschnittstellenspezifikationen zum Fernsteuern
einer Netzwerktest-/-überwachungsvorrichtung
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
3 Markup-Sprache-Quellcodes
von anderen Anwendungsprogrammierungsschnittstellenspezifikationen
zum Fernsteuern einer Netzwerktest-/-überwachungsvorrichtung gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung;
-
4 Markup-Sprache-Quellcodes
von anderen Anwendungsprogrammierungsschnittstellenspezifikationen
zum Fernsteuern einer Netzwerktest-/-überwachungsvorrichtung gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung;
-
5 Markup-Sprache-Quellcodes
von anderen Anwendungsprogrammierungsschnittstellenspezifikationen
zum Fernsteuern einer Netzwerktest-/-überwachungsvorrichtung gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung;
-
6 ein
Flußdiagramm
von Operationen zum Steuern einer Netzwerktest-/-überwachungsvorrichtung
unter Verwendung von Markup-Sprache-Dokumenten gemäß einem
Ausführungsbeispiel
der Erfindung;
-
7 ein
detailliertes Blockdiagramm von Softwareprozessen in einem Vorrichtungssteuersystem
gemäß einem
anderen Ausführungsbeispiel
der Erfindung; und
-
8 ein
Flußdiagramm
von ausführlichen
Operationen zum Einrichten einer Testsitzung durch ein Steuern von
Netzwerkanalysatoren in dem in 7 gezeigten
Vorrichtungssteuersystem.
-
1 ist
ein Blockdiagramm eines Netzwerktest/-überwachungsvorrichtungssteuersystems
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung. In 1 befinden
sich Netzwerktestvorrichtungen (Meß- und/oder Überwa chungsvorrichtungen)
(-Instrumente) 100a-n (Testeinheit(en) 100a-n)
in Kommunikation mit Netzwerken 105a-n und führen an
Testnetzwerken 155a-n verschiedene Tests, Messungen und/oder Überwachungsvorgänge an Daten
durch. In der Regel ist jede Testeinheit 100 ein Computer
oder eine beliebige Rechenvorrichtung (z. B. Desktop, tragbar, in
der Hand zu haltend usw.), der bzw. die mit den Netzwerken 105 und
den Testnetzwerken 155 kommunizieren und unter Verwendung
herkömmlicher
Techniken Informationen empfangen/senden, speichern, anzeigen und
verarbeiten kann. Insbesondere führt
die Testeinheit 100 in der Regel eine Software aus, die
ein typisches Testen/Überwachen
eines Datenaustauschs/Netzwerkverkehrs an den Testnetzwerken 155 und/oder
Meßfunktionen,
die sich auf einen Datenaustausch/Netzwerkverkehr in den Testnetzwerken 155 beziehen,
durchführt.
Beispielhafte Testeinheiten 100 umfassen (ohne Einschränkung) Sprachqualitätstester
(VQTs – voice
quality testers), die Echtzeittransportprotokoll-Pakete (RTP-Pakete, RTP = Real-Time
Transport Protocol) überwachen,
um eine Ende-zu-Ende-Sprachqualität zu ermitteln, verteilte Netzwerkanalysatoren
(DNAs – distributed
network analyzers), die Kommunikationsprotokolle analysieren, und/oder
Logikanalysatoren. Testeinheiten sind von Agilent Technologies,
Inc., Palo Alto, Kalifornien, Bevollmächtigte der vorliegenden Anmeldung,
erhältlich.
-
In 1 kann
das Netzwerk 105 verdrahtet oder drahtlos sein und eine
herkömmliche
Topologie und eine herkömmliche
Architektur aufweisen. Die Architektur des Netzwerks 105 kann
beispielsweise ein Client-Server sein, der herkömmliche Kommunikationsprotokolle,
wie beispielsweise das TCP/IP (Transmission Control Protocol/Internet
Protocol – Übertragungssteuerungsprotokoll/Internetprotokoll),
verwendet. Ferner kann das Netzwerk 105 beispielsweise
ein lokales Netzwerk oder ein Weitverkehrsnetzwerk sein. Das Testnetzwerk 155 kann
eine beliebige Datenkommunikationstechnologie sein, die durch die
Testeinheiten 100 getestet wird. Beispielsweise kann das
Testnetzwerk 155 verdrahtet oder drahtlos sein und eine
beliebige herkömmliche
Topologie und eine beliebige herkömmliche Architektur aufweisen.
Die Architektur des Testnetzwerks 155 kann beispielsweise
ein Client-Server sein, der herkömmliche
Kommunikationsprotokolle verwendet, beispielsweise eine beliebige
Sprachnetzwerktechnologie, T1, E1, VolP, das TCP/IP usw. Ferner
kann das Testnetzwerk 155 beispielsweise ein lokales Netzwerk
oder ein Weitverkehrsnetzwerk sein.
-
Als Beispiel einer Verwendung einer
Client-Server-Netzwerkarchitektur
auf der Basis eines IP-Netzwerks 105, beispielsweise des
Internets oder eines Intranets, befinden sich die Client-Computersysteme 110a-n in 1 in Kommunikation mit den
Testeinheiten 100a-n über
das IP-Netzwerk 105. Die vorliegende Erfindung wird erreicht,
indem eine Markup-Sprache verwendet wird, um eine entfernte bytebetriebene
Befehlsschnittstelle einer Testeinheit 100 zu definieren,
wodurch eine Markup-Sprache-Anwendungsprogrammierungsschnittstelle
(API) geliefert wird, um die Testeinheit 100 über Markup-Sprache-Dokumente
fernzusteuern. Die Markup-Sprache-API befindet sich auf einer höheren Abstraktionsebene
als die entfernte bytebetriebene Befehlsschnittstelle, die üblicherweise
verwendet wird, um die Testeinheit 100 fernzusteuern. Deshalb liefert
die Markup-Sprache-API eine entfernte befehlsbetriebene Benutzerschnittstelle,
um die Testeinheit 100 zu steuern. Der Begriff „befehlsbetrieben"
bezieht sich auf eine Steuerung und/oder Datenkommunikation, die ein
flexibles, für
einen Benutzer lesbares/verständliches
Datenformat, insbesondere von der Perspektive eines Benutzers auf
einer Steuerseite (entfernten Seite) aufweist, wo Positionen von
Befehlen durch eine zugrundeliegende Transportsoftware gehandhabt
werden und vorgeschrieben sind. Auf einer Empfangsseite interpretiert
ein Anwendungsprogramm empfangene Befehle und Befehlsparameter.
Insbesondere wird zum Definieren der Markup-Sprache-API in der Regel
eine Markup-Sprache
gemäß den Regeln
der standardgemäßen verallgemeinerten
Markup-Sprache (SGML – Standard
Generalized Markup Language), beispielsweise (ohne Einschränkung) erweiterbare
Markup-Sprache (XML – Extensible
Markup Language), einfaches Objektzugriffsprotokoll (SOAP – Simple
Object Access Protocol) verwendet. In der Regel ist die Wahlsprache
XML, einschließlich
jeglicher XML-Erweiterungen/-Ableitungen, beispielsweise SOAP, da
sie für
eine Datenkommunikation (d. h. XML liefert Regeln zum Definieren
und Interpretieren von Kennungen für eine Datenkommunikation)
und eine Erweiterbarkeit maßgeschneidert
ist und ein leicht zu lesendes Format im Sinne eines Verständnisses
seitens Benutzern aufweist.
-
In 1 kann
ein herkömmlicher
(d. h. im Handel oder von einer offenen Quelle erhältlicher)
XML-Dokumentschreiber/-editor 115 verwendet
werden, um XML-Dokumente zu erstellen und/oder zu erzeugen, die Befehle/Antworten
und Befehls/Antwortparameter (XML-Schnittstellendokumente) auf einer
höheren
Abstraktionsebene spezifizieren als eine entfernte Schnittstelle
(bitbetriebene Schnittstelle), die verwendet wird, um mit der Testeinheit 100 eine
Schnittstelle zu bilden/dieselbe zu steuern. Ein herkömmlicher
XML-Parser bzw. -Analysierer 120 kann verwendet werden,
um die XML-Schnittstellendokumente
zu validieren und zu parsen bzw. analysieren, um die XML-Daten einer
Testeinheitsanwendung 127 zur Verfügung zu stellen. Deshalb wird der
XML-Standard verwendet, um Befehle, Parameter und Daten der Testeinheit 100 (z.
B. Antworten/Testergebnisse) zwischen der Testeinheit 100 und
dem Clientcomputer 110 zu definieren, übertragen, validieren und interpretieren,
wodurch eine API bereitgestellt wird, um mit der Testeinheit 100 eine
Schnittstelle zu bilden/um dieselbe zu steuern. Die auf der Basis
von XML definierte API kann eine Funktionalität und einen Fluß einer lokalen
Benutzerschnittstelle der Testeinheit 100 spiegeln (d.
h. in der Regel kann der Benutzer der API im großen und ganzen einer selben
Sequenz eines Benutzers einer GUI (graphische Benutzerschnittstelle)
folgen, um einen Test durchzuführen).
Obwohl das beispielhafte Ausführungsbeispiel
XML verwendet, um Testeinheit-APIs zu defi nieren, ist die vorliegende
Erfindung nicht auf eine derartige Konfiguration beschränkt, und
die vorliegende Erfindung kann unter Verwendung anderer Markup-Sprachen
implementiert werden, die Regeln zum Definieren und Interpretieren
von Kennungen für
eine Datenübertragung
liefern, einschließlich
anderer Markup-Sprachen gemäß den SGML-Regeln.
-
In 1 ist
eine Clientanwendungssoftware 125 eine Testanwendung, die
beispielsweise durch eine Netzwerkbedienperson geschrieben wurde,
um Messungen/Tests durchzuführen
(d. h. Testeinheitsanwendungen 127 an den Testeinheiten 100 auszuführen), die
sich auf einen Netzwerkverkehr der Testnetzwerke 155a-n beziehen,
unter Verwendung der Testeinheiten 100a-n eines oder mehrerer
Verkäufer.
Die Clientanwendungssoftware 125 bildet eine Schnittstelle
mit dem XML-Dokumentschreiber 115 und
dem XML-Dokumentparser 120, um über den XML-Dokumentschreiber 115 bzw.
den XML-Dokumentparser 120 Steuerbefehle
zu senden bzw. zu empfangen, um die Testeinheit 100 zu
steuern. Bei einem Aspekt der Erfindung liefert die Clientanwendung 125 die
Steuerbefehle als Eingangsdaten an den XML-Dokumentschreiber 115,
der die XML-Schnittstellendokumente auf der Basis der Eingangsdaten
erzeugt, wodurch die XML-Schnittstellendokumente
automatisch als Teil einer Clientanwendungslogik erzeugt werden.
Bei einem anderen Aspekt der Erfindung kann die Clientanwendungssoftware 125 eine
Bibliothek von XML-Schnittstellendokumenten mit vordefinierten Steuerbefehlen
für die
Testeinheit 100 verwenden. Bei einem anderen Aspekt der
Erfindung wird der XML-Dokumentschreiber 115 verwendet,
um die XML-Schnittstellendokumente
zu erstellen/erzeugen, und die Clientanwendung 125 sendet
und empfängt
die erzeugten XML-Schnittstellendokumente
an die bzw. von der Testeinheit 100, um die Testeinheit 100 zu
steuern.
-
In 1 sendet
die Clientanwendung 125 das erzeugte XML-Schnittstellendokument über einen
Hypertext-Übertragungsprotokoll-Prozeß (HTTP-Client 130,
HTTP = HyperText Transfer Protocol) an die Testeinheit 100.
HTTP wird aufgrund seiner breiten Akzeptanz, einfachen Schnittstelle
und seines Sicherheitsvorteils, der sich daraus ergibt, daß es eine
Sicherheitssockelschicht-Verbindung (SSL-Verbindung, SSL = Secure
Socket Layer) erfordert, um einen sicheren Datenaustausch zu liefern,
als das Transportschichtprotokoll verwendet. Bei einem anderen Ausführungsbeispiel
kann auch ein Sicheres-HTTP-Prozeß (S-HTTP – Secure HTTP) als das Transportschichtprotokoll,
das einen sicheren Datenaustausch unterstützt, verwendet werden.
-
Ferner kann in 1 die Clientanwendung 125 über einen
Dateitransferprotokoll-Prozeß (FTP-Prozeß (FTP =
File Transfer Protocol) (FTP-Client 140)) eine Schnittstelle
mit einer FTP-API 135 bilden, um Datensätze (Dateien) an die Testeinheit 100 zu
senden und von derselben zu empfangen. Bei 1 entsprechen HTTP/XML-Serverprozesse 145 und
ein FTP-Serverprozeß 150 in
der Testeinheit 100 den HTTP/XML-Clientprozessen 130, 115 und 120 bzw.
dem FTP-Clientprozeß 140,
was eine Netzwerkkommunikation unter Verwendung herkömmlicher
Techniken einrichtet. Die vorliegende Erfindung ist nicht auf die
beispielhafte Mehrschichtanwendungsarchitektur des in 1 gezeigten Clientcomputers 110 beschränkt, und
andere geschichtete Anwendungsarchitekturen, die eine Markup-Sprache-API
berücksichtigen,
können
verwendet werden. Obwohl die HTTP/XML-Serverprozesse 145 bei dem
beispielhaften Ausführungsbeispiel
in der Testeinheit 100 vorgesehen sind, ist die vorliegende
Erfindung ferner nicht auf eine derartige Konfiguration beschränkt, und die
Serverprozesse 145 können
mit der Testeinheit 100 integriert oder auf einem separaten
Computer (siehe 7),
der sich in Kommunikation mit der Testeinheit 100 befindet,
ausgeführt
werden.
-
2–5 sind Markup-Sprache-Quellcodes
von Anwendungsprogrammierungsschnittstellenspezifikationen zum Fernsteuern
einer Netzwerktest-/-überwachungsvorrichtung
gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung.
-
Insbesondere sind 2–5 Quellcodes beispielhafter
XML-Schnittstellendokumente,
einschließlich Quellcodekommentare/-anmerkungen,
zum Steuern eines Netzwerkanalysators, wie beispielsweise der Testeinheit 100,
wodurch eine API bereitgestellt wird, die es Programmierern (d.
h. den Netzwerkbedienpersonen) ermöglicht, über ein Steuern des Netzwerkanalysators 100 Netzwerktest-,
-meß-
und/oder -überwachungsanwendungen
zu erstellen. 2 ist
XML-Schnittstellendokumentquellcodes
für eine
Einlogg-XML-Schnittstelle
bzw. Login-XML-Schnittstelle 200, eine Login-Akzeptieren-XML-Schnittstelle 205 und eine
Auslogg-XML-Schnittstelle
bzw. Logout-XML-Schnittstelle 210. 3 ist ein XML-Schnittstellendokumentquellcode
für eine
Protokollstatistikmessung-XML-Schnittstelle 300. 4 ist ein XML-Schnittstellendokumentquellcode für eine Protokollstatistikmessungsanforderung-Akzeptiert-XML-Schnittstelle 400. 5 ist XML-Schnittstellendokumentquellcodes
für eine
Erhalte-Protokollstatistikergebnisse-XML-Schnittstelle 500 und
eine Erhalte-Protokollstatistikergebnisse-Antwort-XML-Schnittstelle 505.
Andere XML-Schnittstellendokumente, die die Funktionalität und den
Fluß einer
Benutzerschnittstelle des Netzwerkanalysators 100 widerspiegeln,
können
Versionsanfrage-, Ruhe-, Neubootungs-, Sichere-Rahmenpuffer- und
Gewinne-Rahmeninformationen-Wieder-Funktionen sein.
-
In den 2–5 können Befehle/Antworten und
Befehls/Antwortparameter, die mit der Testeinheit 100 eine
Schnittstelle bilden sollen, gemäß XML als
Aufzeichnungsbzw. Feldstrukturen auf einer höheren Abstraktionsebene als
entfernte Befehle und Befehlsparameter der Testeinheit 100 organisiert
sein. Vorteilhafterweise können
die Befehle/Antworten und die Befehls/Antwortparameter als Knoten/Elemente
organisiert sein, die stärker
verschachtelt sind als die Aufzeichnungen und Feldstrukturen. Die
XMLbasierte API ermöglicht
es Programmierern vorteilhafterweise, ohne weiteres Clientanwendungen 125 zu
erzeugen, indem sie Befehle und Befehlsparameter unter Verwendung
von für
Personen lesbaren Ausdrücken
(Werten) spezifizieren. In
-
3 kann
ein Programmierer beispielsweise RahmenFilterund ZähleRahmen-Parameter
eines Protokollstatus-Befehls bezeichnen/benennen, indem er Ausdrucksoptionen „ALLE_RAHMEN", „WEISE_RUNT_ZURÜCK", WEISE
FEHLER ZURÜCK", „ALLE_RAHMEN",
VON_STATION", „AN_STATION" bzw. „VON_AN_STATION"
eingibt. Vorteilhafterweise kann das XML-Dokument Anmerkungen in bezug auf Befehls/Antwortfunktionen,
Befehls-/Antwortparameteroptionen und andere Optionen enthalten.
Bei der XML-basierten API kann der Verkäufer der Testeinheit 100 ferner
mit einer minimalen Auswirkung auf vorhandene Clientanwendungen 125 die
API ohne weiteres einer Versionsgebung unterziehen (sie aktualisieren), beispielsweise
indem er neue Merkmale zu den API-Dokumenten hinzufügt.
-
6 ist
ein Flußdiagramm
von Operationen zum Steuern einer Netzwerktest-/-überwachungsvorrichtung
unter Verwendung von Markup-Sprache-Dokumenten gemäß einem
Ausführungsbeispiel
der Erfindung. Insbesondere ist 6 ein
beispielhafter HTTP-Sitzungseinrichtungs- und XML-Schnittstellendokumentfluß zwischen
der Clientanwendung 125 und dem Netzwerkanalysierer 100 zum
Testen/Messen/Überwachen
von Netzwerkverkehr über
den Netzwerkanalysierer 100. Bei einer Operation 600 gibt
die Clientanwendung 125 das Login-XML-Schnittstellendokument 200 über den
HTTP-Client 130 an den HTTP/XML-Server 145 in
dem Netzwerkanalysierer 100 auf. Die Login-XML-Schnittstelle 200 kann
einen Login-Benutzernamen und ein Login-Paßwort aufweisen. Die XML-Schnittstellendokumente,
beispielsweise die Login-XML-Schnittstelle 200, können unter
Verwendung beliebiger herkömmlicher
Techniken über
den XML-Dokumentschreiber 115 gebildet werden.
-
In 6 gibt
der HTTP/XML-Server 145 in einer Operation 605 eine Antwort
mit der Login-Akzeptieren-XML-Schnittstelle 205 an
die Clientanwendung 125 auf. Ein Statusfeld der Login-Akzeptieren-XML-Schnittstelle 205 kann
entweder in bezug auf einen Erfolg „akzeptiert" oder in bezug
auf einen Mißerfolg „zurückgewiesen"
werden. Im Fall eines erfolgreichen Einloggens liefert die Login-Akzeptieren-XML-Schnittstelle 205 ein
Token (z. B. ein Cookie), das in nachfolgenden HTTP-Aufgaben von XML-Schnittstellendokumenten
verwendet werden soll. In der Regel muß das Cookie für eine weitere
Kommunikation mit dem HTTP/XML-Server 145 verwendet werden.
Ferner läuft
das Cookie in der Regel ab, wenn das Cookie über einen vorbestimmten Zeitraum
nicht verwendet wird, was einen weiteren Login-XML-Schnittstellendokumentaustausch
zwischen der Clientanwendung 125 und dem HTTP/XML-Server 145 erforderlich macht.
Wenn das Einloggen bei der Operation 605 erfolgreich ist,
kann die HTTP-Sitzung in der Regel beendet werden, falls sich die
Clientanwendung 125 ausloggt oder der HTTP/XML-Server 145 einen
Zeitablauf eines Cookie feststellt und das Cookie als ungültig markiert.
Deshalb führen
die Operationen 600 und 605 eine Benutzerauthentifizierung
durch. Die XML-API kann eine Testsitzungssicherheit liefern, indem
sie verfügbare
Sicherheitsmaßnahmen
der HTTP-Client-Server-Architektur verwendet.
-
In 6 gibt
die Clientanwendung 125 bei einer Operation 610 einen
Messung-Durchführen-Befehl bei
der Protokollstatistikmessung-XML-Schnittstelle 300 an
den HTTP/XML-Server 145 auf. Bei einer Operation 620 empfängt der
HTTP/XML-Server 145 die
Messung-Durchführen-XML-Schnittstelle 300,
parst dieselbe und stellt die XML-Daten als Eingangsbefehle der
Testeinheitsanwendung 127 zur Verfügung. Die Messung-Durchführen-XML-Schnittstelle 300 definiert
einen Steuerknoten „Messung",
der auf einer höheren
Abstraktionsebene einem entfernten Schnittstellenbefehl entspricht,
der durch den Netzwerkanalysierer 100 erkannt werden kann.
Die Messung-Durchführen-XML-Schnittstelle 300 definiert
ferner einen Parameterknoten „ProtocolStats"
des „Messung"-Steuerknotens, der
auf einer höheren
Abstraktionsebene optionalen Parametern des entfernten Schnittstellenbefehls
entspricht. Der Parameterknoten „ProtocolStats" enthält Attribute
und akzeptable Attributwerte. Die Attributnamen „AktualisierungsIntervall", „NachzuverfolgendeProtokolle", „RahmenFilter", „ZählerRahmen"
und „Operation"
beschreiben auf einer höheren
Abstraktionsebene Funktionen der entsprechenden optionalen Parameter
des entfernten Schnittstellenbefehls. Die Attributwerte eines Attributs
(Parameters) beschreiben auf einer höheren Abstraktionsebene verfügbare Funktionen
eines entsprechenden optionalen Parameters des entfernten Schnittstellenbefehls.
-
In 6 empfängt und
parst der HTTP/XML-Server 145 bei einer Operation 615 die
Messung-Durchführen-XML-Schnittstelle 300 und
stellt die in der Messung-Durchführen-XML-Schnittstelle 300 enthaltenen XML-Daten
als Eingangsbefehle der Testeinheitsanwendung 127 zur Verfügung. Bei
der Operation 615 gibt die Testeinheitsanwendung 127 eine
Messung-Durchführen-Akzeptieren-Antwort
mit der Protokollstatistikmessungsanforderung-Akzeptiert-XML-Schnittstelle 400 auf.
Wenn der HTTP/XML-Server 145 bei der Operation 615 die
Messung-Durchführen-XML-Schnittstelle 300 empfängt, kann
der Server 145 die Anforderung auf der Basis des Sicherheitsgrades
des Benutzers und/oder auf der Basis einer Validierung von Eingangsbefehlen
und Parametern, die in der Messung-Durchführen-XML-Schnittstelle 300 enthalten
sind, entweder akzeptieren oder zurückweisen. Die Messung-Durchführen-Akzeptieren-XML-Schnittstelle 400 definiert
einen „MeßAntwort"-Knoten,
der Attribute „Status", „Erklärung" und „Id" enthält, die
die Clientanwendung 125 mit Antwortinformationen versorgen.
Beispielsweise verwendet die Clientanwendung 125 den „Id"-Attributwert
zum Anfordern von Meßergebnissen.
-
In 6 gibt
die Clientanwendung 125 bei einer Operation 620 einen
Erhalte-Ergebnisse-Befehl bei der Erhalte-Protokollstatistikergebnisse-XML-Schnittstelle 500 an
den HTTP/XML-Server 145 auf. Bei einer Operation 625 empfängt der
HTTP/XML-Server 145 die Erhalte-Ergebnisse-XML-Schnittstelle 500,
parst dieselbe und stellt die empfangenen XML-Daten als Eingangsbefehle
der Testeinheitsanwendung
127 zur Verfügung. Das „ProtocolStats Id"-Attribut
kann den „Id"-Attributwert
enthalten, der durch die Testeinheitsanwendung 127 in der
Messung-Durchführen-Akzeptieren-XML-Schnittstelle 400 bei
der Operation 615 als Antwort auf eine Initiierung des
Tests zurückgegeben
wurde. Bei der Operation 625 gibt die Testeinheitsanwendung 127 eine
Akkumulierte-Meßergebnisse-Antwort
bei der Protokollstatistikergebnisseantwort-XML-Schnittstelle 505 auf.
Insbesondere führt
die Testeinheitsanwendung 127 bei der Operation 625 angeforderte
Meßprozesse ansprechend
auf die Erhalte-Ergebnisse-XML-Schnittstelle 500 aus
und akkumuliert entsprechende Meßergebnisse, die in der Akkumulierte-Meßergebnisse-XML-Schnittstelle 505 enthalten
sind. Beispielsweise kann die Akkumulierte-Meßergebnisse-XML-Schnittstelle 505 DLLTyp-Knoten
für jedes
durch den Netzwerkanalysierer 100 erfaßten Datenlinkschichtprotokoll
definieren.
-
Bei einem weiteren Ausführungsbeispiel
in 6 kann die Testeinheitsanwendung 127 bei
der Operation 625 die Meßergebnisse beispielsweise
in Datendateien akkumulieren, die in dem Netzwerkanalysierer 100 angeordnet
sind, wie durch die aufgegebene Erhalte-Ergebnisse-XML-Schnittstelle 500 spezifiziert
ist. Die Clientanwendung 125 kann die akkumulierten Ergebnisse über eine
FTP-Verbindung/Sitzung mit einem FTP-Server 150 in dem
Netzwerkanalysierer 100 wiedergewinnen. Insbesondere richtet
die Clientanwendung 125 die FTP-Verbindung mit dem FTP-Server 150 über die
FTP-API 135 und den FTP-Client 140 ein. Die Testeinheitsanwendung 127 kann
die Clientanwendung 125 von einer Verfügbarkeit von Meßergebnisdateien über eine
Aufgabe der Erhalte-Ergebnisse-Antwort-XML-Schnittstelle 500 in
Kenntnis setzen. Vorteilhafterweise kann die Clientanwendung 125 den
Netzwerkanalysierer 100 über XML-Schnittstellendokumente
verwalten, um einen Test zu initiieren, Testergebnisse zu akkumulieren
und die Testergebnisse entweder über
Antwort-XML-Schnittstellendokumente
und/oder, im Fall großer
Daten rückgewinnungen,
beispielsweise einer Datenrahmenrückgewinnung, über FTP
wiederzugewinnen.
-
In der bei der Operation 600 initiierten
Testsitzung können
in 6 Operationen 630 und 635 andere XML-Schnittstellendokumente
sein, die zwischen der Clientanwendung 125 und dem Netzwerkanalysierer 100 fließen, um
einen Netzwerkverkehr durch ein Verwalten des Netzwerkanalysierers 100 zu
testen/messen/überwachen.
-
In 6 kann
die Clientanwendung 125 bei einer Operation 640 die
Testsitzung beenden, indem sie die Logout-XML-Schnittstelle 210 an den HTTP/XML-Server 145 aufgibt.
Bei einer Operation 650 empfängt der HTTP/XML-Server 145
die Logout-XML-Schnittstelle 210, parst dieselbe und stellt
die XML-Daten als Eingangsbefehle der Testeinheitsanwendung 127 zur
Verfügung.
Bei einer Operation 645 kann die Testeinheitsanwendung 127 eine
Ausloggen-Akzeptieren-XML-Schnittstelle
(nicht gezeigt) aufgeben. Bei der Operation 645 erklärt der HTTP/XML-Server
145 das ausgegebene Cookie für
ungültig,
um die Testsitzung zu beenden.
-
Bei 6 sind
Operationen, die eine Netzwerktest/-überwachungsvorrichtung auf
der Basis der in 2–5 gezeigten XML-Schnittstellendokumente
steuern, beispielhafte Operationen, und die vorliegende Erfindung
ist nicht auf einen derartigen XML-Schnittstellendokumentfluß und/oder
die XML-Schnittstellendokumente der 2–5 beschränkt. Dementsprechend können auch
andere XML-Typ-Schnittstellendokumente verwendet
werden, die entfernte Schnittstellenbefehle der Testeinheiten 100 gemäß den XML-Regeln definieren
und/oder enthalten (einschließen).
Die entfernten Schnittstellenbefehle der Testeinheiten 100 können gemäß den XML-Regeln
auf der Basis von Metaphern einer Datenbankstruktur, von verschachtelten
Knoten/Elementen usw., die einer Funktionalität und einem Fluß von Benutzerschnittstellen
der Testeinheiten 100 entsprechen, beschrieben werden.
-
7 ist
ein detailliertes Blockdiagramm von Softwareprozessen in einem Vorrichtungssteuersystem gemäß einem
anderen Ausführungsbeispiel
der Erfindung. Der HTTP/XML-Server 700 entspricht dem HTTP/XML-Server 145.
Der HTTP/XML-Server 700 ist in einem Computersystem verkörpert und
befindet sich über
die Netzwerke 105a-n bzw. 155a-n in Kommunikation
mit dem Client-Computersystem 100 und den Testeinheiten 100a-n.
In der Regel ist jede Testeinheit 100 ein Computer oder
eine beliebige Rechenvorrichtung, der bzw. die mit den Testnetzwerken 155 kommunizieren
kann und unter Verwendung herkömmlicher
Techniken Informationen empfangen/senden, speichern, anzeigen und
verarbeiten kann. Insbesondere führt
jede Testeinheit 100 in der Regel eine Software aus, die
ein typisches Testen/Überwachen
eines Datenaustauschs/Netzwerkverkehrs an den Testnetzwerken 155 und/oder
Meßfunktionen,
die sich auf einen Datenaustausch/Netzwerkverkehr in den Testnetzwerken 155 beziehen,
durchführt.
-
8 ist
ein Flußdiagramm
von detaillierten Operationen zum Einrichten einer Testsitzung durch
ein Steuern von Netzwerkanalysierern in dem in 7 gezeigten Vorrichtungssteuersystem.
Als Beispiel, das eine Client-Server-Netzwerkarchitektur in IP-Netzwerken 105a, 105b,
beispielsweise dem Internet oder einem Intranet, verwendet, befinden
sich Client-Computersysteme 110a-n in Kommunikation mit
Netzwerkanalysierern 100a-n als die Testeinheiten 100a-n über den
HTTP/XML-Server 700. Insbesondere befinden sich die Client-Computersysteme 110a-n über das
IP-Netzwerk 105a in Kommunikation mit dem HTTP/XML-Server 700, und
der HTTP/XML-Server 700 befindet sich über das IP-Netzwerk 105b in
Kommunikation mit den Testeinheiten 100a-n. Bei einer Operation 800 wird
die Clientanwendung 125 über einen Einheitsressourcenlokator (URL – Universal
Resource Locator) mit einer spezifischen Testeinheitsanwendung 127 verknüpft. Insbesondere
sendet die Clientanwendung 125 über das Netzwerk 105a eine
URL-Verknüpfungsanforderungs nachricht an
einen statischen und dynamischen URLs-Prozeß 705 in dem HTTP/XML-Server 700.
Was die Testeinheitsanwendung 127 angeht, so weist die
Testeinheitsanwendung 127 in der Regel eine Testinstrumentanwendung 745 auf,
die Test-, Meß-
und/oder Überwachungssoftwareprozesse
bezüglich
des Netzwerkverkehrs in den Testnetzwerken 155 verkörpert. Ferner
weist die Testeinheitsanwendung 127 in der Regel eine Erfassungshardware 750 auf,
die Test-, Meß-
und/oder Überwachungshardwareprozesse
bezüglich
des Netzwerkverkehrs in den Testnetzwerken 155 verkörpert.
-
Bei 8 richtet
ein HTTP-Serverprozeß 710 des
HTTP/XML-Servers 700,
der sich in Kommunikation mit dem statischen und dynamischen URLs-Prozeß 705 befindet,
bei einer Operation 805 eine HTTP-Verbindung mit der empfangenen
URL-Anforderung
ein. Bei einer Operation 810 sendet die Clientanwendung 125 über den
XML-Dokumentschreiber 115 und den HTTP-Client 130 das
Login-XML-Schnittstellendokument 200 an den HTTP/XML-Server 700.
Die Login-XML-Schnittstelle 200 kann einen Benutzernamen
und ein Paßwort oder
andere Benutzerauthentifizierungsinformationen enthalten.
-
In 8 empfängt der
HTTP-Server 710 bei einer Operation 815 die Login-XML-Schnittstelle 200 und stellt
sie Servlet-Prozessen 712 bereit.
Die Servlet-Prozesse 712 weisen Testeinheitsservlets 715 und
ein XML-Leitungsservlet (z. B. CORBA-Namensdienst) 720 auf,
die XML-Dokument-Schreib-, -Pars-, -Validierungs- und allgemeine
Sicherheitsdienste (Login-Dienste) in Verbindung mit der Testsitzung
liefern. Bei der Operation 815 prüfen die Servlet-Prozesse 712,
ob zwischen dem Server 700 und der Testeinheit 100 eine XML-Kommunikationsleitung
eingerichtet werden kann, indem sie bestimmen, ob die angeforderte
Testeinheitsanwendung 127 (bei Operation 800 angefordert)
bei einem CORBA-Namensdienst
registriert ist. Falls die Testeinheitsanwendung 127 bei
der Operation 815 nicht bei dem CORBA-Namensdienst registriert ist, sendet das
XML-Leitungsservlet 720 bei
einer Operation 820 über
das Netz werk 105b eine Testanwendung-Laden-Anforderung
an einen CORBA-XML-Leitungsprozeß 730 der Testeinheit 100.
Bei einer Operation 830 wartet das XML-Leitungsservlet 720,
bis der CORBA-XML-Leitungsprozeß 730 die
angeforderte Testeinheitsanwendung 127 registriert, indem
er dem XML-Leitungsservlet 720 einen Rückruf für eingehende Nachrichten (eine
Nachrichtenübermittlungsklasse)
bereitstellt.
-
Nachdem die Testeinheitsanwendung 127 bei
dem CORBA-Namensdienst
registriert ist, geben die Servletprozesse 712 bei einer
Operation 835 in 8 das
Login-Akzeptieren-XML-Schnittstellendokument 205 an
die Clientanwendung 125 zurück. Bei einer Operation 840 sendet
die Clientanwendung 125 das Protokollstatistikmessung-XML-Schnittstellendokument 300,
um einen Test einzuleiten. Bei einer Operation 845 verifiziert
das Testeinheitsservlet 715 einen Sitzungsschlüssel der
eingehenden Messungsanforderung 300. Bei einer Operation 850 leitet
das XML-Leitungsservlet 712 das eingehende Protokollstatistikmessung-XML-Schnittstellendokument 300 über den
Rückruf
in die Testeinheitsanwendung 127 (z. B. die Testinstrumentanwendung 745 und/oder
die Erfassungshardware 750).
-
In 8 empfängt die
Testeinheitsanwendung 127 bei einer Operation 855 das
Protokollstatistikmessung-XML-Schnittstellendokument 300 und
parst dasselbe (beispielsweise über
einen XML-Dokumentparser 740), um Befehlsinformationen,
beispielsweise Meßtyp
und Parameter, wiederzugewinnen. Bei einer Operation 860 erzeugt
die Testeinheitsanwendung 127 das Protokollstatistikmessungsanforderung-Akzeptiert-XML-Schnittstellendokument 400 (beispielsweise über den
XML-Dokumentschreiber 735) und gibt das erzeugte XML-Dokument 400 über den
Rückruf
an die Clientanwendung 125 zurück. Bei einer Operation 860 spezifiziert
das XML-Schnittstellendokument 400 Rückkanal-URL-Parameter in dem „Id"-Feld
des XML-Schnittstellendokuments 400. Bei einer Operation 865 öffnet die
Clientanwendung 125 eine Verbindung mit dem Rückkanal-URL
und führt
ein Erhalten durch, indem sie das Erhalte-Protokollstatistikergebnisse-XML-Schnittstellendokument 500 sendet.
Bei einer Operation 870 empfängt die Testeinheitsanwendung 127 das
Erhalten und führt
die Messung durch.
-
In 8 bildet
die Testeinheitsanwendung 127 bei einer Operation 875,
während
Meßergebnisse
erzeugt werden, die Erhalte-Protokollstatistikergebnisse-Antwort-XML-Schnittstellendokumente 505 und
sendet die gebildeten XML-Dokumente 500,
die Ergebnisse enthalten, über
die Nachrichtenübermittlungsklasse
an die Clientanwendung 125. Bei einer Operation 880 sendet
die Clientanwendung 125, wenn genügend Ergebnisse gesammelt wurden,
ein Stop-XML-Schnittstellendokument,
beispielsweise das Logout-XML-Schnittstellendokument 210,
um die Testsitzung zu beenden.
-
In 8 kann
die Clientanwendung 125 bei Operationen 865–875 Rahmenpuffer
der Testnetzwerke 155 wiedergewinnen. Die Rahmenpufferdaten
können
in XML-Dokumenten enthalten/beschrieben sein, die eine Lesbarkeit
und Analyseeffizienz auf der Seite des Clientcomputers 110 erhöhen. Insbesondere
werden die XML-Dokumente, die die Rahmenpufferdaten beschreiben,
zum Verarbeiten (z. B. Anzeige, Ausgabe, Analyse usw.) an die Clientanwendung 125 gesandt.
Da Rahmenpufferdaten groß sein
können,
kann die Clientanwendung 125 jedoch optional die Testeinheitsanwendung 127 steuern,
um unter Verwendung bekannter Techniken Pufferdaten in Dateien,
beispielsweise in den Testeinheiten 100, zu sichern. Die
Clientanwendung 125 kann die gesicherten Rahmenpufferdaten über FTP-Sitzungen
anstatt einer Verwendung von XML-Dokumenten wiedergewinnen, um die Übertragungseffizienz
zu erhöhen.
Allerdings kann die Clientanwendung 125 die gesicherten
Rahmenpufferdaten auch über
HTTP-Dateitransfersitzungen
wiedergewinnen.
-
Wie in 7 und 8 gezeigt ist, sind Komponenten
der Erfindung üblicherweise
Servlets, eine Nachrichtenübermittlungsklasse,
ein Anwendungslader und eine XML- Dokumentenbibliothek.
Ein Servletbehälter, beispielsweise
die Servletprozesse 712, übergibt XML-Dokumente über eine
HTTP-Verbindung an die Clientcomputer 110, die die Client(Test-)anwendungen
125 ausführen.
In der Regel verarbeiten die Servlets Logins, verwalten Sitzungen,
akzeptieren Meßstart-/-stop-/usw.
-Befehle und verwalten asynchrone Rückkanäle für zurückgegebene Daten von den Testeinheitsanwendungen 127 der
Testeinheiten 100. Eine Kommunikation an die/von den Servlets
erfolgt in der Regel über
die Nachrichtenklasse. Der Anwendungslader bindet URLs an spezifische
Testeinheitsanwendungen 127 und kann optional anforderungsgemäß die Testeinheitsanwendungen 127 in
jeder Testeinheit 100 laden, wenn durch die Clientanwendungen 125 auf
den URL Bezug genommen wird. Die XML-Dokumentenbibliothek enthält die XML-basierten
API-Quellcodes.
-
Eine Verwendung von XML als eine
API für
Test- und Meßgeräte ermöglicht in
sich abgeschlossene, sich selbst beschreibende modulare Anwendungen,
die über
das Web bzw. Internet veröffentlicht,
lokalisiert und aufgerufen werden können. Testsoftwareanwendungen
auf der Basis der XML-API können
verschiedene Funktionen erfüllen,
die von einfachen Anforderungen bis hin zu komplizierten koordinierten
Operationen alles abdecken können.
Eine Verwendung von XML als den zugrundeliegenden Mechanismus für eine API
für Test- und
Meßgeräte löst folgende
Probleme: keinen einfachen Mechanismus zum Steuern von Test- und
Meßgeräten über das
Internet aufzuweisen; nicht in der Lage zu sein, eine breite Palette
von Testeinheitskunden oder eine breite Palette von Testsoftwareanwendungen
der Kunden, die die Testeinheiten verwenden, oder eine breite Palette
von Testeinheitsanwendungen effizient zu unterstützen (d. h. XML ermöglicht eine
leichtere Integration von Test- und Meßgeräten mit anderen existierenden
Systemen); und die Schwierigkeit beim Schreiben einer Testanwendungssoftware,
die auf andere APIs als eine Markup-Sprache-API, beispielsweise
eine XML-API, zugreift.
-
Andere Vorteile der Erfindung bestehen
darin, daß XML
eine weit verbreitete und gut dokumentierte Sprache ist, die sich
ideal zum Beschreiben von Daten eignet. Insbesondere kann XML als
Mittel zum Integrieren von verschiedenen Computersystemen, und in
diesem Fall von Test- und Meßgeräten, dienen.
Eine XML-basierte API kann eine leichte API-Versionsgebung unterstützen, da
XML-API-Dokumente unter Verwendung eines Texteditors und einer Benutzerlesbarkeit
der XML-API-Dokumente ohne weiteres verändert werden können. Beispielsweise
wird eine typische Versionsgebung durch ein Erweitern der XML-API-Sprache, wobei
neue Testeinheitsmerkmale hinzugefügt werden, unterstützt. Die
verworfenen API-Befehle können
trotzdem interpretiert werden, und es kann nach ihnen gehandelt
werden. Eine Möglichkeit,
wie XML dies möglich macht,
besteht darin, zu ermöglichen,
daß die
Struktur, die die entfernten Schnittstellenbefehle beschreibt, erweitert
wird, ohne eine verworfene Version der Struktur für ungültig zu
erklären.
Beispielsweise kann die XML-Elementstruktur für ein Login-XML-Schnittstellendokument:
einer Versionsgebung unterzogen
werden, um ein neues Feld „Titel"
zu umfassen, wie folgt:
-
Die Testeinheitsanwendungssoftware,
die dieses XML-Dokument parst (beispielsweise der XML-Dokumentparser 740),
kann jede der beiden Versionen akzeptieren, und falls kein Titel
spezifiziert ist, kann die Software wählen, besondere Maßnahmen
zu ergreifen oder nicht. Im Gegensatz zu einer Verwendung der XML-API
bestünde
bei einer bytebetriebenen Sockelschnittstelle ein Erfordernis, einen
weiteren Befehlshandhaber für
die Testeinheitsanwendungssoftware zu definieren, um dieses Problem
zu lösen
(der doppelte Softwareaufwand, um den Befehl einer Versionsgebung
zu unterziehen). Dies erhöht
die Anzahl von Befehlshandhaberimplementierungen und macht die Testeinheitsanwendungssoftware
anfällig
für zusätzliche
Programmfehler und Sicherheitslücken,
beispielsweise im Fall von Login-XML-Schnittstellendokumenten.
-
Ferner kann bei einer XML-basierten
API ohne weiteres erfolgreich eine Fehlersuche durchgeführt werden,
da man ohne weiteres bestimmen kann, ob ein Problem in der Clientanwendung 125 oder
in den API-Befehlen, die an die Testeinheitsanwendung 127 ausgegeben
wurden, vorliegt, indem man die ausgetauschten XML-Dokumente liest.
-
Falls eine Testeinheit bereits eine
native API aufweist, die ein anderer Typ als eine XML-API ist (beispielsweise
einen existierenden Befehlshandhaber für eine bytebetriebene Sockelschnittstelle),
so kann ein Übersetzungsprogramm
XML-Befehle in die nativen API-Befehle umwandeln, was eine Modifizierung
der Testeinheitssoftware überflüssig macht.
-
Obwohl die beispielhaften Ausführungsbeispiele
eine XML-API zum Steuern von Testeinheiten beschreiben, ist die
vorliegende Erfindung nicht auf eine derartige Konfiguration beschränkt. Die
vorliegende Erfindung kann erreicht werden, indem ein Schnittstellen-/Funktionsprotokoll
definiert wird, das Benutzerschnittstellenfunktionen einer Rechenvorrichtung
auf der Basis einer Markup-Sprache (kennungsbasierte Skriptsprache,
selbstdokumentierende Sprache) gleichkommt (dieselben widerspiegelt),
und indem man mit der Rechenvorrichtung über ein Netzwerk auf entfernte
Weise interagiert (dieselbe steuert/eine Kommunikation mit derselben
herstellt), indem man Schnittstellen/Funktionsprotokolldokumente
gemäß der Markup-Sprache
austauscht. Dementsprechend kann das Markup-Sprachebasierte Schnittstellen-/Funktionsprotokoll
als eine API verwendet werden, um Softwareanwendungen zu entwickeln,
die Rechenvorrichtungen fernsteuern.
-
Gemäß der vorliegenden Erfindung
kann eine Ferntestsoftware Testvorrichtungen steuern, indem sie XML-Dokumentanforderungen
bildet. In der Regel wird HTTP als das Transportmittel zum Austauschen
der XML-Dokumente mit den Testvorrichtungen verwendet. HTTP stößt auf breite
Akzeptanz im Internet, einschließlich des World Wide Web, weist
eine einfache Schnittstelle und Sicherheitsvorteile auf, indem es
eine Sicherheitssockelschicht bereitstellt. Somit werden die XML-Dokumente
in der Regel über
eine HTTP-Verbindung
an einen Server, der sich in Kommunikation mit den Testvorrichtungen
befindet, gesendet. Der Server sendet über einen Satz von Antwort-XML-Dokumenten
Daten an die Ferntestsoftware zurück. Zur Verfügung stehende
HTTP-Erweiterungen,
beispielsweise die Sicherheitssockelschicht-Paketverschlüsselung (SSL-Paketverschlüsselung),
können
für eine
Testsitzungssicherheit freigegeben werden. Ferner kann zumindest
ein XML-Dokumentaustausch einer Benutzerauthentifizierung dienen.
Ein Benutzer, der (über
die Ferntestsoftware) Tests durchführt, kann einen Benutzernamen
und ein Paßwort
bereitstellen müssen,
der bzw. das zuvor an den Testvorrichtungen konfiguriert wurde.
Ferner können
Dateitransfers unter Verwendung von HTTP und/oder FTP bewerkstelligt
werden, was es der Ferntestsoftware ermöglicht, große Datensätze wiederzuerlangen, ohne
XML zu durchlaufen, und Konfigurationsdateien auf dem Server aufzugeben.
