DE602005002919T2

DE602005002919T2 - Adaptive Softwarekomponententechniken

Info

Publication number: DE602005002919T2
Application number: DE602005002919T
Authority: DE
Inventors: Lindsay Bradford; Julien J.P. Vayssiere; Stephen Hotland Park Milliner
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2004-12-13
Filing date: 2005-12-13
Publication date: 2008-07-31
Anticipated expiration: 2025-12-14
Also published as: US20060129516A1; DE602005002919D1; US8849781B2; EP1670212A1; ATE376320T1; EP1670212B1

Description

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.

Claims

Verfahren zum Verbessern der Anpassbarkeit von Komponenten innerhalb einer Aktiver-Objektraum-Architekturumgebung, wobei die Umgebung auf Gruppen aktiver Objekte und ihrer locker gekoppelten Beziehung zueinander und ihren Wechselwirkungen miteinander beruht, wobei das Verfahren den Schritt des Bereitstellens eines sich anpassenden aktiven Objekts (303) aufweist, das eine Erweiterung (302A) eines anderen aktiven Objekts innerhalb der Umgebung dynamisch feststellt, die Erweiterung (302A) innerhalb der Umgebung auf der Grundlage des Typs der festgestellten Erweiterung (302A) dynamisch installiert und die Erweiterung (302A) für mindestens eine von einer Anfrage an das andere aktive Objekt und einer Antwort von dem anderen aktiven Objekt dynamisch einleitet oder ausführt.
Verfahren nach Anspruch 1, das weiter eine Registrierung bei der Umgebung (301) aufweist, um eine Benachrichtigung von der Erweiterung (302A) zu empfangen, sobald die Erweiterung (302A) innerhalb der Verarbeitungsumgebung verfügbar ist.
Verfahren nach Anspruch 1 oder 2, wobei das dynamische Feststellen weiter das Empfangen einer Benachrichtigung von der Umgebung aufweist, dass ein Voranfrage- oder Nachantwort-Objekttyp in der Verarbeitungsumgebung gepostet wurde.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die dynamische Verarbeitung weiter das Posten eines neuen Objekttyps innerhalb der Verarbeitungsumgebung einschließt, wobei der neue Objekttyp durch eine andere dynamisch installierte Komponente innerhalb der Umgebung erkannt und verarbeitet wird.
Verfahren nach Anspruch 4, bei dem weiter, ansprechend auf Bedingungen oder Entscheidungen, die von der anderen dynamisch installierten Komponente festgestellt wurden, die Komponente innerhalb der Umgebung durch eine neue Version der Komponente dynamisch ersetzt wird.
Verfahren nach einem der voranstehenden Ansprüche, wobei die dynamische Verarbeitung weiter das Überwachen des Ansprechens in Zusammenhang mit der Komponente durch die Erweiterung bei der Verarbeitung einschließt.
Verfahren nach Anspruch 6, bei dem weiter die Komponente als ein Inhalt liefernder Webdienst innerhalb der Umgebung verarbeitet wird und die Umgebung eine Aktiver-Objektraum-Serverplattform ist.
System zum Verbessern der Anpassbarkeit von Komponenten innerhalb einer Aktiver-Objektraum-Architekturumgebung, wobei die Umgebung auf Gruppen aktiver Objekte und ihrer locker gekoppelten Beziehung zueinander und ihren Wechselwirkungen miteinander beruht, welches aufweist: die Aktiver-Objektraum-Umgebung (301), ein Variable-Schicht-Objekt (302A), das dafür eingerichtet ist, die Verarbeitung einer ersten Komponente (302B) innerhalb der Aktiver-Objektraum-Umgebung (301) dynamisch zu erweitern, und einen Transponder (303), der dafür eingerichtet ist, das Variable-Schicht-Objekt (302A) zu erkennen, das Variable-Schicht-Objekt (302A) innerhalb der Umgebung auf der Grundlage des Typs des festgestellten Variable-Schicht-Objekts (302A) zu installieren und das Variable-Schicht-Objekt (302A) innerhalb der Aktiver-Objektraum-Umgebung zu verarbeiten.
System nach Anspruch 8, welches weiter aufweist: eine zweite Komponente (304), welche die Ausgabe von dem Variable-Schicht-Objekt (302A) innerhalb der Aktiver-Objektraum-Umgebung (301) feststellt und verarbeitet, wobei die zweite Komponente (304) dafür eingerichtet ist, zu bewirken, dass eine neuere Version der ersten Komponente (302B), ansprechend auf Bedingungen, die der Ausgabe von dem Variable-Schicht-Objekt (302A) zugeordnet sind, innerhalb des aktiven Objektraums (301) dynamisch installiert und verarbeitet wird.
System nach Anspruch 9, wobei die Ausgabe ein durch das Variable-Schicht-Objekt (302A) erzeugtes neues dynamisches Objekt ist.
System nach einem der Ansprüche 8 bis 10, wobei der Transponder (303) das Variable-Schicht-Objekt (302A) als mindestens eine von einer Voranfragekomponente und einer Nachantwortkomponente verarbeitet.
System nach einem der Ansprüche 8 bis 11, wobei die erste Komponente (302B) ein Webinhalts-Lieferdienst ist, auf den von einem Client über das Internet zugegriffen wird.
System nach Anspruch 12, wobei das Variable-Schicht-Objekt (302A) Antwortzeiten für Clientanfragen von der ersten Komponente (302B) dynamisch verfolgt.
System nach einem der Ansprüche 8 bis 13, wobei der aktive Objektraum (301) Anfragezustandsobjekte, die von Clients an die erste Komponente (302B) gerichtet werden, und Antwortzustandsobjekte, die von der ersten Komponente (302B) erzeugt und an die Clients gerichtet werden, aufweist und wobei der Transponder (303) die Anfrage- und Antwortzustandsobjekte für die Clients und die erste Komponente (302B) feststellt und übermittelt.
Computerlesbares Medium, auf dem sich Befehle befinden, wobei die Befehle, wenn sie durch einen Computer verarbeitet werden, das Verfahren nach einem der Ansprüche 1 bis 7 ausführen.
Medium nach Anspruch 15, welches weiter Befehle zum Verarbeiten einer zweiten Komponente ansprechend auf eine Ausgabe von der Erweiterung aufweist.
Medium nach Anspruch 16, welches weiter Befehle zum dynamischen Installieren und Verarbeiten einer neuen Version der Verarbeitungskomponente ansprechend auf von der zweiten Komponente empfangene Befehle aufweist.
Medium nach einem der Ansprüche 15 bis 17, welches weiter Befehle zum Darstellen der Ein- und Ausgabe in Zusammenhang mit der Verarbeitungskomponente und der Erweiterung als Objekte innerhalb einer Aktiver-Objektraum-Plattform aufweist.
Medium nach einem der Ansprüche 15 bis 18, wobei die Verarbeitung der Erweiterung weiter die Verarbeitung der Anfragen, bevor die Anfragen durch die Verarbeitungskomponente behandelt werden, und die Verarbeitung der Antworten, nachdem die Antworten von der Verarbeitungskomponente erzeugt wurden, aufweist.
Medium nach einem der Ansprüche 15 bis 19, welches weiter Befehle zum Verarbeiten der Komponente als ein Inhalt liefernder Webdienst, der über das Internet mit Clients kommuniziert, aufweist, wobei die Erweiterung die Leistungsfähigkeit des Webdienstes überwacht und in die Lage versetzt ist, Schlüssel-Webdienstkomponenten dynamisch durch neue Komponenten zu ersetzen.