DE102006028311B4

DE102006028311B4 - Mehrseitige Synchronisation einer Ausführung in einer drahtlosen Testumgebung

Info

Publication number: DE102006028311B4
Application number: DE102006028311A
Authority: DE
Inventors: David E. Bingham; Carolyn Darbie; Stephen Craig Booth
Original assignee: Agilent Technologies Inc
Current assignee: Viavi Solutions Inc
Priority date: 2005-08-03
Filing date: 2006-06-20
Publication date: 2012-08-30
Anticipated expiration: 2026-06-21
Also published as: US20070032253A1; GB0613591D0; GB2428838B; DE102006028311A1; GB2428838A; US7536280B2

Abstract

Verfahren zum Synchronisieren des Flusses von dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten bei einem System mit zumindest einem Sync-Servlet zum Steuern der Synchronisation des Flusses von Daten und zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei das Verfahren folgende Schritte aufweist: (a) gleichzeitiges Initiieren von zumindest dem ersten Fluss (50) und dem zweiten Fluss (70); (b) Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70); (c) Senden, von dem Fluss, der nicht unterbrochen ist, eines Synchronisationssignals (71) zu dem Sync-Servlet (30); (d) Anfordern einer Erlaubnis, die Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30); (e) Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, nach dem Empfang des Synchronisationssignals durch das Sync-Servlet (30); und (f) Wiederaufnehmen der Ausführung des unterbrochenen Flusses.

Description

Die vorliegende Erfindung bezieht sich auf eine Vorrichtung und ein Verfahren zum Synchronisieren von Flüssen zwischen und unter mehrseitigen Tests, und insbesondere auf eine Vorrichtung und ein Verfahren zum Testen von einem oder mehreren Netzwerken und Synchronisieren der Ausführung von mehreren Flüssen bei mehrseitigen Tests.
Der Ausdruck „Testsoftware” wird verwendet, um ein Softwareprodukt zu beschreiben, dessen primäre Funktion es ist, zu untersuchen, wie ein System funktioniert. Die Testsoftware sammelt ihre Eingabe von Agenten, die individuelle Bauglieder eines Systems sind, das getestet wird.
Einige Beispiele, wo eine Testsoftware eingesetzt wird, umfassen mobile oder drahtlose Telefonnetzwerke und andere Typen von Telekommunikations-Netzwerken oder -Systemen, Flusswasserqualitätsüberwachungseinrichtungen und Automobilverhaltentestsysteme. Netzwerke oder Systeme sind häufig geographisch und/oder zeitlich verteilt. Die Testsoftware für solche Systeme muss Daten aus unterschiedlichen Orten oder zu unterschiedlichen Zeiten sammeln, um ein solches System zu testen.
Trotz der vielen Fortschritte, die auf dem Gebiet des Testens drahtloser Netzwerke gemacht wurden, bestehen weiterhin bestimmte Probleme. Diese Probleme umfassen eine Unfähigkeit, die Ausführung von Testflüssen zwischen oder unter Flüssen oder Seiten auf offene Weise zu synchronisieren, die allgemeine Standards einsetzt, eine Unfähigkeit, eine Ausführung zwischen Flüssen zu synchronisieren (oder virtuellen Teilprozessen bzw. Threads einer Ausführung), außer wenn eine proprietäre Schnittstelle verwendet wird, und eine Unfähigkeit, drahtlose Dienste zu testen, die von Ausführungsreihenfolgen zwischen Flüssen abhängen, außer eine proprietäre Schnittstelle ist in der Systemarchitektur umfasst.
Der Wireless QOS-Manager (WQM) von Agilent ist in der Lage, mehrseitige Mehr-Schritt-Tests auszuführen. Jedoch ist die SIGOS-Site-Anwendung, in der der WQM gegenwärtig integriert ist, eine proprietäre Schnittstelle. Folglich müssen Daten, die zwischen einem Fluss und einem anderen (oder von einer Seite zu einer anderen) hin- und herbewegt werden, erst durch die proprietäre SIGOS-Site-Infrastruktur fließen. Ein System, das getestet wird, das keine SIGOS-Site-Infrastruktur enthält, ermöglicht keine Synchronisation zwischen oder unter Flüssen oder Seiten.
Was erwünscht ist, ist ein drahtloser QOS-Verwalter (Wireless QOS Manager; WQM), der die Fähigkeit aufweist, eine Testausführung zwischen oder unter Seiten und/oder Flüssen (zu synchronisieren, egal ob eine SIGOS oder eine andere proprietäre Orts- bzw. Site-Infrastruktur verwendet wird oder nicht.
Die nachfolgende Veröffentlichungund Patentanmeldung, die hierin jeweils durch Bezugnahme in ihrer entsprechenden Gesamtheit aufgenommen sind, umfassen verschiedene. Lehren gemäß dem Stand der Technik im Hinblick auf WQMs:
Die US 2005/0137842 A1 mit dem Titel „Sequential Coordination of Test Execution and Dynamic Data” an Bingham.
Wie Fachleute auf dem Gebiet erkennen werden, nachdem sie die vorliegende Zusammenfassung, Figuren, detaillierte Beschreibung und Ansprüche gelesen haben, kann zumindest ein Teil der Vorrichtungen, Systeme und Verfahren, die in der vorangehenden Veröffentlichung und Patentanmeldung offenbart sind, vorteilhaft gemäß den Lehren der vorliegenden Erfindung modifiziert werden.
Die EP 0 872 085 B1 beschreibt ein Verfahren der gegenseitigen Synchronisation eines Datenflusses aus Zellen mit unterschiedlichen Anzahlen von Datenbits. Bei aufeinanderfolgenden Kommunikationsvorgängen wird durch die aufeinanderfolgende Reihenfolge der Initiierung der Datenflüsse die Möglichkeit einer Synchronisation geschaffen. Zuerst geht ein Schaltungskern in den ”Sync”-Zustand und dann wird eine Sync-Zelle an ein Umschalttor gesendet, welches durch Senden von Sync-Zellen antwortet. Zu Beginn des Synchronisationsprozesses sind beide Seiten in einem nichtsynchronisierten Zustand, und die Datenflüsse von dem Schalttor und von dem Schaltkern werden angehalten oder unterbrochen, bis irgendeiner dieser Flüsse eine Synchronisation versucht.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Synchronisieren des Flusses von dynamisch erzeugten Daten, einen Testagenten zum entfernten Synchronisieren des Flusses aus dynamisch erzeugten Daten und ein Verfahren zum Herstellen eines Testagenten mit verbesserten Charakteristika zu schaffen.
Diese Aufgabe wird durch ein Verfahren zum Synchronisieren gemäß Anspruch 1, ein System zum Synchronisieren gemäß Anspruch 19, einen Testagenten gemäß Anspruch 22 und ein Verfahren zum Herstellen eines Testagenten gemäß Anspruch 25 gelöst.
Verfahren, Vorrichtungen und Systeme zum Synchronisieren der Ausführung von mehrseitigen Tests zwischen oder unter mehrseitigen Testkomponenten in einer Kommunikations- oder Test-Umgebung, wie z. B. einer drahtlosen Telekommunikationsumgebung, sind offenbart. Mehrere Flüsse in einem System, wie z. B. einer drahtlosen Testkonfiguration, werden gleichzeitig initiiert. Eine Ausführung wird dann bei zumindest einem der Flüsse unterbrochen. Von dem Fluss, der nicht unterbrochen wird, wird ein Synchronisationssignal zu einem Sync-Servlet gesendet. Der unterbrochene Fluss fordert eine Erlaubnis von dem Sync-Servlet, den Fluss fortzusetzen. Der unterbrochene Fluss wird fortgesetzt, nachdem ein Synchronisationssignal von dem Sync-Servlet empfangen wird.
Die vorliegende Erfindung umfasst innerhalb ihres Schutzbereichs die Verfahren zum Synchronisieren, die oben, hierin nachfolgend und in den Figuren beschrieben sind, sowie Systeme und Testagenten, die in der Lage sind, solche Verfahren auszuführen.
Verschiedene Ausführungsbeispiele der vorliegenden Erfindung können durch einen oder mehrere der nachfolgenden Aspekte gekennzeichnet sein:

(a) Synchronisation zwischen oder unter mehreren Flüssen bei einem Drahtloser-Dienst-Test ist erlaubt, sogar wenn eine proprietäre Schnittstelle nicht bei dem System eingesetzt wird, das getestet wird;
(b) Ein Sync-Servlet erlaubt, dass ein Fluss die Ausführung unterbricht (await sync; Sync abwarten), während er auf eine Fortsetzen-Meldung von einem anderen Fluss wartet (send sync; Sync senden), wodurch erlaubt wird, dass drahtlose Dienste getestet werden, die eine solche Funktionalität benötigen;
(c) Ein Sync-Servlet erlaubt die Steuerung der Ausführung zwischen oder unter Flüssen (oder virtuellen Teilprozessen der Ausführung);
(d) Ein offener, allgemeiner Standard oder eine Datenübertragung, wie z. B. HTTP, HTTPS, FTP kann eingesetzt werden, um die Synchronisation einer Testausführung zwischen oder unter mehreren Flüssen und/oder zwischen mehreren Drittparteianwendungen zu bewirken;
(e) Daten können sicher unter Verwendung eines HTTPS-Protokolls übertragen werden;
(f) Zeitbegrenzungen können nach Bedarf konfiguriert werden;
(g) Der Ort eines Sync-Servlets kann verändert werden, was nützlich für Konfigurationen mit Firewalls ist;
(h) Sync-Servlets können auf jeglichem Wireless-QOS-Agenten oder auf jeglichem Web-Server betrieben werden, der Servlets unterstützt;
(i) Wenn ein Synchronisationsereignis eine konfigurierbare Zeit überlebt hat, wird es automatisch gelöscht.

Die vorangehenden und andere Aspekte und Vorteile von verschiedenen Ausführungsbeispielen der vorliegenden Erfindung werden offensichtlich und besser verständlich, nachdem die detaillierte Beschreibung der bevorzugten Ausführungsbeispiele, die Zeichnungen und Ansprüche gelesen und verstanden wurde.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein Ausführungsbeispiel der vorliegenden Erfindung;
2 ein anderes Ausführungsbeispiel der vorliegenden Erfindung; und
3 ein wiederum anderes Ausführungsbeispiel der vorliegenden Erfindung.
1 zeigt ein Ausführungsbeispiel der vorliegenden Erfindung, bei dem Flüsse A und B bei einem mehrseitigen Testsystem unter Verwendung von Sync-Servlets 20, 30 bzw. 40 synchronisiert sind, die in der aktiven Testsonde 50, die Fluss A entspricht, der aktiven Teststeuerung 60 bzw. der aktiven Testsonde 70, die Fluss B entspricht, angeordnet sind.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist jede der aktiven Testsonde 50, der aktiven Teststeuerung 60 und der aktiven Testsonde 70 ein individueller Agent in dem System 10, obwohl andere Konfigurationen möglich sind und in den Schutzbereich der vorliegenden Erfindung fallen. Es wird darauf hingewiesen, dass Sync-Servlets 20 und 40 in 1 nicht bei dem nachfolgend gegebenen Beispiel eingesetzt, aber bei anderen Konfigurationen oder Flüssen eingesetzt werden können, die hierin nicht ausdrücklich offenbart sind. Abhängig von der vorliegenden Systemkonfiguration kann der entsprechende Zielort für ein bestimmtes Signal oder eine Meldung, wie z. B. ein Signal „Await Sync” (Sync abwarten) oder „Send Sync” (Sync senden) spezifiziert werden müssen oder nicht, obwohl bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ein solcher Zielort spezifiziert sein muss, wie bei dem Schema angezeigt ist, das nachfolgend ausgeführt wird. Zum Beispiel kann das „Send Sync”-Signal, das von Fluss B (Flow B) in 1 ausgeht, derart spezifiziert sein, dass es einen letztendlichen Zielort in Fluss B hat, und dass „Await Sync”-Signal, das aus Fluss A (Flow A) stammt, kann spezifiziert sein, dass es einen letztendlichen Zielort in dem Sync-Serviet 30 hat.
In 1 ist Fluss A durch Testkomponente 1, Testkomponente 2 („Await Sync”) und Testkomponente 3 in der aktiven Testsonde 50 dargestellt. Fluss B ist dargestellt durch Testkomponente 1, Testkomponente 2 („Send Sync”) und Testkomponente 3 in der aktiven Testsonde 70. Ein erster und zweiter Fluss A und B werden im Wesentlichen gleichzeitig initiiert. Die Ausführung von Fluss A wird unterbrochen, nachdem Fluss A zu der zweiten Testkomponente oder dem Ereignis „Await Sync” fortgeschritten ist. Eine Ausführung der Testkomponente „Await Sync” in Fluss A verursacht, dass eine Meldung oder Anweisung zu dem Sync-Servlet 30 gesendet oder abgeschickt wird, die angibt, dass Fluss A auf den Empfang eines „Send Sync”-Signals oder einer -Meldung von Fluss B wartet. Der Zeitbetrag, den die Testkomponente „Await Sync” in Fluss A auf den Empfang eines „ Send Sync”-Signals wartet, kann eine konfigurierbare Zeitbegrenzung sein. Wenn Fluss B zu der Testkomponente „Send Sync” fortgeschritten ist, wird ein „Send Sync”-Signal zu dem Sync-Servlet 30 abgeschickt. Das nächste mal, wenn Fluss A eine Erlaubnis anfordert, die Ausführung wieder aufzunehmen (d. h. „wurde ein „Send Sync”-Signal von Fluss B empfangen?”), wurde das „Send Sync”-Signal bereits von dem Sync-Servlet 30 empfangen, und Fluss A empfängt eine Erlaubnis, die Ausführung durch Ausführen des nächsten Schrittes wieder aufzunehmen (d. h. jetzt tritt die Ausführung von Testkomponente 3 auf).
Ausschließlich als darstellendes Beispiel und ohne Absicht, den Schutzbereich der vorliegenden Erfindung einzuschränken, kann FlowA:test1 (Flow = Fluss) in 1 ein Test sein, der zu einer Webseite navigiert und Authentifizierungsinformationen zum Einloggen in ein 802.11 wifi-Netzwerk anfordert und die Rechnungs- und Login-Informationen zu einem Zellulartelefonkonto senden lässt. FlowB:test1 empfängt dann die Bestätigungsmeldung auf den Zellulartelefon mit dem Benutzernamen und Passwort. FlowA:test3 verwendet als Nächstes den Benutzernamen und das Passwort, um sich in dem wifi-Netzwerk zu registrieren. FlowA:test3 kann sich nicht einloggen (bzw. registrieren) bevor FlowB:test1 ordnungsgemäße Authentifizierungsinformationen empfangen hat. FlowA:await sync verursacht, dass eine Ausführung unterbrochen wird, bis FlowB:send sync gesendet wurde, wobei an diesem Funkt die Ausführung fortgesetzt wird. Wie nun erkannt wird, können send sync und await sync-Funktionalitäten in mehreren Flüssen implementiert sein, um zu ermöglichen, dass kompliziertere, mehrseitige und Mehrfluss-Netzwerke oder -Systeme getestet werden.
Es wird darauf hingewiesen, dass das Ausführungsbeispiel der vorliegenden Erfindung, das in 1 gezeigt ist, speziell angepasst ist für eine Verwendung bei einer drahtlosen Diensttesteinstellung, wie z. B. einer wifi-Login-Anwendung bzw. -Registrier-Anwendung, obwohl zahlreiche andere Anwendungen denkbar sind und trotzdem in den Schutzbereich der vorliegenden Erfindung fallen.
Weiterhin Bezug nehmend auf 1 kann jedes der Sync-Servlets 20, 30 und 40 ein Programm mit mehreren Teilprozessen sein, das auf jeglichem der Agenten 50, 60 und 70 in dem System 10 läuft. Jeder Agent sollte eine Sync-Servlet-Funktionalität besitzen, obwohl eine solche Funktionalität nicht im Hinblick auf ein gegebenes Servlet gemäß einer bestimmten Systemkonfiguration verwendet werden kann. Zum Beispiel kann eine solche Sync-Servlet-Funktionalität auf Agenten 60 und 70 und nicht 50 ausgeübt werden, während weiterhin erlaubt wird, dass die oben beschriebenen Testprozeduren auftreten. Bei einer optimalen Systemkonfiguration jedoch besitzt jeder Agent eine Dynamischer-Inhalt-Servlet-Funktionalität.
Tests können durch einen Anrufer aufgerufen werden, der entfernt von jeglichem der Agenten des Systems 10 ist, wenn der Anrufer mit einem Netzwerk verbunden ist, mit dem solche Agenten verbunden sind, oder mit dem einer solcher Agenten verbunden ist. Ein solches Netzwerk kann jegliches Netzwerk sein, wie z. B. das Internet. Bei einem Ausführungsbeispiel der vorliegenden Erfindung können die Agenten 50, 60 und 70 Computer und/oder Server sein.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird eine Dynamischer-Inhalt-Servlet-Funktionalität zu einem Syc-Servlet hinzugefügt. Während sich eine Dynamischer-Inhalt-Servlet-Funktionalität von der eines Sync-Servlets unterscheidet, kann eine Dynamischer-Inhalt-Servlet-Funktionalität allgemein auf ein Sync-Servlet im Huckepackverfahren aufgenommen werden, um das Betreiben mehrerer Servlets zu vermeiden, wie in 1 gezeigt ist.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung können Testbeschreibungen oder Anforderungen zum Synchronisieren in ein vordefiniertes XML-Schema (oder sogar Klartext) entweder in einer HTTP-Post oder einer HTTPS-Post eingelagert sein. HTTP (Hyper Text Transfer Protocol) ist ein generischer Meldungstransportstandard oder eine standardisierte Weise, über das Internet zu kommunizieren. Ein HTTP-Get (Get = Erhalten), ist das, was ein Web-Browser ausführt; er empfängt Daten nur. Aber eine HTTP-Post (Post = abschicken) ermöglicht das Senden eines Datenkörpers und auch den Empfang einer Antwort.
Der Datenkörper, der durch eine HTTP-Post gesendet wird, ist über das XML-Schema organisiert. XML (Extensible Markup Language; erweiterbare Markup-Sprache) ist eine standardisierte Möglichkeit zum Codieren von Daten, oder anders ausgedrückt zum Generisieren der Daten, Freigeben einer Definition, Übertragung, Validierung und Interpretation der Daten zwischen Anwendungen.
Schnittstellenentwurfsdetails, die ein Ausführungsbeispiel der Erfindung implementiert, das in 1 dargestellt ist, werden nachfolgend in Beispiel 1 aufgeführt, wo Textdarstellungen eines Sync-Servlet-Eingangsschemas gezeigt sind. Während die Sync-Servlet-Implementierung, die hierin nachfolgend ausgeführt wird, in Java geschrieben ist, kann eine solche Funktionalität in jeder geeigneten Programmiersprache implementiert sein oder unter jeglichem Web-Server laufen, der Servlets unterstützt. Andere auf Standards basierende Server und Protokolle können ebenfalls verwendet werden, um Sync-Servlets zu implementieren. Sync-Servlets können HTTP-Posts mit einem definierten XML-codierten Körper akzeptieren, nur um Daten einzugeben oder zu erhalten. Durch Verwenden einer solchen Funktionalität kann ein Sync-Objekt, das in jedem Test enthalten ist, der in einem gegebenen Fluss läuft, dann Daten abschicken oder Daten von dem Sync-Servlet erhalten. Das Sync-Servlet kann abgeschickt werden, um HTTP oder HTTPS (secure socket layer; Sicherheitssockelschicht) zu verwenden, um eine Sicherheit zu gewährleisten.
Beispiel 1: Wqm-Sync-Servlet-Schnittstellenentwurf
(A) Eingabe- und Ausgabe-Schnittstelle zu dem Sync-/Dynamischer-Inhalt-Servlet
(1) Kurze Beschreibung
Das Dynamische-Daten-Servlet läuft auf jeglichem QoSM-WQM-Agenten. Es liefert einen Datenspeicher für dynamische Daten zum Betreiben von Tests und verarbeitet Anforderungen zum „Hinzufügen (add)”, „Entfernen (remove)” oder „Erhalten (get)” dynamischer Daten für eine spezifizierte Uniqueid (eindeutige ID), oder zum „Löschen (delete)” aller Daten für diese Uniqueid.
(2) Vorraussetzungen, die sich auf einen Dynamische-Daten-Entwurf beziehen

– Die nachfolgenden Attribute finden sich in dem Abschnitt Drahtlos (Wireless) von fh.conf. Sie können überschrieben werden durch verdeckte (Präfix fh) Attribute in dem Wireless Chain Text (Drahtlos-Kette-Test) selbst.
–
– (Zeichenfolge) Voreinstellung ist dieselbe wie das Attribut Host (ATC).
–
– (ganze Zahl) Voreinstellung ist 16716
–
– (ganze Zahl) Voreinstellung 0 (einmal Nachsehen, kein Warten)
–
– (Boolscher Wert) Voreinstellung wahr (prüfe DCS, wenn nicht in lokalem Speicher)
– Das Nachfolgende muss in den Flussebenendatenspeichern verfügbar sein:
– DcsLocation
– DcsPort
– DcsTimeout
– DcsLookup
– ChaindId – (Zeichenfolge) eine eindeutige ID für diese Testausführung
– FlowId – (Zeichenfolge) der Name des aktuellen Flusses
– Eine DcsControl-Testkomponente ist verfügbar, um die Werte der Dcs*-Attribute zu ändern, die oben beschrieben sind.
– Die DcsPurgeTime-Eingabe in den Drahtlos-Abschnitt von fh.conf definiert das Alter, bei dem alte Daten im DCS (in Stunden) abgeführt werden sollen.

(3) Technische Anforderungen

– Fähigkeit zum Betreiben eines Servlets auf dem QOSM-Agenten.
– Definierte XML-Schnittstelle für die HTTP-Anforderungen und -Antwort.

(4) Definition oder Entwurfsbeschreibung

– Die Schnittstelle zum Servlet ist eine HTTP-Post.
– Beispiel url!http://<DcsLocation>:<
>/
– Der Körper der Post ist XML. Die XML-Schnittstelle ist hierin definiert.
– Das Verhalten des DCS imitiert eine Hash-Tabelle:
– Es ist nicht legal, einen Null-Schlüssel oder -Wert zu speichern, eine NullPointerException (Null-Zeiger-Ausnahme) resultiert.
– Ein „put” (Setzen) bringt den vorangehend gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde)
– Ein „get” (Erhalten) bringt den gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde)
– Ein „remove” (Entfernen) bringt den vorangehend gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde)
– Ein „delete” (Löschen) entfernt alle Daten für einen eindeutige Id und bringt alle vorangehend gespeicherten Werte zurück.
– Das DCS weist ein spezielles Verhalten auf, wenn ein „Sync”-Datum bzw. eine gegebene Größe gespeichert ist.
– Der Name des Sync-Datums ist „dcs_sync<fromFlow>:<toFlow>”
– Der Wert, der für ein Sync-Typ-Datum gespeichert ist, ist eine ganze Zahl.
– Wenn bereits ein Wert für dieses Datum existiert, wird er um ein weiteres „put” inkrementiert.
– Der Wert für dieses Datum wird um ein „get” dekrementiert, wenn der resultierende Wert 0 ist, wird das Datum entfernt.
– Das Abführen alter Daten, die nicht ordnungsgemäß am Ende einer Testausführung entfernt wurden, wird ausgeführt.
– Der Wert DcsPurgeTime (DCS-Abführzeit), der in fh.conf enthalten ist, wird als das Alter verwendet, um alte Testdaten zu löschen, mit einer Voreinstellung von 24 Stunden.
– Die Frequenz des Prüfens zum Abführen von alten Daten basiert auf dem Alterungswert (1/10tel des Werts).

(5) SITE-Abhängigkeiten (Site = Ort)
– TDL-Code, der das
aufrufen, auf die Antwort warten und die Ausgabe akzeptieren kann.
(6) Erzeugen und Parsen der XML in Tcl und Java

– Beschreibung:
– Lernkurve beim Parsen von XML
– Auflösung/Fortschritt:
– Erlernen des Dokumentobjektmodells in jdk1.4.1 zum Parsen von XML
– Verwenden von Prozeduren, die bereits in Tdl zum Handhaben von XML vorhanden sind.

(7) Aufbauen der ausgehenden XML in Java

– Beschreibung:
– Lernkurve beim Parsen von XML
– Auflösung/Fortschritt:
– Erlernen des Dokumentobjektmodells in jdk1.4.1 zum Parsen von XML

Voraussetzungen

– Die gesendete XML muss in der korrekten Form sein oder wird nicht validiert.

Technische Anforderungen

– Die Schnittstelle ist eine HTTP-Post, die einen XML-Körper als Eingabe zu dem Servlet enthält.
– Die Ausgabe ist die Post-Antwort, ebenfalls im XML-Format.

(B) Definition oder Entwurfsbeschreibung
SQM-(Firehunter-)Abhängigkeiten

– Keine

SITE-Abhängigkeiten

– Fähigkeit zum Ausführen einer HTTP-Post an dem Servlet mit dem korrekten XML-Körper.
– Fähigkeit zum Empfangen der Post-Antwort-XML.

Die Sync-Servlet-Schemata, die oben ausgeführt und in den Figuren dargestellt sind, sind nur Beispiele. Die vorliegende Erfindung ist nicht auf solche Schemata beschränkt; Andere Schemata können verwendet werden und fallen trotzdem in den Schutzbereich der vorliegenden Erfindung; vorausgesetzt jedoch, dass entsprechende Änderungen an den Sync-Servlets und ihren entsprechenden Testkomponenten ausgeführt werden. Ferner sind Schemata der vorliegenden Erfindung nicht auf XML beschränkt; Andere Markup-(„Etiket ten”-)Sprachen oder sogar Klartext und ihre entsprechenden Testkomponenten können ebenfalls eingesetzt werden.
2 zeigt ein anderes Ausführungsbeispiel der vorliegenden Erfindung, wo drei Flüsse A, B und C gleichzeitig ablaufend initiiert werden. Jeder Fluss betreibt seine erste Testkomponente. Wenn Fluss A die Testkomponente „Await Sync” betreibt, wird verursacht, dass Fluss A die Ausführung unterbricht, bis ein Signal oder eine Meldung „Send Sync” über das Sync-Servlet 30 von Fluss B empfangen wird. Der Zeitbetrag, den die Testkomponente „Await Sync” in Fluss A auf einen Empfang des Signals „Send Sync” wartet, kann eine konfigurierbare Zeitbegrenzung sein. Wenn Fluss B zu der Testkomponente „Send Sync” fortgeschritten ist, wird ein Signal „Send Sync” zu dem Sync-Servlet 30 abgeschickt. Das nächste Mal, wenn Fluss A eine Erlaubnis anfordert die Ausführung wieder aufzunehmen (d. h. „Wurde ein Signal „Send Sync” von Fluss B empfangen?”), wurde das Signal „Send Sync” bereits von dem Sync-Servlet 30 empfangen und Fluss A empfängt eine Erlaubnis, die Ausführung durch Betreiben des nächsten Schrittes wieder aufzunehmen (d. h. Ausführung von Testkomponente 3 tritt nun auf). Wenn Fluss C seine Testkomponente „Send Sync” erreicht, wird ein Signal oder eine Meldung „Send Sync” zu Fluss B über das Sync-Servlet 30 gesendet. Sobald das Signal oder die Meldung „Send Sync”, die aus Fluss C stammt, von der Testkomponente „Await Sync” bei Fluss B empfangen wird, nimmt Fluss B die Ausführung zu der Testkomponente 4 wieder auf.
3 zeigt ein anderes Ausführungsbeispiel der vorliegenden Erfindung, wo die Firewall 100 zwischen der aktiven Teststeuerung 60 und Flüssen A, B und C angeordnet ist. Flüsse A, B und C werden gleichzeitig ablaufend initiiert. Jeder Fluss betreibt seine erste Testkomponente. Da die Firewall 100 zwischen der aktiven Teststeuerung 60 und den aktiven Testsonden 50, 70 und 80 angeordnet ist, kann das Sync-Servlet 30 vielleicht nicht verwendet werden. Trotzdem kann bei dem Ausführungsbeispiel der vorliegenden Erfindung, das in 3 gezeigt ist, auf jegliches Sync-Servlet durch jegliche der aktiven Testsonden 50, 70 oder 80 zugegriffen werden, wodurch das System 10 betriebsfähig gemacht wird. In 3 wird das Sync-Servlet 20 der aktiven Testsonde 50 eingesetzt, um eine solche Funktion zu erfüllen.
Wenn Fluss A zu der Testkomponente „Await Sync” fortgeschritten ist, wird die Ausführung von Fluss A unterbrochen, während auf den Empfang eines Signals oder einer Meldung „Send Sync” von Fluss B gewartet wird. Wenn Fluss B die zweite Testkomponente „Send Sync” zu einer späteren Zeit erreicht, wird ein Signal oder eine Meldung „Send Sync” zu dem Sync-Servlet 20 von Fluss B abgeschickt. Die Testkomponente „Await Sync” in Fluss A empfängt das Signal „Send Sync” von Fluss B über das Sync-Servlet 20, das die Wiederaufnahme von Fluss A auslöst. Fluss B setzt die Ausführung des Tests „Await Sync” fort und wird unterbrochen, während er auf einen Empfang eines Signals oder einer Meldung „Send Sync” von Fluss C wartet. Wenn Fluss C seine Testkomponente „Send Sync” erreicht, wird ein Signal oder eine Meldung „Send Sync” zu Fluss B über das Sync-Servlet 20 gesendet. Sobald das Signal oder die Meldung „Send Sync”, das aus Fluss C stammt, durch die Testkomponente „Await Sync” in Fluss B empfangen wird, nimmt Fluss B die Ausführung zu der Testkomponente 4 wieder auf.
Verschiedene Protokolle werden hierin beschrieben, wie z. B. HTTP und HTTPS. Die vorliegende Erfindung ist nicht auf solche Protokolle beschränkt und erachtet explizit die Verwendung anderer Protokolle, wie z. B. FTP („File Transfer Protokoll”), SCP („Secure Copy Protocol”) und SFTP („Secure File Transfer Protocol”). Auf ähnliche Weise werden hierin verschiedene Netzwerke beschrieben, wie z. B. ein LAN, ein drahtloses Netzwerk, ein Drahtleitungsnetzwerk und das Internet. Die vorliegende Erfindung ist nicht auf solche Netzwerke beschränkt; andere Netzwerke können eingesetzt werden, und fallen in den Schutzbereich der vorliegenden Erfindung.
Die vorliegende Erfindung kann erfolgreich über einen breiten Bereich von drahtlosen Netzwerktypen und Standards eingesetzt werden, der folgendes umfasst, aber nicht beschränkt ist auf wifi 802.11a wifi 802.11b, wifi 802,11g wimax, GSM/GPRS und CDMA, sowie andere Standards, die noch erfunden oder implementiert werden. Ferner ist die vorliegende Erfindung in ihrem Schutzbereich nicht auf drahtlose Testanwendungen beschränkt und umfasst innerhalb ihres Schutzbereichs Drahtleitungstestanwendungen, wie z. B. Ethernet/LAN- und Einwahl-Netzwerke.
Bei einem bevorzugten Ausführungsbeispiel werden die Synchronisationsverfahren der vorliegenden Erfindung ausgeführt unter Verwendung eines Agilent-QoS-Verwalter-Agenten (QoS = „Quality of Service”), wobei viele Aspekte desselben beschrieben sind unter: http://we.home.agilent.com/cgibin/bvpub/agilent/Product/cp Product.jsp?OID=536882909&NAV ID=-536885380.536882909.00&LANGUAGE CODE=eng&COUNTRY CODE=-ZZ&CT=PRODUCT&JPID=/comms/firehunter.
Es wird darauf hingewiesen, dass bestimmte Aspekte und Anwendungen von verschiedenen Ausführungsbeispielen der vorliegenden Erfindung bei den Vorrichtungen, Systemen und Verfahren eingesetzt werden können, die offenbart sind in der U.S.-Patenanmeldung Seriennummer 10/736,835 mit dem Titel „Sequential Coordination of Test Execution and Dynamic Data” an Bingham, die hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen ist.
Obwohl einige Ausführungsbeispiele der vorliegenden Erfindung gezeigt und beschrieben wurden, werden Fachleute auf dem Gebiet erkennen, dass Änderungen an solchen Ausführungsbeispielen ausgeführt werden können, ohne von dem Schutzbereich und dem Wesen der Erfindung abzuweichen, deren Schutzbereich in den beiliegenden Ansprüchen und ihren Entsprechungen definiert ist. Zum Beispiel fällt ein System oder Agent, der ein oder mehrere Synchronisationsverfahren der vorliegenden Erfindung mit Hilfe von einem oder mehreren Stellvertretern ausführt, in den Schutzbereich der vorliegenden Erfindung.

Claims

Verfahren zum Synchronisieren des Flusses von dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten bei einem System mit zumindest einem Sync-Servlet zum Steuern der Synchronisation des Flusses von Daten und zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei das Verfahren folgende Schritte aufweist: (a) gleichzeitiges Initiieren von zumindest dem ersten Fluss (50) und dem zweiten Fluss (70); (b) Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70); (c) Senden, von dem Fluss, der nicht unterbrochen ist, eines Synchronisationssignals (71) zu dem Sync-Servlet (30); (d) Anfordern einer Erlaubnis, die Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30); (e) Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, nach dem Empfang des Synchronisationssignals durch das Sync-Servlet (30); und (f) Wiederaufnehmen der Ausführung des unterbrochenen Flusses.
Verfahren gemäß Anspruch 1, bei dem das System ein drahtloses System ist.
Verfahren gemäß Anspruch 1 oder 2, das ferner aufweist, das System einer Mehrzahl von Funktionstest zu unterziehen.
Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem das System keine proprietäre Schnittstelle umfasst.
Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das Sync-Servlet (30) ein Signal „Await Sync” von dem unterbrochenen Fluss empfängt.
Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem das Synchronisationssignal, das von dem Sync-Servlet (30) empfangen wird, ein Signal „Send Sync” ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem ein offener, allgemeiner Kommunikationsstandard für eine Datenübertragung eingesetzt wird, um die Synchronisation von Flüssen zu bewirken.
Verfahren gemäß Anspruch 7, bei dem der offene, allgemeine Kommunikationsstandard aus der Gruppe ausgewählt ist, die aus HTTP, HTTPS, FTP, SCP und SFTP besteht.
Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem Schemata, die aus der Gruppe ausgewählt sind, die aus XML, einer Markup-Sprache und Klartext besteht, eingesetzt werden, um eine Synchronisation von Flüssen zu bewirken.
Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem eine Zeitbegrenzung für den unterbrochenen Fluss konfiguriert wird.
Verfahren gemäß Anspruch 10, bei dem eine Stelle des Sync-Servlets (30) spezifiziert wird.
Verfahren gemäß Anspruch 11, bei dem die Stelle des Sync-Servlets (30) verändert wird.
Verfahren gemäß einem der Ansprüche 1 bis 12, bei dem das Sync-Servlet (30) auf einem drahtlose QOS-Agenten betrieben wird.
Verfahren gemäß einem der Ansprüche 1 bis 13, bei dem das Sync-Servlet (30) auf einem Web-Server betrieben wird.
Verfahren gemäß einem der Ansprüche 1 bis 14, bei dem das Synchronisationssignal gelöscht oder entfernt wird, nachdem ein vorbestimmter Zeitbetrag abgelaufen ist.
Verfahren gemäß einem der Ansprüche 1 bis 15, bei dem das Sync-Servlet (30) konfiguriert ist, um zumindest eines aus einer HTTP-Post, einer HTTPS-Post, einer. FTP-Post und einer SCP-Post und einer SFTP-Post zu akzeptieren.
Verfahren gemäß einem der Ansprüche 1 bis 16, bei dem das Sync-Servlet (30) eine XML-codierte Post akzeptiert, um die Daten einzugeben oder zu erhalten.
Verfahren gemäß einem der Ansprüche 1 bis 17, bei dem das Sync-Servlet (30) ferner eine Dynamische-Daten-Inhalt-Funktionalität aufweist.
System zum Synchronisieren des Flusses aus dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten mit zumindest einem Sync-Servlet (30) zum Steuern der Synchronisation des Flusses von Daten und zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei das System folgende Merkmale aufweist: (a) eine Einrichtung zum gleichzeitigen Initiieren von zumindest dem ersten Fluss (50) und dem zweiten Fluss (70); (b) eine Einrichtung zum Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70); (c) eine Einrichtung zum Senden eines Synchronisationssignals zu dem Sync-Servlet (30) von dem Fluss, der nicht unterbrochen ist; (d) eine Einrichtung zum Anfordern einer Erlaubnis, um die Ausführung wiederaufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30); (e) eine Einrichtung zum Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, auf einen Empfang des Synchronisationssignals durch das Sync-Servlet (30) hin, und (f) eine Einrichtung zum Wiederaufnehmen der Ausführung des unterbrochenen Flusses.
System gemäß Anspruch 19, wobei das System konfiguriert ist, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
System gemäß Anspruch 19 oder 20, wobei das System konfiguriert ist, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.
Testagent zum entfernten Synchronisieren des Flusses aus dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten mit zumindest einem Sync-Servlet (30) zum Steuern der Synchronisation des Flusses von Daten und zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei der Testagent folgende Merkmale aufweist: (a) eine Einrichtung zum Verursachen, dass zumindest der erste Fluss (50) und der zweite Fluss (70) gleichzeitig initiiert werden; (b) eine Einrichtung zum Verursachen, dass eine Ausführung von zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70) unterbrochen wird; (c) eine Einrichtung zum Verursachen, dass ein Synchronisationssignal von dem nicht unterbrochenen Fluss zu dem Sync-Servlet (30) gesendet wird; (d) eine Einrichtung zum Verursachen, dass eine Erlaubnis, eine Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30) angefordert wird; (e) eine Einrichtung zum Verursachen, dass dem unterbrochenen Fluss eine Erlaubnis zum Wiederaufnehmen der Ausführung erteilt wird, auf den Empfang des Synchronisationssignals von dem Sync-Servlet (30) hin; und (f) eine Einrichtung zum Verursachen, dass die Ausführung des unterbrochenen Flusses wieder aufgenommen wird.
Testagent gemäß Anspruch 22, wobei der Testagent konfiguriert ist, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
Testagent gemäß Anspruch 22 oder 23, wobei der Testagent konfiguriert ist, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.
Verfahren zum Herstellen eines Testagenten zum Synchronisieren des Flusses aus dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten mit zumindest einem Sync-Serviet (30) zum Steuern der Synchronisation des Flusses von Daten und zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei das Verfahren folgende Schritte aufweist: (a) Bereitstellen einer Einrichtung zum Verursachen, dass zumindest der erste Fluss (50) und der zweite Fluss (70) gleichzeitig initiiert werden; (b) Bereitstellen einer Einrichtung zum Verursachen, dass eine Ausführung von zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70) unterbrochen wird; (c) Bereitstellen einer Einrichtung zum Verursachen, dass ein Synchronisationssignal von dem nicht unterbrochenen Fluss zu dem Sync-Serviet (30) gesendet wird; (d) Bereitstellen einer Einrichtung zum Verursachen, dass eine Erlaubnis, eine Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30) angefordert wird; (e) Bereitstellen einer Einrichtung zum Verursachen, dass dem unterbrochenen Fluss eine Erlaubnis zum Wiederaufnehmen der Ausführung erteilt wird, auf den Empfang des Synchronisations-Signals von dem Sync-Servlet (30) hin; (f) Bereitstellen einer Einrichtung zum Verursachen, dass die Ausführung des unterbrochenen Flusses wieder aufgenommen wird; (g) wirksames Anordnen und Verbinden der vorangehenden Einrichtungen zum Erzeugen des Testagenten.
Verfahren gemäß Anspruch 25, bei dem der Testagent konfiguriert ist, um den Fluss aus dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten entfernt zu synchronisieren.
Verfahren gemäß Anspruch 25 oder 26, bei dem der Testagent konfiguriert wird, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
Verfahren gemäß einem der Ansprüche 25 bis 27, bei dem der Testagent konfiguriert wird, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.