DE69908349T2 - Verteilte datenverarbeitung, die client- und server-objekte verwendet - Google Patents

Verteilte datenverarbeitung, die client- und server-objekte verwendet Download PDF

Info

Publication number
DE69908349T2
DE69908349T2 DE69908349T DE69908349T DE69908349T2 DE 69908349 T2 DE69908349 T2 DE 69908349T2 DE 69908349 T DE69908349 T DE 69908349T DE 69908349 T DE69908349 T DE 69908349T DE 69908349 T2 DE69908349 T2 DE 69908349T2
Authority
DE
Germany
Prior art keywords
server
location
client
proxy
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69908349T
Other languages
English (en)
Other versions
DE69908349D1 (de
Inventor
Anne Caroline Ipswich LEBRE
John Richard Ipswich TITMUS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of DE69908349D1 publication Critical patent/DE69908349D1/de
Application granted granted Critical
Publication of DE69908349T2 publication Critical patent/DE69908349T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/541Client-server

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)

Description

  • Gebiet der Erfindung
  • Diese Erfindung bezieht sich auf ein Verfahren zum Verarbeiten von Daten in einer verteilten Rechenumgebung.
  • Hintergrund
  • Eine Datenverarbeitung kann in einer verteilten Rechenumgebung ausgeführt werden, in der Client-Software mit Server-Software, die in einem Netz verbunden sind, interagiert. Ein Server kann als ein Betriebsmittel aufweisend betrachtend werden, das von mehreren Clients gemeinsam benutzt wird, die daran Interesse haben. Der Server wartet auf vom Client initiierte Anfragen und antwortet auf diese individuell mit Informationen, die aus dem vom Client abgefragten Betriebsmittel hergeleitet werden.
  • Gewöhnlich ist die Client-Software bei festen Arbeitsstationen angeordnet, die im Netz angeschlossen sind und mit Servern an festen Orten interagieren. Vor kurzem wurde eine mobile Agentensoftware entwickelt, die der Client-Software erlaubt, sich zu einem Ort in der Nähe eines Servers zu bewegen, um eine bessere Nutzung der Einrichtungen des Servers zu erreichen. Wenn z. B. ein verarbeitendes Unternehmen Fabriken an zwei verschiedenen Orten besitzt, die ihre eigenen lokalen Computernetze aufweisen, kann ein Operator am ersten Ort wünschen, Datenbanken von Servern an beiden Orten abzufragen, um z. B. die Verfügbarkeit bestimmter Lagergegenstände zu ermitteln, die in den Lagerhäusern an den zwei Orten gehalten werden können. In dieser Situation ist es für die Client-Datenabfragesoftware günstig, sich vom ersten Ort zum zweiten Ort zu verlagern, um näher am Server am zweiten Ort zu sein, um eine effiziente Abfrage der zugehörigen Datenbanken zu ermöglichen. Die mobile Client-Software ist als mobiler Agent bekannt.
  • Es wurden mehrere verschiedene Systeme entwickelt, die mobile Agenten zur Verfügung stellen: MuBot von Crystaliz, Inc.; Agent Tcl von Dartmouth College; Aglets von IBM; MOA von der Open Group, Inc.; GMAF/Magna von GMD Fokus; und Odyssey von General Magic Inc.
  • In "Agent-Based Configuration Management of Distributed Applications", Berghoff u. a., Proceedings of the third international conference on Configurable Distributed Systems (Annapolis USA, 6.-8. Mai 1996), S. 52–59, wird das Konfigurationsmanagement von verteilten Anwendungen beschrieben. Genauer wird die Eignung mobiler Agenten in einem solchen Konfigurationsmanagement beschrieben und behandelt. Ein Beispiel für Konfigurationsmanagement, das keine mobilen Agenten verwendet, ist als Hintergrund angegeben. In diesem Beispiel wird angenommen, daß eine Funktionseinheit M in jeder Komponente eines Satzes von unterteilten Server-Komponenten ausgetauscht werden muß. Um dies mit einer minimalen Störung der laufenden Anwendung zu bewerkstelligen, werden die unterteilten Server-Komponenten der Reihe nach weiter betrieben. Die folgenden Schritte werden ausgeführt, um die Einheit M in der ersten der unterteilten Server-Komponenten A auszutauschen.
    • – Anweisen des Vermittlers (der ankommende Anfragen zwischen Servern verteilt, um einen Lastausgleich zu erreichen), keine weiteren Anfragen an die Server-Komponente A weiterzuleiten.
    • – Anweisen der Server-Komponente A, ankommende Anfragen zu rückzuweisen.
    • – Überwachen des aktuellen Verkehrs auf der Server-Komponente A.
    • – Entscheiden, zu welchem Zeitpunkt die Server-Komponente ausgetauscht wird, in Abhängigkeit vom aktuellen Verkehr.
    • – Wenn der Zeitpunkt gekommen ist, Aussetzen aller aktuellen Bindungen zur Server-Komponente A durch Passivieren der entsprechenden Schnittstellen auf der Client-Seite.
    • – Nachdem die Aktivitäten der Server-Komponente A gestoppt worden sind (aufgrund der Passivierung der Client-Schnittstellen), wird die Einheit M ausgetauscht.
    • – Wiederherstellen der Bindungen zur Server-Komponente A durch Aktivieren der entsprechenden Client-Schnittstellen.
    • – Anweisen der Server-Komponente A, ankommende Anfragen anzunehmen.
    • – Anweisen des Vermittlers, daß zukünftige Anfragen an die Server-Komponente A weitergeleitet werden können.
  • Das Papier beschreibt eine Management-Architektur, die auf einer globalen Management-Komponente (GMC) beruht, die mit den Anwendungskomponenten interagiert, um Managementoperationen durchzuführen. Diese zentralisierte Architektur gilt als nachteilig, wenn sie auf große und komplexe verteilte Anwendungen angewendet wird. Alle Nachrichten, die Management-Interaktionen betreffen, müssen von einer GMC behandelt werden. Der resultierende Verkehr tendiert dazu, die Management-Komponenten zu überlasten, und führt zu schlechten Antwortzeiten. Wenn die Anwendung über einen weiten Bereich verteilt ist, kann der Kommunikationsaufwand dramatisch anwachsen. Um diese Beschränkungen zu beseitigen, haben Berghoff u. a. ein dezentralisiertes Managementsystem untersucht, das unterteilte globale Management-Komponenten verwendet. Es hat sich jedoch herausgestellt, daß dieses System aufgrund des Synchronisationsaufwands zwischen den dezentralisierten Management-Komponenten immer noch an geringer Skalierbarkeit leidet.
  • Als Alternative schlagen Berghoff u. a. eine Infrastruktur für mobile Agenten vor. Berghoff u. a. erläutern, daß der Vorteil von mobilen Agenten im Vergleich zu herkömmlichen Lösungsansätzen zur verteilten Berechnung hauptsächlich in der Effizienz liegt. Viele Operationen erfordern einen langwierigen Dialog oder das Verschieben beträchtlicher Datenmengen. Wenn dies unter Verwendung herkömmlicher Mittel über ein Netz bewerkstelligt wird, kann dies zu einer erhöhten Netzbelastung und zu einem Leistungsverlust aufgrund der Latenzzeit und eines Mangels an Bandbreite führen. Mobile Agenten tragen dazu bei, die Notwendigkeit einer Netzkommunikation zu reduzieren, indem der Code, der die Interaktion handhabt, näher an die Datenquelle bewegt wird. Berghoff u. a. heben hervor, daß in einer Umgebung, die mobile Agenten unterstützt, nicht jeder Agent mobil sein muß – tatsächlich spielen stationäre Agenten eine wichtige Rolle, indem sie als Mittler oder Proxies zwischen der "Agentenwelt" und der normalen Betriebsumgebung auf einem Host arbeiten.
  • Sie haben eine Prototyp-Agenten-Infrastruktur implementiert, um Experimente auf dem Gebiet mobiler Agenten zu unterstützen. Dies bildet die Grundlage einer Ausführungsumgebung für mobile und stationäre Agenten. Die Agenten-Infrastruktur umfaßt einen Agenten-Server, der sich mit den Einzelheiten des Akzeptierens von Agenten, die laufen sollen, des Konstruierens einer geeigneten Laufzeitumgebung und des Einführens und Entfernens des Agenten der Reihe nach befaßt. Agenten müssen ferner miteinander und mit anderen Programmen kommunizieren. Die Prototyp-Agenten-Infrastruktur unterstützt dies über den Gedanken eines Informationsraums, den Agenten zum gemeinsamen Nutzen von Daten und zum Einleiten und Beantworten von Anfragen benutzen können. Dies war eine Einrichtung auf niedriger Ebene, die im allgemeinen ausreichte, um eine Vielfalt von Interaktionsarten zu erlauben, sowohl deklarative als auch RPC-ähnliche. Anschließend haben sie eine Erweiterung des bestehenden zentralisierten Managementsystems mit den folgenden Hauptanforderungen entwickelt. Anwendungskomponenten sollten nicht modifiziert werden müssen, um durch Agenten verwaltbar zu sein. Bestehende Management-Anwendungskomponenten sollten wiederverwendbar sein. Es sollte möglich sein, von einem rein zentralisierten Managementsystem zu einem solchen auf Agentenbasis inkrementell fortzuschreiten. Um den Übergang zu erleichtern und Betriebsmittelbeschränkungen des Netzes des Hosts zu berücksichtigen, sollte die Agenten-Infrastruktur nicht auf jedem Host vorhanden sein müssen, auf dem die verteilte Anwendung läuft. Die bestehende Management-Architektur wurde auf einem Host mit mobilen Agenten integriert, indem spezialisierte Agenten eingeführt wurden, die als Vermittler zwischen mobilen Agenten und dem Managementsystem arbeiteten. Diese Agenten waren stationär, d. h. sie wurden bestimmten Hosts zugewiesen, von denen sie sich nicht wegbewegten. Sie kommunizierten mit mobilen Agenten über den Informationsraum und führten Management-Anfragen an Anwendungskomponenten aus. Berghoff u. a. schließen ihr Papier, indem sie die Hauptvorteile ihres Lösungsansatzes für das Konfigurationsmanagement auf Agentenbasis identifizieren: Erhöhte Flexibilität, da mobile Agenten Code führen können, um die Funktionalität stationärer Agenten, Anwendungs- und Managementkomponenten zu erweitern oder zu ersetzen. Eine neue Managementfunktionalität oder Protokolle werden in einer einfachen Weise eingeführt.
  • Erhöhte Zuverlässigkeit, da mobile Agenten autonom in einem vorübergehend abgetrennten Teil des Netzes arbeiten können.
  • Erhöhte Leistungsfähigkeit und reduzierter Netzverkehr in großen Anwendungen, da sich die Agenten zu dem Bereich bewegen, in dem die Managementoperationen ausgeführt werden müssen. Während der Verarbeitung seiner Management-Aufgabe ist die Latenzzeit eines Management-Aufrufs (die nun Kurzstreckenaufrufe sind) verringert, wobei die Gesamtlatenzzeit ebenfalls abnimmt. Die Zwischeninformationen, die zum Erfüllen der Management-Aufgabe erforderlich sind, werden lokal verarbeitet und müssen nicht weit zu einer GMC übermittelt werden. Somit nimmt die Gesamtbelastung des GMC deutlich ab.
  • Berghoff u. a. schlagen nirgendwo vor, daß die mobilen Agenten eine Server-Funktionalität aufweisen sollen, noch daß es möglich ist oder in irgendeiner Weise wünschenswert wäre. Es wird nicht gelehrt, mobile Server vorzusehen.
  • Zusammenfassung der Erfindung
  • Gemäß der Erfindung wird angenommen, daß es Situationen gibt, in denen es vorteilhaft wäre, den Server innerhalb einer verteilten Rechenumgebung mobil zu machen.
  • Gemäß der Erfindung wird ein Verfahren zum Verarbeiten von Daten in einer verteilten Rechenumgebung geschaffen, in der ein Client und ein Server Daten verarbeiten, wobei das Verfahren das Senden des Servers von einem ersten Ort, an dem er mit dem Client kommuniziert, über die verteilte Rechenumgebung zu einem zweiten anderen Ort, damit er von hier eine Datenverarbeitung ausführt, umfaßt.
  • Das Verfahren kann das Einfrieren ankommender Aufrufe für eine Datenverarbeitung beim Server an dem ersten Ort, während er von dem ersten Ort zu dem zweiten Ort gesendet wird, und danach das Leiten der eingefrorenen Aufrufe zu dem zweiten Ort, damit sie durch den Server verarbeitet werden, wenn er an dem zweiten Ort arbeitsfähig geworden ist, umfassen. Dies hat den Vorteil, daß sichergestellt wird, daß Verbindungen für den Server nicht verloren gehen, während er sich vom ersten Ort zum zweiten Ort bewegt.
  • In einem weiteren Aspekt enthält die Erfindung das Aufnehmen des vom ersten Ort gesendeten Servers, um eine Datenverarbeitung am zweiten Ort durchzuführen.
  • Um den Server vom ersten Ort zum zweiten Ort zu senden, kann er von einer Arbeitskonfiguration am ersten Ort in eine Konfiguration umgewandelt werden, die für die Übertragung durch die verteilte Umgebung zu dem zweiten Ort geeignet ist. Die Umwandlung kann die Serialisierung des Servers umfassen.
  • Die Erfindung umfaßt ferner eine Software-Entität, die so betreibbar ist, daß sie einen Server für einen Client in einer verteilten Rechenumgebung bereitstellt, dadurch gekennzeichnet, daß die Software-Entität über die Umgebung wahlweise zu verschiedenen Orten verschoben werden kann.
  • In einem weiteren Aspekt umfaßt die Erfindung ein Signal für die Übertragung in einer verteilten Rechenumgebung, in der ein Client und ein Server Daten verarbeiten, wobei das Signal den Server umfaßt, der für die Übertragung über die verteilte Rechenumgebung zwischen einem ersten Ort, wo er mit dem Client kommuniziert, und einem zweiten anderen Ort serialisiert wird und eine Datenverarbeitung ausführt.
  • Die Übertragung des Servers vom ersten Ort zum zweiten Ort kann von einem Proxy kontrolliert werden, genauer umfaßt die Erfindung einen Proxy für die Verwendung in einer verteilten Rechenumgebung, in der ein Client und ein Server Daten verarbeiten, wobei der Proxy so betreibbar ist, daß er den Server von einem ersten Ort, wo er mit dem Client kommuniziert, über die verteilte Rechenumgebung zu einem zweiten anderen Ort sendet, damit er eine Datenverarbeitung ausführt.
  • Kurzbeschreibung der Zeichnungen
  • Damit die Erfindung vollständiger verstanden werden kann, wird im folgenden eine ihrer Ausführungsformen beispielhaft mit Bezug auf die beigefügten Zeichnungen beschrieben, in welchen:
  • 1 ein schematisches Blockschaltbild einer verteilten Rechenumgebung ist, die mobile Softwareagenten verwendet;
  • 2 ein genaueres Diagramm eines der in 1 gezeigten Hosts ist;
  • 3 schematisch die Bewegung eines mobilen Servers von einem ersten Ort zu einem zweiten Ort gemäß der Erfindung zeigt; und
  • 4 ein schematisches Zeitablaufdiagramm der Signalkommunikation zwischen dem ersten Ort und dem zweiten Ort bezüglich der Bewegung des Servers ist.
  • Genaue Beschreibung
  • In der folgenden Beschreibung wurde zur bequemen Erläuterung die Terminologie angewendet, die von der Object Management Group (OMG) für mobile Agenten angewendet wird. Die OMG hat einen gemeinsamen Standard für die Interoperabilität von Objekten zwischen verschiedenen Systemen unter einer gemeinsamen Objekt-Management-Architektur definiert, die ein Objektanfragevermittler, der im Handel als CORBA bekannt ist, bereitstellt, welcher eine Infrastruktur bietet, die Objekten erlaubt, unabhängig von den spezifischen Plattformen und Techniken, die zum Implementieren der Objekte verwendet werden, zu kommunizieren. Um die Interoperabilität mobiler Agenten zu bewältigen, hat die OMG ein Dokument "Mobile Agent Facility Specification", 1. September 1997, OMG TC Document orbos/97-09-20, erhältlich von der Object Management Group, 492 Old Conneticut Path, Framingham, MA 01707, USA, angefertigt. Die vollständige Spezifikation ist auch über die Internet- Seite von OMG (dessen URL www.omg.org ist) der Öffentlichkeit zugänglich. Dies wird im folgenden mit Bezug auf die 1 und 2 erläutert.
  • Für mobile Softwareagenten, die Clients sind, besteht die Welt aus Regionen, die Orte enthalten, zwischen denen sich der mobile Agent bewegen kann. Wie in 1 gezeigt ist, sind erste und zweite Host-Rechensysteme 1, 2 über ein Netz 3 verbunden. Die ersten und zweiten Host-Systeme können irgendeiner geeigneten Form entsprechen, wie z. B. lokalen Netzen, einzelnen Computern und dergleichen, die mit ihrem eigenen Betriebssystem OS1, OS2 arbeiten können. In herkömmlicher Weise können die einzelnen Hosts 1, 2 einen oder mehrere Computer oder Prozessoren enthalten, die jeweils einen Prozessor, einen flüchtigen Arbeitsspeicher und einen nichtflüchtigen Datenspeicher enthalten. Jeder Host ist mit einer Kommunikationsschnittstelle CI1, CI2 versehen, um eine Kommunikation zwischen diesen über das Netz 3 zu ermöglichen. Das Netz 3 kann irgendeiner geeigneten Form entsprechen, z. B. einem Weitverkehrsnetz, einem lokalen Netz, einem Intranet oder dem Internet.
  • Das Betriebssystem OS1 des Host 1 bietet eine Umgebung, in der Software arbeiten kann. Die Client-Software ist als mobiler Softwareagent MA1 konfiguriert. In ähnlicher Weise weist der Host 2 ein Betriebssystem OS2 und einen mobilen Agent MA2 auf. Ein weiterer mobiler Agent MAn ist im Host 1 gezeigt. Jeder mobile Agent MA ist an einem Ort P betriebsfähig. Bei Betrachtung des Host 1 ist somit der mobile Agent MA1 am Ort P1 betriebsfähig, während der mobile Agent MAn an einem Ort Pn betriebsfähig ist. Der mobile Agent MA2 befindet sich am Ort P2 im Host 2. Die mobilen Agenten können sich von Ort zu Ort bewegen. Es ist klar, daß im Host 1 die Orte P indivi duelle Computer sein können, die in einem Netz verbunden sind, das den Host 1 oder irgendeine andere geeignete Hardwarekonfiguration umfaßt, die hier nicht genauer beschrieben wird. Das gleiche gilt für den Host 2. Die OMG-Mobilagenten-Spezifikation ist so ausgelegt, daß sie eine Interoperabilität zwischen verschiedenen Betriebssystemen schafft, um den Transport von mobilen Client-Agenten von einem Host zu einem weiteren zu erlauben. In der Konfiguration der 1 wird angenommen, daß verschiedene Betriebssysteme OS1, OS2 in Gebrauch sind, obwohl dies kein wesentliches Merkmal der Erfindung ist. Es wird angenommen, daß die OMG-Spezifikation CORBA nutzt, um eine Interoperabilität zwischen verschiedenen Hardware- und Software-Konfigurationen zu erlauben. Die Agenten, die innerhalb des Betriebssystems OS1 arbeiten, definieren ein Agentensystem AS1 im Host 1. Ein ähnliches Agentensystem AS2 arbeitet in dem in 1 gezeigten Host 2.
  • Der Softwareprozeß ist in einer Client-Server-Konfiguration angeordnet, wie im folgenden mit Bezug auf 2 erläutert wird. Günstigerweise, jedoch nicht notwendigerweise, kann die Software objektorientiert sein, so daß die mobilen Client-Agenten und die Server jeweils als Objekte betrachtet werden können. Wie in 1 gezeigt ist, ist die Server-Software MS1 am Ort P1 gezeigt, der Aufrufe von mobilen Klienten bedienen kann, wie mit Bezug auf 1 beschrieben worden ist. Zum Beispiel ist der mobile Agent MA1 ein Client am Ort P1 und kann Datenaufrufe an den Server MS1 über den Pfad 4 stellen, um eine Datenverarbeitung auszuführen. Der Client und der Server müssen jedoch nicht am gleichen Ort P angeordnet sein. Im Beispiel der 2 kann somit der Server MS1 Datenaufrufe vom mobilen Client-Agenten MA2 am Ort 2 über den Kommunikationspfad 5 bedienen. Es ist klar, daß mehr als ein Server MS in der verteilten Rechenumgebung vorhanden sein kann.
  • Gemäß der Erfindung ist der Server MS1 innerhalb der verteilten Rechenumgebung mobil. Um die Mobilität des mobilen Servers MS1 zu managen, ist ihm ein Software-Proxy pr1 zugeordnet, der an jedem Ort P verschieden ist. Der Proxy pr1 wird dem CORBA mit der mobilen Server-Schnittstelle angezeigt, anstelle des mobilen Servers selbst. Alle Verarbeitungsaufrufe für den Server gehen zuerst an den Proxy und werden anschließend von diesem zum Server umgeleitet. Daher weiß der Proxy pr1 zu jedem Zeitpunkt, wie viele Clients mit dem Server MS1 verbunden sind, und wie viele Aufrufe durchgeführt werden.
  • Wie in 3 gezeigt ist, gibt es Situationen, in denen es günstig wäre, den Server-Agenten MS1 vom Ort P1 über die Kommunikationsschnittstelle CI1, das Netz 3 und die Schnittstelle CI2 zum Ort P2 zu bewegen. Zum Beispiel könnte der Server MS1 dann mit verbesserter Operabilität mit dem Client MA2 arbeiten, der sich im Agentensystem AS2 im Host 2 befindet. Die Übertragung des Servers MS1 vom Ort P1 zum Ort P2 wird im folgenden mit Bezug auf 4 genauer beschrieben.
  • Anfangs, wenn der mobile Server MS1 entscheidet oder angewiesen wird, sich vom Ort P1 wegzubewegen, teilt er im Schritt S.0 seinem Proxy pr1 den Ort mit, zu dem er bewegt werden soll. In diesem Fall soll der mobile Server MS1 zum Ort P2 bewegt werden. Alternativ kann der Proxy pr1 von einer bestimmten externen, dritten Partei angewiesen werden, den mobilen Server zu bewegen. Der Bewegungsprozeß beginnt anschließend.
  • Im Schritt S.1 friert der Proxy pr1 alle ankommenden Aufrufe zur Datenverarbeitung an den mobilen Server MS1 ein.
  • Im Schritt S.2 wartet der Proxy pr1, bis alle aktuellen Datenverarbeitungen, die vom mobilen Server MS1 gehandhabt werden, beendet sind.
  • Anschließend teilt im Schritt S.3 der Proxy pr1 dem mobilen Server MS1 mit, daß er bewegt werden soll und daß er irgendeine Aufgabe ausführen muß, die abgeschlossen sein muß, bevor er den Ort P1 verläßt.
  • Anschließend veranlaßt der Proxy im Schritt S.4, daß der mobile Server MS1 serialisiert wird, d. h. er wird von seinem Betriebszustand in einen Zustand umgewandelt, der für die Übertragung über das Netz 3 geeignet ist (1).
  • Anschließend wird im Schritt S.5 der serialisierte mobile Server über die Kommunikationsschnittstelle CI1, das Netz 3 und die Kommunikationsschnittstelle CI2 zum Ort P2 des Host 2 gesendet.
  • Im Schritt S.6 wird ein neuer Proxy pr1' im Ort P2 für den mobilen Server MS 1 erzeugt, wenn er sich am Ort p2 befindet.
  • Im Schritt S.7 wird der mobile Server MS1 am Ort P2 deserialisiert, wodurch er in einen Betriebszustand zurückversetzt wird.
  • Im Schritt S.8 sendet der neu erzeugte Proxy pr1' lokale Referenzdaten für den mobilen Server MS1 zurück, um somit dem Proxy pr1 die neue CORBA-Referenz des mobilen Servers MS1 anzuzeigen.
  • Anschließend werden im Schritt S.9 die im Schritt S.1 eingefrorenen Aufrufe zum mobilen Server MS1 über das Netz 3 mittels des Proxy pr1 vom Ort P1 zum Ort P2 weitergeleitet.
  • Die mit Bezug auf 4 beschriebene Prozedur hat den Vorteil, daß eine Kommunikation mit dem mobilen Server MS1 während des Übertragungsprozesses nicht verloren geht. Die Schritte stellen sicher, daß jede Datenverarbeitung, die am Ort P1 ausgeführt wird, abgeschlossen wird, bevor die Übertragung stattfindet, und daß, während die Übertragung stattfindet, ankommende Aufrufe eingefroren werden und anschließend zum neuen Ort übertragen werden.
  • Clients können den bewegten mobilen Server MS1 finden, indem sie eine geeignete Anfrage stellen, wie für jedes andere CORBA-Objekt, und die Referenz seines Proxy empfangen. Der Proxy, der für den mobilen Agenten angezeigt wird, kann entweder der erste Proxy pr1 sein, wobei in diesem Fall Aufrufe vom pr1 zu pr1' geleitet werden, oder der Proxy pr1' selbst.
  • Bei Abschluß des Bewegungsprozesses für den mobilen Server ist der Proxy pr1 nicht mehr erforderlich und wird gelöscht.
  • Es ist klar, daß Client-Agenten, wie z. B. der am Ort P1 in 3 gezeigte Agent MA2, in herkömmlicher Weise mobil sein können, entsprechend der OMG-Spezifikation für mobile Agenten. Somit kann der Client-Agent MA2 in herkömmlicher Weise durch Serialisieren des Agenten, Übertragen desselben über das Netz 3 zu einem anderen Ort und Deserialisieren des Agenten am neuen Ort bewegt werden. Somit ist es gemäß der Erfindung möglich, eine gesamte Client- Server-Kombination von einem Ort zu einem weiteren oder verschiedenen Orten zu bewegen.
  • Es ist klar, daß der mobile Server MS1, wenn er sich an einem bestimmten Ort befindet, sich im Arbeitsspeicher eines bestimmten Computers innerhalb des Host befindet und bei Bedarf im nichtflüchtigen Speicher des dem Ort P zugeordneten Computers gespeichert werden kann, um eine Aufzeichnung desselben zu schaffen, wenn das Netz oder ein Teil desselben heruntergefahren wird. Der mobile Server kann ferner auf einem Speichermedium wie z. B. einer optischen oder magnetischen Platte zur Verfügung stehen, so daß er an einem bestimmten Ort P in einen Computer geladen werden kann und anschließend seine mobilen Aktivitäten im Netz aufnimmt.
  • Während die vorher beschriebenen Clients und Server in geeigneter Weise als Softwareobjekte in einer objektorientierten Umgebung konfiguriert sein können, ist dies nicht wesentlich, wobei sie als Stapel von herkömmlichem Code konfiguriert sein können. Während die Erfindung ferner mit Bezug auf eine CORBA-Objekt-Managementarchitektur beschrieben worden ist, können andere Management-Architekturen verwendet werden, wie z. B. OLE von Microsoft, die geeignet konfiguriert sind, um mobile Objekte zu behandeln.
  • Die Bewegung des Servers gemäß der Erfindung macht den Rechenprozeß viel flexibler. Wenn z. B. in einer Internet-Anwendung eine große Anzahl von Clients im Vereinigten Königreich einen Server aufruft, der sich an einem Ort in den USA befindet, müßte eine große Anzahl von Transatlantik-Aufrufen gemacht werden, was unwirtschaftlich ist. Gemäß der Erfindung kann das Server-Objekt von einem Ort in den USA zu einem Ort im Vereinigten Königreich verla gert werden, wodurch die Ausführung der individuellen Client/Server-Prozesse beschleunigt wird.

Claims (28)

  1. Verfahren zum Verarbeiten von Daten in einer verteilten Rechenumgebung, in der ein Client (MA1) und ein Server (MS1) Daten verarbeiten, dadurch gekennzeichnet, daß das Verfahren das Senden des Servers (MS1) von einem ersten Ort (P1), an dem er mit dem Client (MA1) kommuniziert, über die verteilte Rechenumgebung zu einem zweiten, anderen Ort (P2), damit er von hier eine Datenverarbeitung ausführt, umfaßt.
  2. Verfahren nach Anspruch 1, das das Einfrieren ankommender Aufrufe für eine Datenverarbeitung beim Server (MS1) an dem ersten Ort (P1), während er von dem ersten Ort (P1) zu dem zweiten Ort (P2) gesendet wird, und danach das Leiten der eingefrorenen Aufrufe zu dem zweiten Ort (P2), damit sie durch den Server (MS1) verarbeitet werden, wenn er an dem zweiten Ort (P2) arbeitsfähig geworden ist, umfaßt.
  3. Verfahren nach Anspruch 2, das das Warten auf den Server (MS1) umfaßt, damit er seine momentanen Verarbeitungsaufgaben abschließt, bevor er zu dem zweiten Ort (P2) gesendet wird.
  4. Verfahren nach einem vorhergehenden Anspruch, das das Umwandeln des Servers (MS1) von einer Arbeitskonfiguration am ersten Ort (P1) in eine Konfiguration, die für die Übertragung durch die verteilte Umgebung zu dem zweiten Ort (P2) geeignet ist, umfaßt.
  5. Verfahren nach Anspruch 4, bei dem die Umwandlung die Serialisierung des Servers (MS1) umfaßt.
  6. Verfahren nach einem vorhergehenden Anspruch, das das Erzeugen eines Proxy (pr1) für den Server (MS1) an dem ersten Ort (P1), der das Senden des Servers (MS1) zu dem zweiten Ort (P2) steuert, umfaßt.
  7. Verfahren nach einem vorhergehenden Anspruch, das das Senden des Client (MA1) an einen anderen Ort in der verteilten Rechenumgebung umfaßt.
  8. Verfahren zum Verarbeiten von Daten in einer verteilten Rechenumgebung, bei dem ein Client (MA1) und ein Server (MS1) Daten verarbeiten, dadurch gekennzeichnet, daß das Verfahren das Empfangen des Servers (MS1), der von einem ersten Ort (P1), wo er mit dem Client (MA1) kommuniziert, über die verteilte Rechenumgebung gesendet wird, an einem zweiten, anderen Ort (P2) umfaßt, damit er an dem zweiten Ort (P2) eine Datenverarbeitung ausführt.
  9. Verfahren nach Anspruch 8, bei dem der Server (MS1) an dem zweiten Ort (P2) in einer Form empfangen wird, die für die Übertragung über die verteilte Umgebung geeignet ist, und das das Umwandeln des empfangenen Servers (MS1) an dem zweiten Ort (P2) in eine Form, die für die Verarbeitung von Daten an dem zweiten Ort (P2) geeignet ist, umfaßt.
  10. Verfahren nach Anspruch 9, bei dem die Umwandlung die Deserialisierung des Servers (MS1) umfaßt.
  11. Verfahren nach Anspruch 8, 9 oder 10, das das Erzeugen eines Proxy (pr1') für den empfangenen Server (MS1) an dem zweiten Ort (P2) umfaßt.
  12. Verfahren nach einem der Ansprüche 8 bis 11, das das Empfangen von von dem ersten Ort (P1) zum zweiten Ort (P2) geleiteten Datenverarbeitungsaufrufen für den Server (MS1), nachdem der Server (MS1) an dem zweiten Ort (P2) arbeitsfähig geworden ist, umfaßt.
  13. Software-Entität, die so betreibbar ist, daß sie einen Server (MS1) für einen Client (MA1) in einer verteilten Rechenumgebung bereitstellt, dadurch gekennzeichnet, daß die Software-Entität über die Umgebung wahlweise zu verschiedenen Orten verschoben werden kann.
  14. Entität nach Anspruch 13, die so betreibbar ist, daß sie als der Server (MS1) an einem ersten Ort (P1) in der Umgebung arbeitet und dann verschoben wird und als der Server (MS1) an dem zweiten Ort (P2) in der Umgebung arbeitet.
  15. Entität nach Anspruch 13 oder 14, die so betreibbar ist, daß Datenaufrufe an sie von einem Client (MA1) während der Verschiebung eingefroren werden.
  16. Entität nach einem der Ansprüche 13 bis 15, die so betreibbar ist, daß sie einen Proxy (pr1) bereitstellt, der so arbeitet, daß er den Server (MS1) über die Umgebung sendet, um die Verschiebung zu erzielen.
  17. Entität nach Anspruch 16, bei der der Proxy (pr1) so arbeitet, daß er auf den Server (MS1) wartet, damit er seine momentanen Verarbeitungsaufgaben abschließt, bevor die Verschiebung begonnen wird.
  18. Entität nach Anspruch 16 oder 17, bei der der Proxy (pr1) so betreibbar ist, daß er den Server (MS1) aus seiner Arbeitskonfiguration in eine Konfiguration serialisiert, die für die Übertragung über die verteilte Umgebung geeignet ist, um so die Verschiebung zu erzielen.
  19. Software-Entität nach einem der Ansprüche 13 bis 18, die in einem Speichermedium gespeichert ist.
  20. Signal für die Übertragung in einer verteilten Rechenumgebung, in der ein Client (MA1) und ein Server (MS1) Daten verarbeiten, dadurch gekennzeichnet, daß das Signal den Server (MS1) umfaßt, der für die Übertragung über die verteilte Rechenumgebung zwischen einem ersten Ort (P1), wo er mit dem Client (MA1) kommuniziert, und einem zweiten, anderen Ort (P2) serialisiert wird und eine Datenverarbeitung ausführt.
  21. Proxy (pr1) für die Verwendung in einer verteilten Rechenumgebung, in der ein Client (MA1) und ein Server (MS1) Daten verarbeiten, dadurch gekennzeichnet, daß der Proxy (pr1) so betreibbar ist, daß er den Server (MS1) von einem ersten Ort (P1), wo er mit dem Client (MA1) kommuniziert, über die verteilte Rechenumgebung zu einem zweiten, anderen Ort (P2) sendet, damit er eine Datenverarbeitung ausführt.
  22. Proxy (pr1) nach Anspruch 21, der so betreibbar ist, daß er ankommende Datenverarbeitungsaufrufe für den Server (MS1) an dem ersten Ort (P1) einfriert, während dieser von dem ersten Ort (P1) zu dem zweiten Ort (P2) gesendet wird, und danach die eingefrorenen Aufrufe zu dem zweiten Ort (P2) leitet, damit sie von dem Server (MS1) verarbeitet werden, wenn er an dem zweiten Ort (P2) arbeitsfähig geworden ist.
  23. Proxy (pr1) nach Anspruch 21 oder 22, der so betreibbar ist, daß er auf den Server (MS1) wartet, damit dieser seine momentanen Verarbeitungsaufgaben abschließen kann, bevor er ihn zu dem zweiten Ort (P2) sendet.
  24. Proxy (pr1) nach Anspruch 21, 22 oder 23, der so betreibbar ist, daß er den Server (MS1) aus einer Arbeitskonfiguration an dem ersten Ort (P1) in eine Konfiguration serialisiert, die für die Übertragung über die verteilte Umgebung zu den zweiten Ort (P2) geeignet ist.
  25. Host (1 oder 2), der mit Client-Objekten (MA1) und Server-Objekten (MS1) für die Verarbeitung von Daten in einer objektorientierten verteilten Verarbeitungsumgebung versehen ist, dadurch gekennzeichnet, daß das Server-Objekt (MS1) wahlweise an andere Orte in der Umgebung verschiebbar ist.
  26. Host (1 oder 2) nach Anspruch 25, bei dem das mobile Server-Objekt (MS1) so betreibbar ist, daß Datenaufrufe für das Server-Objekt (MS1) während der Verschiebung eingefroren werden.
  27. Host (1 oder 2) nach Anspruch 25, bei dem der Server (MS1) mit einem Proxy (pr1) versehen ist, der mit einer CORBA- oder OLE-Architektur kompatibel ist.
  28. Server-Objekt (MS1) für die Verarbeitung von Daten in einer objektorientierten verteilten Verarbeitungsumgebung, dadurch gekennzeichnet, daß das Server-Objekt (MS1) für eine Operation an unterschiedlichen Orten verschiebbar ist und im Betrieb mit einem Proxy (pr1) versehen ist, der Datenaufrufe für das Server-Objekt (MS1) während der Verschiebung einfriert und anschließend diese Datenaufrufe zu dem bewegten Server-Objekt (MS1) weiterleitet.
DE69908349T 1998-05-01 1999-04-27 Verteilte datenverarbeitung, die client- und server-objekte verwendet Expired - Fee Related DE69908349T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB9809512A GB9809512D0 (en) 1998-05-01 1998-05-01 Distributed data processing
GB9809512 1998-05-01
PCT/GB1999/001302 WO1999057637A1 (en) 1998-05-01 1999-04-27 Distributed data processing

Publications (2)

Publication Number Publication Date
DE69908349D1 DE69908349D1 (de) 2003-07-03
DE69908349T2 true DE69908349T2 (de) 2004-04-01

Family

ID=10831431

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69908349T Expired - Fee Related DE69908349T2 (de) 1998-05-01 1999-04-27 Verteilte datenverarbeitung, die client- und server-objekte verwendet

Country Status (7)

Country Link
EP (1) EP1076851B1 (de)
JP (1) JP2002513965A (de)
AU (1) AU753572B2 (de)
CA (1) CA2330596A1 (de)
DE (1) DE69908349T2 (de)
GB (1) GB9809512D0 (de)
WO (1) WO1999057637A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8065399B2 (en) 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US8898340B2 (en) 2000-04-17 2014-11-25 Circadence Corporation Dynamic network link acceleration for network including wireless communication devices
US20020002602A1 (en) 2000-04-17 2002-01-03 Mark Vange System and method for serving a web site from multiple servers
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US8195823B2 (en) 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
JP2002345006A (ja) * 2001-04-23 2002-11-29 Motorola Inc 情報処理を代行する方法、プログラムおよび装置
WO2002093834A1 (en) * 2001-05-14 2002-11-21 Telefonaktiebolaget Lm Ericson (Publ) Unique identifier provisioning

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5838909A (en) * 1996-05-23 1998-11-17 Sandcastle, Inc. Reducing latency when synchronizing access to a multi-user database over a network

Also Published As

Publication number Publication date
AU753572B2 (en) 2002-10-24
AU3718999A (en) 1999-11-23
CA2330596A1 (en) 1999-11-11
DE69908349D1 (de) 2003-07-03
EP1076851B1 (de) 2003-05-28
WO1999057637A1 (en) 1999-11-11
EP1076851A1 (de) 2001-02-21
JP2002513965A (ja) 2002-05-14
GB9809512D0 (en) 1998-07-01

Similar Documents

Publication Publication Date Title
DE69724877T2 (de) Verfahren und Vorrichtung zum Betrieb einer Aggregation von Serverrechnern mittels eines Doppelzweck-Proxy-Servers
DE69719620T2 (de) Vorrichtung und Verfahren zur Bestimmung von Server-Cluster-Topologien
DE69429686T2 (de) Transaktionsverwaltung in objektorientiertem System
DE69228621T2 (de) Objektorientiertes verteiltes Rechnersystem
EP0825524B1 (de) Verfahren zur Verwaltung der Benennung von Objekten
DE69814900T2 (de) Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software
DE69424597T2 (de) Erweiterbares Dateiensystem
DE69226858T2 (de) Kommunikationssystem
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
DE69327448T2 (de) Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
DE69322887T2 (de) Datenverarbeitung und Betriebssystem mit dynamischer Belastungsteilung in einem Netzwerk von verknüpften Prozessoren
DE69329577T2 (de) Verfahren und system für implementierung-unabhängige schnittstellenspezifikation
DE60302876T2 (de) Master-knotenauswahl in geclusterten knotenkonfigurationen
DE69523939T2 (de) Verfahren zur erzeugung von objektstrukturen für den zugriff auf konventionelle, nicht objekt-orientierte geschäftsanwendungen
DE69824879T2 (de) Verteilter web- anwendungs- server
DE3852324T2 (de) Verfahren und System zur Netzwerkverwaltung.
DE69734432T2 (de) Verfahren und Vorrichtung zur Absendung von Clientverfahrenanrufen in einem Server Rechnersystem
DE68919631T2 (de) Verfahren zur Verarbeitung von Programmteilen eines verteilten Anwendungsprogramms durch einen Hauptrechner und einen intelligenten Arbeitsplatz in einer SNA LU 6.2-Netzwerkumgebung.
DE69624579T2 (de) System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten
DE69637436T2 (de) Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen
DE69425093T2 (de) Verfahren zum Erzeugen einer Gruppe erweiterbarer Zusatzdienste für Objekte in einem objektoriertierten System
EP0825527B1 (de) Verfahren zur Unterstützung der Adress-Interaktion zwischen einer ersten und einer zweiten Einheit
DE69908349T2 (de) Verteilte datenverarbeitung, die client- und server-objekte verwendet
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE60122671T2 (de) Anforderungsbedingte dynamische Schnittstellengenerierung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee