-
Gebiet der Erfindung
-
Die
Erfindung betrifft allgemein Serversoftware in einer vernetzten
Umgebung und insbesondere auf einem Server verarbeitete dynamische
adaptive Softwarekomponenten.
-
Hintergrund der Erfindung
-
US 2204/0044999A1 betrifft
ein System zum automatischen Aktualisieren von Programmmodulen in
Client/Server-Netzwerken.
In einem Netzwerk, das verschiedene Typen von Servercomputern aufweist, werden
Ziel-Servercomputer zuerst auf der Grundlage der Serverfunktionalität in logische
Gruppen unterteilt. Dateiaktualisierungen werden auf einem Master-Aktualisierungsserver
verfügbar
gemacht. Der Master-Aktualisierungsserver
bewirbt die Verfügbarkeit
an die Zielserver. Der Master-Aktualisierungsserver erzeugt eine
bewerbende Nachricht und sendet die bewerbende Nachricht zu den
Ziel-Servercomputern oder stellt sie diesen auf andere Weise zur
Verfügung.
Jeder Ziel-Servercomputer stellt fest, ob die Aktualisierung auszuführen ist.
Falls eine Aktualisierung auszuführen
ist, wird das Aktualisierungsmodul entsprechend einem vordefinierten
Aktualisierungsplan auf dem Ziel-Servercomputer installiert.
-
US 6 006 034 betrifft Verfahren
und Systeme zum Unterhalten von Anwendungsprogrammen auf einem Clientcomputer
in einer Client-Server-Netzwerkumgebung, in der dieses Aktualisieren ein
häufiges
und wirksames Einrichten der Anwendungskomponenten notwendig macht.
Die Versionsaktualisierungssteuerung wird auf einen individuellen
Client statt auf einen Server übertragen.
-
Client/Server-Softwareanwendungen
sind unter zunehmenden Änderungsdruck
geraten, um sich entwickelnde Anforderungen und Änderungen innerhalb der Umgebungen,
in denen sie eingerichtet sind, zu erfüllen. Es ist wünschenswert,
dass diese Anwendungen unter spannungsgeladenen und sogar unvorhergesehenen
Umständen
eine maximale Leistungsfähigkeit
aufweisen. Einfach bei der Auslegungszeit ("design time") zu versuchen, vorherzusagen, welche
Anpassung zur Laufzeit erforderlich sein kann (beispielsweise ein
Just-in-Case-(JIC)-Ansatz), reicht häufig nicht aus, weil hierdurch
nicht alle Laufzeitsituationen in Betracht gezogen werden können, die
tatsächlich
eine Anpassung zur Laufzeit erfordern.
-
Ferner
erfordert der Versuch, Anpassbarkeit in eine Anwendung einzubauen,
bevor sie eingerichtet wird, ungewöhnlichen Durchblick auf Seiten
der Softwareentwickler, weil die Entwickler während der Entwurfsphase ("design time") verstehen müssen, welche
Teile der Anwendung und bis zu welchem Grad angepasst werden müssen. Selbst
der am besten durchdachte und vorhergesehene Entwurf benötigt häufig einen
gewissen Grad einer spezifischen Auslegung, um sich an Umstände anzupassen,
sobald die Auswirkung auf die Anwendung für diese Umstände bekannt
wird.
-
Ein
Anpassbarkeitsproblem betrifft die Skalierbarkeit oder Leistungsfähigkeit
einer Anwendung. Das heißt,
dass die Nutzung oder der kommerzielle Erfolg einer Anwendung zunächst unterschätzt werden
können.
Folglich muss die Anwendung möglicherweise
hochskaliert werden, um den unerwarteten Bedarf zu erfüllen. Ein
beliebter Ansatz für
dieses Problem besteht darin, ein Übermaß an Rechenressourcen (beispielsweise
Prozessoren und/oder Speicher) bereitzustellen, typischerweise durch
Liefern doppelter Maschinen, die sich Anwendungsanfragen durch irgendeinen
Lastausgleichsmechanismus teilen. Diese Lösung ist nicht nur kostspielig,
sondern erfordert auch einen erhöhten
Konfigurations- und Verwaltungsaufwand.
-
Ein
anderer Ansatz für
die Anwendungsskalierbarkeit besteht darin, Cache-Dienste einzurichten. Mit
Cache-Diensten werden Anwendungsdaten, auf die häufig zugegriffen wird, für verbesserte
Zugriffsantwortzeiten im Speicher gehalten. Dieser Ansatz erfordert
das Unterhalten und die Unterstützung von
Cache-Vereinbarungen und das Unterhalten zusätzlicher Hardware in Zusammenhang
mit Speichervorrichtungen, die die Cache-Speicherung unterstützen.
-
Generell
wurde bei der Anpassbarkeit von Anwendungen in erster Linie auf
Techniken zurückgegriffen,
die versuchen, begrenzte Ressourcen (beispielsweise Prozessor und
Speicher) weiter zu strecken, als sie andernfalls erweitert worden
wären, wenn
eine bestimmte Anwendung oder Komponente über anfängliche Erwartungen hinaus
beliebt wird. Diese Ansätze
haben sich nicht auf das Ändern
des Verhaltens der Anwendung konzentriert, sondern vielmehr angestrebt,
die Umgebung und externe Schnittstellen in Zusammenhang mit der
Anwendung zu verbessern.
-
Daher
besteht ein Bedarf an verbesserten Techniken zur Anpassbarkeit von
Anwendungen oder Softwarekomponenten, welche das Verhalten einer
Komponente dynamisch erweitern oder ändern, um eine gewünschte Anpassung
zu erreichen.
-
Zusammenfassung der Erfindung
-
Gemäß einer
Ausführungsform
ist eine Aktiver-Objektraum-(AOS)-Umgebung
vorgesehen, in der Erweiterungen von Komponenten dynamisch erkannt,
installiert und verarbeitet werden. Die Erweiterungen können durch
dynamisches Ersetzen individueller Komponentenverhaltensweisen,
wodurch wiederum Verhaltensweisen des Gesamtdiensts geändert werden,
erreicht werden.
-
Kurzbeschreibung der Zeichnungen
-
Es
zeigen:
-
1 ein
Diagramm einer Aktiver-Objektraum-(AOS)-Architekturumgebung oder -Plattform gemäß einer
als Beispiel dienenden Ausführungsform
der Erfindung,
-
2 ein
Diagramm eines Verfahrens zum dynamischen Anpassen einer Komponente
gemäß einer
als Beispiel dienenden Ausführungsform
der Erfindung,
-
3 ein
Diagramm eines dynamischen, anpassenden Systems gemäß einer
als Beispiel dienenden Ausführungsform,
und
-
4 ein
Diagramm eines anderen Verfahrens zum dynamischen Anpassen einer
Komponente gemäß einer
als Beispiel dienenden Ausführungsform.
-
Detaillierte Beschreibung
-
1 ist
ein Diagramm einer Aktiver-Objektraum-(AOS)-Architekturumgebung oder -Plattform 100 gemäß einer
als Beispiel dienenden Ausführungsform
der Erfindung. Die Komponenten sind innerhalb eines maschinenzugänglichen
oder computerlesbaren Mediums implementiert und über ein Netzwerk zugänglich.
Das Netzwerk kann drahtgestützt
oder drahtlos sein oder eine Kombination eines drahtgestützten und
eines drahtlosen Netzwerks sein. Gemäß einer Ausführungsform
sind die Komponenten als ein Webanwendungsserver implementiert und
stellen ein Webinhalts-Liefersystem dar.
-
Die
Architektur 100 kann als eine Erweiterung regulärer Objekträume, wie
Sun Microsystems JavaSpaces®, betrachtet werden. Die
Architektur 100 beinhaltet den Begriff eines aktiven Objekts
(AO). Ein AO kommt mit seinem eigenen Verhalten (beispielsweise
Code), und ihm kann sein eigener Steuer-Thread zum Ausführen seines
Verhaltens gegeben werden. Gemäß einer
Ausführungsform
kann ein AOS als ein Server oder eine Maschine betrachtet werden,
der oder die sowohl als ein Ausführungsraum
für AOs
als auch als ein Koordinationsort, wo die AOs indirekt und entkoppelt
kommunizieren, während
sie Objekte aus einem global gemeinsam verwendeten Objektspeicher
abrufen, verwendet werden kann.
-
Ein
neuartiges Merkmal des hier vorgestellten AOS ist seine Fähigkeit,
Verhaltensweisen während
der Laufzeit dynamisch hochzuladen und/oder zu entfernen. Dies wird
in den als Beispiel dienenden Beschreibungen, die folgen, vollständiger beschrieben. Überdies
verwenden hier vorgestellte Ausführungsformen
AOs zum Implementieren der grundlegenden Bausteine einer Serverarchitektur,
und sie verlassen sich auf die AOS für das Koordinieren von Aktivitäten verschiedener
AOs. Daher ist die hier vorgestellte Architektur 100 an
Stelle einer festverdrahteten Architektur dynamisch, locker gekoppelt
und flexibel bzw. verformbar, weil sie auf AO-Gruppen und ihren
Beziehungen zueinander, die dynamisch geändert werden können, beruht.
-
In
den folgenden Beschreibungen wird gezeigt, dass das Verhalten einer
Anwendung oder einer Softwarekomponente innerhalb einer Maschine dynamisch
angepasst oder modifiziert werden kann, ohne durch Wahlmöglichkeiten
oder Entscheidungen eingeschränkt
zu werden, die während
einer Entwurfsphase für
die Anwendung oder Komponente vorgenommen wurden. Durch die Verwendung
der Architektur 100, die auf einem AOS beruht, kann die
Funktionalität
einer Komponente während
der Laufzeit dynamisch modifiziert, hinzugefügt oder entfernt werden, ohne
die Maschine anzuhalten oder neu booten zu müssen, um die Änderung
vorzunehmen.
-
Die
Komponenten der Architektur umfassen eine Serveranwendung oder -komponente,
eine Clientanwendung (Client), ein State-only-Objekt (SOO), ein
Festschichtobjekt (FLO) und ein Variable-Schicht-Objekt (VLO). Jedes
von diesen wird nun erörtert.
-
Die
Serverkomponente ist eine Anwendung oder ein Programm, die oder
das auf einer Maschine in der Art eines Servers läuft. Die
Komponente stellt Clients Funktionalitäten bereit. Ein Beispiel einer Komponente
ist ein unternehmensweites Angestelltenverzeichnis. Die Komponente
ist über
ein Netzwerk in der Art des Internets oder eines Intranets zugänglich.
-
Der
Client ist ein Programm, das sich über das Netzwerk mit der Komponente
verbindet und Informationen von der Serverkomponente verbraucht, indem
er Anfragen an die Serverkomponente bzw. die Serverkomponenten ausgibt
und Antworten davon empfängt.
-
Ein
SOO ist eine Datenstruktur, die Zustandsinformationen umfasst. Die
SOO-Datenstruktur weist jedoch kein maschinenausführbares
Verhalten auf. Mit anderen Worten besteht sie ausschließlich aus
Daten, wie eine Struktur in der Programmiersprache C, ein Datensatz
in der Programmiersprache Pascal, ein Dokument in der Extensible
Markup Language (XML) usw.
-
Ein
FLO ist ein AO, der für
die Kommunikation zwischen externen Einheiten, der Komponente und
einem VLO, das darin enthalten sein kann, verantwortlich ist. FLOs
sind für
das Erkennen neuer VLOs (welche die FLOs verwenden) in dem Objektraum
und das Installieren dieser VLOs für das Erreichen eines geänderten
Laufzeitverhaltens verantwortlich.
-
Ein
VLO ist ein austauschbares Funktionsobjekt, das sowohl ein Verhalten
als auch einen möglichen
Zustand aufweist. Ein VLO ist in der Lage, Daten zu manipulieren,
die ihm direkt über
ein FLO zugeführt
werden.
-
Innerhalb
der Architektur 100 existiert eine Anzahl von Objektklassen
in dem Objektraum. Die Koordination zwischen AOs wird durch das
Posten und Lesen von Objekten von der Architektur 100 durch
die verschiedenen AOs der Architektur 100 erreicht. Die
AOs brauchen nicht direkt miteinander zu kommunizieren; die Kommunikation
wird durch den AOS verwaltet, der die indirekte und locker gekoppelte
Kommunikation zwischen AOs erzwingt.
-
Einige
als Beispiel dienende SOO-Objekte schließen ein RequestState-Objekt
und ein ResponseState-Objekt ein. Jedes von diesen wird nun erörtert.
-
Ein
RequestState-Objekt umfasst eine Vielfalt von Attributen, wie:
- 1) requestID – eine Kennung, die verwendet
wird, um eine bestimmte Anfrage oder Antwort auf einen offenen Kommunikationskanal
in der Art eines Hyper-Text-Transfer-Protocol-(HTTP)-Sockets
abzubilden bzw. diesem zuzuordnen.
- 2) requestText – der
eigentliche Text einer von einem Client (beispielsweise in der Art
eines HTTP-Clients)
gesendeten Anfrage.
- 3) processorID – eine
Kennung, die verwendet wird, um anzugeben, welcher Prozessortyp
(typischerweise ein AO-Typ) das Objekt als nächstes manipulieren sollte.
Ein spezieller Wert von "NICHT
ZUGEWIESEN" wird
verwendet, um anzugeben, dass die Verarbeitung einer Instanz dieses
Objekts noch nicht begonnen hat.
- 4) processorHistory – eine
Codierung der Prozessoren, die bis zu einem bestimmten Zeitpunkt
eine Instanz dieses Objekts behandelt haben.
-
Ein
ResponseState-Objekt umfasst ähnliche Attribute:
- 1) requestID – eine von einem RequestState-Objekt
geerbte Kennung, welche den offenen Kommunikationskanal (beispielsweise
HTTP-Socket) identifiziert, durch den die Antwort schließlich zurückgegeben
werden kann.
- 2) responseText – der
eigentliche Text der einem Client in der Art eines HTTP-Clients
zuzuführenden
Antwort.
- 3) processorID – eine
Kennung, die verwendet wird, um anzugeben, welcher Prozessortyp
(typischerweise ein AO-Typ) das Objekt als nächstes manipulieren sollte.
Ein spezieller Wert "FERTIG" wird verwendet,
um anzugeben, dass an der Antwort keine weitere Arbeit erforderlich
ist, und die Antwort zum Client gesendet werden kann.
- 4) processorHistory – eine
Codierung der Prozessoren, die dieses Objekt und das dazu passende RequestState-Objekt
bisher behandelt haben.
-
Die
Architektur 100 weist auch eine als "Transponder" bezeichnete Serverkomponente auf. Der
Transponder ist ein AO, das für
das Empfangen von Anfragen in der Art von HTTP-Anfragen und das Posten von ihnen in
den Objektraum (als RequestState-SOOs) verantwortlich ist. Sobald
der Transponder die Anfrage empfangen hat, erzeugt er ein RequestState-Objekt,
wobei er das requestText-Attribut so festlegt, dass es den Anfragetext
umfasst. Er erzeugt auch eine eindeutige requestID und weist diese
zu, wobei er die requestID dem Kommunikationskanal (beispielsweise
HTTP-Socket) zuordnet, um
anzugeben, von wo die Anfrage gekommen ist, und markiert das RequestState-Objekt
mit dieser Kennung. Die Prozessorkennung ist standardmäßig auf "NICHT ZUGEWIESEN" gesetzt. Sobald
das RequestState-Objekt erzeugt wurde, wird es dem AOS zugeführt.
-
Der
Transponder ist auch für
das Aufnehmen von Antworten (als ResponseState-SOOs), die für die Auslieferung
vom Objektraum bereit sind, und für das Zurückführen von ihnen zu ihren jeweiligen
anfragenden Clients verantwortlich. Er registriert für die Benachrichtigung
mit dem AOS, wobei er fordert, dass ihm ResponseState-Objekte mitgeteilt
werden, deren Prozessorkennung "FERTIG" ist. Nach der Benachrichtigung
entnimmt der Transponder das passende ResponseState-Objekt aus dem
Objektraum und übermittelt
den Inhalt von responseText über
den durch das requestID-Attribut
identifizierten Kommunikationskanal (Socket) zum geeigneten Client.
-
Ferner
ist der Transponder auch konfiguriert, um auf zwei Typen von VLOs
zu achten und sie zu installieren. Diese Objekte werden als Voranfrageverhalten
und Nachanfrageverhalten bezeichnet. Sie können verwendet werden, um das
Verhalten hinzuzufügen
oder zu ändern,
das die Verarbeitung unmittelbar vor der Übermittlung einer Anfrage an
den Objektraum oder direkt nach dem Posten einer Antwort zum Objektraum
ausführt.
Für diese
beiden VLOs registriert der Transponder die Benachrichtigung beim AOS,
wobei er fordert, dass er immer dann informiert wird, wenn Objekte
der Klasse Voranfrageverhalten oder Nachantwortverhalten in den
Objektraum gegeben bzw. dort plaziert werden. Nach der Benachrichtigung
nimmt der Transponder diese Objekte und installiert sie für die interne
Verwendung.
-
Eine
andere Komponente der Architektur 100 ist ein Prozessorwähler. Dies
ist ein AO, das den Objektraum durch Registrieren von Benachrichtigungen
für den
Raum überwacht,
wobei er fordert, über alle
RequestState-Objekte mit einer processorID "NICHT ZUGEWIESEN" informiert zu werden. Nach Empfang
der Benachrichtigung nimmt dieses AO ein passendes RequestState-Objekt,
fragt den Kommunikationskopf (beispielsweise HTTP-Kopf) des requestText-Felds
des Objekts ab und gibt es mit einem neuen processorID-Wert, der
den Typ des Prozessors identifiziert, der diese Anfrage als nächstes verarbeiten
sollte, zum AOS zurück.
Der Prozessorwähler
umfasst ein VLO (als Process Mapper bezeichnet), das das eigentliche
Abfragen und die eigentliche Entscheidungsfindung vornimmt.
-
Gemäß einer
Ausführungsform
gibt es einige spezielle Komponenten, wie einen /"ping"-Prozessor und einen "/helloWorld"-Prozessor. Diese
sind Beispiele von HTTP Uniform Resource Identifiers (URI), welche
AOs verarbeiten, welche wissen, wie HTTP-Anfragen zu verarbeiten
sind, die mit "/ping" und "/helloWorld" enden. Diese AOs
registrieren Benachrichtigungen beim Objektraum für RequestState-Objekte, welche zu
den processorIDs passen, denen sie zugewiesen wurden. Sie delegieren
jedoch die eigentliche Antworttexterzeugung an ihre jeweiligen VLOs.
-
Für die "/ping"- und "/helloWorld"-Prozessoren wird
das RequestState-Objekt von diesen Prozessoren verbraucht, und es
wird ein ResponseState-Objekt, das den benötigten Antworttext (im responseText-Attribut)
enthält,
erzeugt und an Stelle des RequestState-Objekts in den Objektraum
gegeben. Die processorID des RequestState-Objekts, dessen Lebensdauer
endet, wird dem neuen ResponseState-Objekt zugewiesen, um zu ermöglichen,
dass die Antwort den gleichen Kommunikationskanal oder Socket zurückkehrt
wie die anfängliche
Anfrage. Wenn keine weitere Verarbeitung für eine Anfrage benötigt wird,
weisen diese Prozessoren der processorID den speziellen Wert "FERTIG" zu, um anzugeben,
dass die Antwort für
die Übermittlung
zum Client bereit ist.
-
In
einer erweiterten Ausführungsform
könnten
auch ein "400: Schlechte
Anfrage"- und ein "404: Nicht gefunden"-Prozessor bereitgestellt
sein. Diese Beispiele von HTTP-Verwaltungs prozessoren erzeugen
HTTP-Verwaltungsantworten für
Clients. Zur Erläuterung
sei bemerkt, dass der "400:
Schlechte Anfrage"-Prozessor
den Objektraum auf Anfragen überwacht,
die, entweder durch den Prozessorwähler oder spezifische URI-Prozessor-AOs,
als schlecht gebildet angesehen werden. Er tut dies durch Registrieren
einer Benachrichtigung beim Objektraum, wobei er auffordert, über alle
RequestState- oder
ResponseState-Objekte informiert zu werden, deren processorID ein
reservierter "BAD
REQUEST"-Wert ist.
-
Nach
der Benachrichtigung über
eine schlechte Anfrage entnimmt das AO das passende Objekt aus dem
Objektraum und erzeugt ein geeignet formatiertes HTTP-"400: Schlechte Anfrage"-ResponseState-Objekt,
um es zu dem regel-verletzenden
Client zurückzugeben.
Die ResponseStaterequestID wird von dem schlechten RequestState-Objekt
geerbt, wobei dem responseText-Attribut einiger vorgegebener oder
konfigurierbarer Text, wodurch das Problem beschrieben wird, zugewiesen
wird, und der processorID wird "FERTIG" zugewiesen, um anzugeben,
dass diese Antwort für
die Übermittlung
bereit ist.
-
Die
Architektur 100 unterstützt
dynamische und Echtzeiterweiterungen. Um diese Funktionalität zu erläutern, wird
nun ein Beispiel vorgestellt. Es sei ein Client betrachtet, der
zum Empfangen eines Webinhalts-Lieferdiensts, dessen Schnittstelle
durch eine erste Komponente innerhalb des AOS, wie AO #1, unterstützt wird,
mit der Architektur 100 integriert bzw. kommuniziert. AO
#1 kann mit einer Vielzahl anderer AOs kommunizieren, um dem Client
Webinhaltslieferungen zur Verfügung
zu stellen.
-
Es
sei nun erwogen, dass ein Verhaltensänderungsmodul in den AOS eingebracht
wird, um den Webinhalts-Lieferdienst in irgendeiner Weise zu erweitern
bzw. zu verbessern. Das Verhaltensänderungsmodul kann die der
Inhaltsübermittlung
von AO #1 zugeordnete Ausführungszeit überwachen
und auf der Grundlage davon, dass dem Client unannehmbare Antwortzeiten
zugeführt
werden, neue Komponenten (AOs) zum AOS hinzufügen, oder es kann VLOs von
Schlüssel-AOs
auf der Grundlage einer unannehmbaren Clientantwortzeit durch eine neuere
Version ersetzen.
-
Ein
Weg, um dies innerhalb der Architektur 100 zu erreichen,
besteht darin, dass sich das Verhaltensänderungsmodul innerhalb des
AOS (als ein neues AO) selbst installiert, und eine Benachrichtigung
beim AOS registriert, worin aufgefordert wird, über alle ResponseTime-Objekte
informiert zu werden, die dem Objektraum zugeführt werden.
-
Das
ResponseTime-Objekt kann ein neues Objekt sein, das in den Objektraum
eingebracht wird, welches die folgenden Attribute umfasst:
- 1) processorHistory – eine Codierung der Prozessoren,
die die Antwort für
dieses Objekt behandelt haben.
- 2) responseTime – die
eigentliche aufgezeichnete Zeit zwischen dem Empfang der Anfrage
und der Übermittlung
der Antwort für
eine bestimmte HTTP-Anfrage.
-
Es
sei bemerkt, dass das Verhaltensänderungsmodul
ein "Ping Factory"-AO an den AOS liefert und
dass die Ping Factory, wie vorstehend erwähnt wurde, fordert, dass der
AOS sie über
alle zum AOS geposteten ResponseTime-Objekte benachrichtigt. Sobald
dies geschehen ist, übermittelt
die Ping Factory zum Objektraum ein neues VLO (Erweiterung bzw.
Verbesserung), das mit der Ping Factory gebündelt ist. Dieses neue VLO
weiß,
wie die neuen ResponseTime-Objekte als ein Nachantwortverhaltens-Objekt
zu erzeugen sind.
-
Wenn
das neue VLO zum Objektraum übertragen
wird, wird der Transponder durch den Objektraum benachrichtigt,
weil das neue VLO als ein Nachantwortverhaltens-Objekt identifiziert
wurde. Der Transponder nimmt dieses neue VLO aus dem Objektraum
und installiert es intern. Von diesem Punkt an verwendet der Transponder
für jedes
ResponseState-Objekt, dem der spezielle Wert "FERTIG" für
sein processorID-Attribut
zugewiesen wurde, das neue VLO, um eine neue Instanz eines ResponseTime-Objekts
zu erzeugen und sie zum Objektraum zu posten. Der processorHistory-Attributwert, der
in dem ResponseState-Objekt enthalten ist, wird zum processorHistory-Attribut
der ResponseTime-Objektinstanz herüberkopiert.
-
Als
nächstes
beginnt die Ping Factory, die in den Objektraum geposteten neuen
ResponseTime-Objekte dynamisch zu erfassen. Die Ping Factory kann
Schwellenwerte verwenden, um zu entscheiden, dass die Antwortzeiten
für Clients,
die Ping-Inhalt anfragen, nicht annehmbar sind. Es sei bemerkt, dass
die Antwortzeiten unannehmbar niedrig oder unannehmbar hoch sein
können,
weil ein Wunsch bestehen kann, dass ein geringeres Niveau der Ansprechempfindlichkeit
bzw. der Reaktionsfreudigkeit von der AO #1-Komponente vorhanden
ist. Die Ping Factory kann die Situation durch Abfragen des processorHistory-Attributs
inspizieren, wodurch die "/ping"-URI-processorID
in der Historie gesucht wird, um eine kurze Liste der "/ping"-Anfragen zu erstellen und das responseTime-Attribut
mit bestimmten vordefinierten Grenzen oder Schwellen zu vergleichen.
-
Wenn
die Ping Factory entscheidet, die Art zu ändern, in der das "/ping"-Prozessor-AO arbeitet, überträgt die Ping
Factory das neue Ping-Verhalten über
ein VLO zum Objektraum. Der Objektraum benachrichtigt das "/ping"-Prozessor-AO über dieses neue Ping-Verhalten.
Das "/ping"-Prozessor-AO nimmt dieses neue Verhalten
aus dem Objektraum und installiert es intern. Hierdurch wird wiederum
der Aufwand geändert,
der zur Erzeugung von Ping-Antworten erforderlich ist, und dies
hat einen starken Einfluss auf von den Clients erfahrene Antwortzeiten.
-
In
dem vorstehend präsentierten
Beispiel kann der "/ping"-Prozessor als eine AO-Komponente angesehen
werden, so dass die Ping Factory und ihr neues Objekt (ResponseTime)
unter Verwendung eines VLOs als ein Nachantwortverhaltens-Objekt
(Erweiterung bzw. Verbesserung) dynamisch innerhalb des AOS installiert
werden. Hierdurch wird die Ping Factory mit den dem "/ping"-Prozessor zugeordneten Antwortzeiten
integriert, und es wird ermöglicht,
dass die Ping Factory dynamisch und in Echtzeit feststellt, ob das "/ping"-Prozessor-Verhalten zu ändern ist, wenn
die Ansprechempfindlichkeit auf Clients als unannehmbar niedrig
oder unannehmbar hoch angesehen wird.
-
Es
wurde gezeigt, dass die AOS-Architektur 100 so erweitert
bzw. verbessert werden kann, dass sie Voranfrageverhaltens-Objekte und Nachantwortverhaltens-Objekte
aufweist, die durch einen Transponder überwacht werden. Diese Objekttypen
sind VLOs, die zum dynamischen Ändern
oder Anpassen des Verhaltens von AOs (Komponenten) zur Laufzeit in
den AOS integriert werden können.
-
2 ist
ein Flussdiagramm eines Verfahrens 200 zum dynamischen
Anpassen einer Softwarekomponente gemäß einer als Beispiel dienenden
Ausführungsform
der Erfindung. Das Verfahren 200 (nachstehend als "anpassende Komponente" oder "anpassendes AO" bezeichent) wird
in einem maschinenzugänglichen
und lesbaren Medium implementiert und über ein Netzwerk betrieben.
Das Netzwerk kann festverdrahtet oder drahtlos sein oder eine Kombination
eines festverdrahteten und eines drahtlosen Netzwerks sein. Gemäß einer
Ausführungsform
wird die anpassende Komponente innerhalb einer AOS-Architektur,
-Umgebung oder -Plattform in der Art der Architektur 100 aus 1 implementiert.
-
Bei 210 stellt
die anpassende Komponente dynamisch eine Erweiterung einer anderen
Komponente innerhalb einer Verarbeitungsumgebung fest. Die Erweiterung
kann als eine Kombination eines neuen AOs, eines VLOs zum Ersetzen
des Verhaltens in dem Transponder und einer ganz neuen Klasse zum
Beschreiben des neuen Antwortzeit-SOOs betrachtet werden. Die Umgebung
ist ein AOS, in dem die Architektur durch die locker gekoppelte
Beziehung und die Wechselwirkungen zwischen AOs definiert ist. Auf
diese Weise können
die anpassende Komponente und ihre Verarbeitung, wie in 1 dargestellt
ist, auch als ein oder mehrere AOs betrachtet werden, die innerhalb
der Verarbeitungsumgebung ausgeführt
werden.
-
Die
anpassende Komponente kann eine Erweiterung an einer existierenden
Komponente in einer Vielzahl von Weisen feststellen und unterscheiden.
Beispielsweise kann sich die anpassende Komponente bei 211 vorher
bei der Umgebung registriert haben, um aktive Benachrichtigungen
für eine
innerhalb der Umgebung gepostete Erweiterung zu empfangen.
-
Eine
Technik, um dies auszuführen,
besteht darin, dass Erweiterungen als ein spezifischer VLO-Typ in
der Art eines Voranfrageverhaltens-Objekts oder eines Nachantwortverhaltens-Objekts
definiert werden. Das anpassende Komponenten-AO fordert, dass die Umgebung es benachrichtigt,
wenn Objekte mit diesen Eigenschaften zu der Umgebung gepostet werden.
Auf diese Weise kann die anpassende Komponente bei 212 Benachrichtigungen über Voranfrageverhaltens-
und Nachantwortverhaltens-Objekte dynamisch und in Echtzeit empfangen, und
diese innerhalb der Umgebung geposteten Objekte können angeben,
dass eine Erweiterung zu der Umgebung übertragen wird.
-
Sobald
die anpassende Komponente bei 220 eine Benachrichtigung über die
Erweiterung empfangen hat und ihr Vorhandensein in der Umgebung
feststellt, installiert die anpassende Komponente die Erweiterung
dynamisch innerhalb der Umgebung. Eine Technik hierfür kann darin
bestehen, auf die ausführbaren
Befehle der Erweiterung intern bei der Verarbeitung des anpassenden
AOs Bezug zu nehmen. Dies kann geschehen, wenn die Erweiterung in
einer Programmiersprache geschrieben ist, die ein spätes Binden
von Code unterstützt,
wie JAVA usw.
-
Falls
die Erweiterung beispielsweise als ein Voranfrageverhaltens-Objekttyp
identifiziert wird, kann das anpassende AO die Erweiterungsbefehle ausführen oder
aufrufen, bevor es RequestState-Objekte erzeugt (vorstehend in Bezug
auf 1 erörtert).
Falls die Erweiterung alternativ ein Nachantwortverhaltens-Objekttyp
ist, kann das anpassende AO die Erweiterung ausführen oder aufrufen, nachdem
es ein ResponseState-Objekt erzeugt hat (vorstehend auch mit Bezug
auf 1 erörtert).
-
Daher
kann das anpassende AO die Erweiterung auf der Grundlage des identifizierten
oder festgestellten Erweiterungstyps geeignet in die Umgebung laden
und darin installieren. Ferner können
das Laden und die Installation erreicht werden, indem innerhalb
der anpassenden Komponente geeignet auf die Erweiterung Bezug genommen
wird, so dass sie bei einem geeigneten Ereignis oder unter einer
geeigneten Bedingung geschieht, beispielsweise vor der Erzeugung
eines RequestState-Objekts oder nach der Erzeugung eines ResponseState-Objekts.
-
Sobald
die Erweiterung dynamisch in die Umgebung geladen und darin installiert
wurde, kann sie bei 230 innerhalb der Umgebung für Anfragen oder
Antworten, die der Komponente zugeordnet sind, dynamisch verarbeitet
werden. Wenn die Erweiterung in die Umgebung geladen oder darin
installiert wird, ist ihre Ausführungssequenz
oder Ausführungszeit
dem anpassenden AO bekannt. Wenn es demgemäß eine Bedingung oder ein Ereignis
vorschreibt, leitet das anpassende AO die Erweiterung ein oder führt sie
aus. Es sei darauf hingewiesen, dass die Installation und Ausführung der
Erweiterung innerhalb der Umgebung dynamisch und in Echtzeit geschehen.
-
Gemäß einer
Ausführungsform
kann, sobald die Erweiterung ausgeführt wurde, die mit dieser Ausführung verbundene
Ausgabe ein neues Objekt innerhalb der Umgebung erzeugen, das der
Umgebung zuvor nicht bekannt war. Dieses neue Objekt kann von einer
anderen Komponente (AO) behandelt werden, die innerhalb der Umgebung
dynamisch installiert wurde. Das anpassende AO kann sich des neuen
oder verschiedenen AOs nicht einmal bewusst sein, wobei alles, was
das anpassende AO weiß,
darin besteht, dass ein neues Objekt erzeugt und in die Umgebung
gepostet wird, wenn die Erweiterung ausgeführt wird. Das neue AO stellt
das neue Objekt dann dynamisch fest und führt eine gewisse Verarbeitung
aus.
-
In
manchen Fällen
kann das neue AO bei 232 tatsächlich feststellen, dass ein
anderes Verhalten für
ein bestehendes AO ansprechend auf die Verarbeitung der neuen Objekte,
die der Erweiterung zugeordnet sind, in der Umgebung installiert
werden sollte. Demgemäß können Bestimmungen
dynamisch vorgenommen werden und durch die Verwendung von Erweiterungen
in Echtzeit vorgenommen werden, um auf der Grundlage des neuen AOs,
das die Ausgabe der Erweiterung konsumiert, zu entscheiden, ob eine
bestimmte existierende Komponente geeignet arbeitet und ob ihr Verhalten
(VLO) ersetzt, modifiziert oder verbessert werden sollte. Ein Beispiel
einer solchen Situation wurde vorstehend in Bezug auf 1 für durch
die Ping Factory (das neue AO), die bei Bedarf wiederum ein neues
VLO (eine neue Erweiterung) für
das "/ping"-Prozessor-AO erzeugt,
verarbeitete neue ResponseTime-Objekte präsentiert.
-
Gemäß einer
Ausführungsform
kann die anpassende AO bei 240 die Erweiterung verwenden, um
die Ansprechempfindlichkeit des ursprünglichen AOs zu überwachen.
In manchen Fällen
kann das ursprüngliche
AO bei 250 einem Inhalt liefernden Webdienst zugeordnet
werden. Es sei bemerkt, dass die Erweiterung und Komponente eine
beliebige Anwendung sein kann, die innerhalb der Umgebung installiert
und verarbeitet werden kann. Der Inhalt liefernde Dienst wird als
eine Beispielkomponente vorgestellt. Ferner sollen die Ausführungsformen
der Erfindung nicht auf einen bestimmten Komponenten- oder Erweiterungstyp
beschränkt
sein.
-
Das
anpassende AO demonstriert eine Technik für das automatische dynamische
Anpassen einer Softwarekomponente zur Laufzeit. Dies wird durch
Erkennen, Installieren und Verarbeiten von Erweiterungen innerhalb
der Umgebung erreicht. Folglich kann der Durchsatz von Anwendungen
oder Komponenten nun durch die Verwendung dynamischer Erweiterungen,
die der laufenden Umgebung zugeführt
werden, statt durch die Verwendung zusätzlicher physikalischer Ressourcen,
wie Maschinen und/oder Speicher, geändert oder angepasst werden.
-
3 ist
ein Diagramm eines dynamischen anpassenden Systems 300 gemäß einer
als Beispiel dienenden Ausführungsform.
Das dynamische anpassende System 300 ist in einem maschinenzugänglichen
und computerlesbaren Medium implementiert und über ein Netzwerk betreibbar.
Das Netzwerk kann festverdrahtet, drahtlos oder eine Kombination
eines festverdrahteten und eines drahtlosen Netzwerks sein. Gemäß einer
Ausführungsform
ist das dynamische anpassende System 300 innerhalb der
Architektur 100 aus 1 implementiert
und implementiert zumindest teilweise das Verfahren 200 aus 2.
-
Das
dynamische anpassende System 300 umfasst eine Aktiver-Objektraum-Umgebung
(AOS) 301, ein Variable-Schicht-Objekt (VLO) 302A und
einen Transponder 303 auf. Bei manchen Anordnungen weist
das dynamische anpassende System 300 auch eine erste Komponente 302B und
eine zweite Komponente 304 auf.
-
Der
AOS 301 unterstützt
eine dynamische Verarbeitungsumgebung, die durch Koordination und Kooperation
innerhalb des AOS 301 implementierter aktiver Objekte (AOs)
definiert ist. Die Verarbeitung geschieht durch Posten von SOOs,
die durch andere AOs konsumiert, festgestellt und verarbeitet werden.
-
Das
VLO 302A ist ein spezieller VLO-Typ, der Befehle aufweist
und innerhalb seines eigenen von irgendeinem enthaltenden AO zugeführten Steuerthreads
ausführen
kann. Das VLO 302A des dynamischen anpassenden Systems 300 ist
als eine Erweiterung oder ein dynamisches Komplement einer ersten
Komponente oder als irgendein anderes AO 302B, das innerhalb
des AOS 301 verarbeitet wird, ausgelegt. Das VLO 302A wird
für den
AOS 301 durch einen Typ identifiziert.
-
Der
Typ kann einem Voranfrageverhaltens-Objekt oder einem Nachantwortverhaltens-Objekt
für das
AO 303 zugeordnet werden.
-
Der
Transponder 303 ist ein AO, das bewirkt, dass RequestState-Objekte
innerhalb des AOS 301 gepostet werden. Der Transponder 303 konsumiert auch
in den AOS 301 gepostete ResponseState-Objekte. Das VLO 302A kann
durch Erfassen von dem Transponder 303 bekannten Informationen über RequestState-Objekte
mit dieser Verarbeitung integrieren, bevor die RequestState-Objekte
in den AOS 301 gepostet werden (Voranfrageverhaltens-Objekttyp des
VLOs 302A). Alternativ kann das VLO 302A durch
Erfassen von dem Transponder 303 bekannten Informationen
mit der Verarbeitung integrieren, nachdem ResponseState-Objekte
in den AOS 301 gepostet wurden (Nachantwortverhaltens-Objekttyp
des VLOs 302A).
-
Der
Transponder 303 bestimmt auf der Grundlage des Objekttyps
des VLOs 302A, wie das VLO 302A innerhalb des
AOS 301 zu installieren ist. Ferner bestimmt der Transponder 303,
wann das VLO 302A zu verarbeiten ist. Die Installation
und Ausführung
des VLOs 302A geschehen dynamisch und in Echtzeit innerhalb
des AOS 301. Dies bedeutet, dass keine manuelle Integration,
Konfiguration und/oder Kompilation erforderlich ist, um das VLO 302A zu
installieren und auszuführen.
-
Gemäß einer
Ausführungsform
weist das dynamische anpassende System 300 auch eine zweite Komponente
oder ein zweites AO 304 auf, das innerhalb des AOS 301 dynamisch
installiert und verarbeitet wird. Das zweite AO 304 kann
die Befehle zum anfänglichen
Posten des VLOs 302A innerhalb des AOS 301 aufweisen.
Der AOS 301 benachrichtigt den Transponder 303,
wenn das VLO 302A festgestellt wird. Der Transponder 303 lädt und installiert dann
das VLO 302A innerhalb des AOS 301 oder intern
im Transponder 303 auf der Grundlage des dem VLO 302A zugeordneten
Objekttyps (Voranfrageverhalten oder Nachantwortverhalten).
-
Das
zweite AO 304 kann sich auch zum Empfang eines neuen Objekttyps
beim AOS 301 registrieren. Der neue Objekttyp wird durch
das VLO 302A erzeugt. Der neue Objekttyp kann aus dem AOS 301 abgerufen
werden, wenn er durch das VLO 302A gepostet und beurteilt
wurde. In manchen Fällen
kann das zweite AO 304 auf der Grundlage der Beurteilung
von Instanzen in den AOS 301 geposteter neuer Objekte feststellen,
dass ein anderes VLO für
das erste AO 302B verwendet werden sollte, welches das
AO 304 in den Objektraum gibt. Das AO 302B ersetzt
sein VLO durch das vom AO 304 gepostete neue VLO, wodurch
vom AO 304 festgestellte Mängel behandelt werden sollen,
indem die Instanzen der neuen Objekte beurteilt werden, die vom VLO 302A gepostet
wurden.
-
Ein
Beispielszenario einer solchen Situation wurde vorstehend mit Bezug
auf 1 vorgestellt, wobei das neue Objekt ein ResponseTime-Objekt war
und das zweite AO 304 eine Ping Factory war. Demgemäß kann das
VLO 302A als eine Erweiterung angesehen werden, welche
konfiguriert werden kann, um Antwortzeiten für Clientanfragen dynamisch
zu verfolgen, wobei die Antwortzeiten einer vom ersten AO 302B zugeführten Webinhaltslieferung
zugeordnet sind und wobei Bestimmungen zum Ändern des Verhaltens des ersten
AOs 302B vom zweiten AO 304 durch Beurteilen von
Informationen erreicht werden, die durch das VLO 302A in
den AOS 301 gepostet werden.
-
Der
Transponder 303 erleichtert die Kommunikation zwischen
dem AOS 301 und externen Clients mit dem AOS 301.
Das VLO 302A ist ein spezieller AO-Typ, der vom Transponder 303 erkannt
wird. In manchen Fällen
informiert der Objekttyp des VLOs 302A den Transponder 303,
das VLO 302A innerhalb der Logik des Transponders 303 zu
installieren, zu laden und zu verarbeiten. Dies ermöglicht es,
dass andere Komponenten (in der Art der zweiten Komponente 304)
installiert und verwendet werden, um eine erste Komponente 302B zu
beurteilen. Die Beurteilung geschieht durch neue Objekte, die das
VLO 302A erzeugt, wenn es eine Ausführung vornimmt. Diese neuen
Objekte umfassen Informationen über die
erste Komponente 302B und ihre Verarbeitung innerhalb des
AOS 301. Das zweite AO 304 kann dann dem ersten
AO 302B dynamisch ein Austauschverhalten zuführen, um
ein besseres Dienstniveau zu erreichen.
-
Es
wurde nun gezeigt, wie eine Komponente oder ein AO durch Softwaremechanismen
statt durch zusätzliche
Hardwaremechanismen dynamisch angepasst werden kann.
-
4 ist
ein Diagramm eines anderen Verfahrens 400 zum dynamischen
Anpassen einer Softwarekomponente oder AO gemäß einer als Beispiel dienenden
Ausführungsform.
Das Verfahren 400 (nachstehend "Anpassungsbefehle") wird in einem maschinenzugänglichen
und computerlesbaren Medium implementiert und ist über ein
Netzwerk betreibbar. Das Netzwerk kann festverdrahtet, drahtlos
oder eine Kombination eines festverdrahteten und eines drahtlosen
Netzwerks sein. Gemäß einer
Ausführungsform
sind die Anpassungsbefehle eine alternative Verarbeitungstechnik
zu der vorstehend mit Bezug auf das Verfahren 200 aus 2 vorgestellten Technik.
-
Die
Anpassungsbefehle können
von entfernbaren Maschinenmedien zur Verarbeitung zu einer Maschine
hochgeladen werden, wenn die entfernbaren Medien mit der Maschine
verbunden werden. Alternativ können
die Anpassungsbefehle von einem fernen Server über das Netzwerk heruntergeladen werden
und zur Verarbeitung auf einer Maschine installiert werden. Bei
wieder anderen Anordnungen können
die Anpassungsbefehle vorab erzeugt oder in den Speicher einer Maschine
geladen und auf der Maschine verarbeitet werden. Wenn die Anpassungsbefehle
ausgeführt
werden, führen
sie das in 4 dargestellte Verfahren 400 aus.
-
Bei 410 stellen
die Anpassungsbefehle eine Erweiterung fest, die einem verarbeitenden
AO zugeordnet ist. Gemäß einer
Ausführungsform
ist die Erweiterung ein VLO, das zu einem AOS gepostet wurde, und
die Anpassungsbefehle sind eine Transponderkomponente, welche die
Kommunikation zwischen dem AOS und externen Clientanwendungen ermöglicht.
-
Bei 420 installieren
die Anpassungsbefehle dynamisch die Erweiterung zur anschließenden Ausführung innerhalb
der Umgebung. Gemäß einer
Ausführungsform
installieren die Anpassungsbefehle dynamisch die Erweiterung innerhalb
der Verarbeitung der Anpassungsbefehle. Dies kann mit einem Zeiger zu
den Erweiterungsbefehlen zur Ausführung nach einem festgestellten
Ereignis oder einer festgestellten Sequenz erreicht werden. Die
Sequenz kann auf der Grundlage der Eigenschaften der Erweiterung (beispielsweise
Vorprozessverhalten oder Nachprozessverhalten) bestimmt werden.
-
Wenn
dementsprechend bei 430 die richtige Ereignissequenz festgestellt
wird, verarbeiten die Anpassungsbefehle die Erweiterung für Anfragen
oder Antworten. Mit anderen Worten ist die Erweiterung eine Vorprozesskomponente,
wenn sie als ein Voranfrageverhaltens-Objekttyp identifiziert wird,
und die Erweiterung ist eine Nachprozesskomponente, wenn sie als
ein Nachantwortverhaltens-Objekttyp identifiziert wird.
-
Gemäß einer
Ausführungsform
kann bei 440 ein zweites AO ansprechend auf eine von der
Erweiterung erzeugte Ausgabe verarbeitet werden. Beispielsweise
können
bei 441 eine Eingabe und eine Ausgabe innerhalb der Umgebung
der Anpassungsbefehle als Objekte mit definierten Typen dargestellt werden.
Auf diese Weise kann das zweite AO von der Erweiterung hervorgebrachte
neu erzeugte Objekte feststellen.
-
Bei 442 kann
die Erweiterung wiederum verarbeiten, bevor die Anpassungsbefehle
Anfragen erzeugen, oder die Erweiterung kann verarbeiten, nachdem
die Anpassungsbefehle Antworten auf diese Anfragen erzeugt haben.
Gemäß einer
Ausführungsform
kann das erste AO als ein inhaltsliefernder Webdienst verarbeitet
werden, und das zweite AO verwendet die Erweiterung, um festzustellen,
ob das erste AO ausreichend anspricht, um bestimmte vordefinierte
Schwellen zu erfüllen.
Unter der Annahme, dass die Ansprechempfindlichkeit nicht annehmbar ist, überträgt das zweite
AO das Ersatzverhalten zum ersten AO, das dafür ausgelegt ist, spezifische
Ansprech-Engpassprobleme zu adressieren.
-
Hierfür kann das
zweite AO bei 441 den Anpassungsbefehlen oder dem ersten
AO eine Nachricht senden. Die Nachricht oder der Befehl gibt an, dass
das erste AO die Verarbeitung anhalten sollte und sich selbst aus
der Umgebung entfernen sollte. Eine aktualisierte Version des ersten
AOs kann dann innerhalb der Umgebung dynamisch installiert und verarbeitet
werden.
-
Es
wurde nun gezeigt, wie Server-Softwarekomponenten oder AOs dynamisch
und zur Laufzeit angepasst werden können. Dies ermöglicht Erweiterungen,
um eine verbesserte Verarbeitung von AOs zu erleichtern, ohne dass
es notwendig wäre,
Maschinen herunterzufahren oder neu zu booten, welche die AOs verarbeiten.
Ferner ermöglicht
dies, dass Softwaremechanismen eingerichtet werden, um Leistungsfähigkeitsprobleme
mit AOs zu adressieren, statt herkömmliche Hardware-Ressourcen
(zusätzliche
Maschinen und/oder zusätzlichen
Speicher) zu verwenden.
-
Die
vorstehende Beschreibung dient der Erläuterung und ist nicht als einschränkend anzusehen. Viele
andere Ausführungsformen
werden Fachleuten beim Lesen der vorstehenden Beschreibung einfallen.
Der Anwendungsbereich der Ausführungsformen
sollte daher mit Bezug auf die anliegenden Ansprüche, zusammen mit dem vollen
Anwendungsbereich von äquivalenten
Ausgestaltungen, auf die sich die Ansprüche beziehen, bestimmt werden.
-
Die
Zusammenfassung ist in Übereinstimmung
mit 37 C.F.R. §1.72(b)
bereitgestellt und erlaubt es dem Leser, die Natur und den Gedanken
der technischen Darlegung schnell zu erfassen. Sie ist vorgelegt,
wobei zu verstehen ist, dass sie nicht verwendet werden sollte,
um den Schutzumfang oder die Bedeutung der Ansprüche zu interpretieren oder zu beschränken.
-
In
der vorstehenden Beschreibung der Ausführungsformen sind verschiedene
Merkmale in einer einzigen Ausführungsform
gruppiert, um die Darlegung rationeller zu gestalten. Dieses Darlegungsverfahren
sollte nicht so interpretiert werden, dass die beanspruchten Ausführungsformen
mehr Merkmale haben, als sie in jedem Anspruch ausdrücklich angegeben
sind. Vielmehr liegt, wie es die folgenden Ansprüche widerspiegeln, der Erfindungsgegenstand
in weniger als allen Merkmalen einer einzigen dargelegten Ausführungsform.
Demgemäß sind die
folgenden Ansprüche
hiermit in die Beschreibung der Ausführungsformen aufgenommen, wobei
jeder Anspruch für
sich als eine getrennte als Beispiel dienende Ausführungsform
steht.