Beschreibung

Titel

Verfahren zum Betreiben eines Applikationsrahmens sowie eine entsprechende

Datenbank

Technisches Gebiet

Die Erfindung betrifft ein Verfahren zum Betreiben eines Applikationsrahmens, der mehrere Bundles verwaltet, wobei ein Bündle anderen Bundles verschiedene Dienste, die durch Dienst-Objekte (1) realisiert werden, anbietet und die Dienste zur Freigabe von Speicherkapazitäten suspendierbar sind sind sowie eine entsprechend ausgebildete Datenbank.

Stand der Technik

Offene Standards für sogenannte Applikationsrahmen gewinnen zunehmend an Bedeutung. Ein Applikationsrahmen stellt eine standardisierte Umgebung für die Verwaltung und Ausführung von Programmen, sogenannte Applikationen, zur

Verfügung. Die Applikationen weisen vorgeschriebene Schnittstellen auf, über die der Applikationsrahmen die Applikationen verwaltet und für den Anwender bereitstellt. Der Applikationsrahmen stellt eine Reihe von Dienstfunktionen zur Verfügung, die von den Applikationen genutzt werden können. Zu den Funktionen gehören z.B. Mechanismen zum Konfigurations-, Life Cycle- und Nutzermanagement. Der Applikationsrahmen kann plattformunabhängig sein, d.h. er läuft z.B. in einer Java-Laufzeitumgebung, dynamisch konfigurierbar und um Softwarekomponenten dynamisch erweiterbar. Er kann darüber hinaus mit elektronischen Komponenten kommunizieren, die mit dem System vernetzt sind. Hierbei kann es sich um Java-basierte Komponenten oder um andere Module, die

mit dedizierten Treibern angesprochen werden, handeln. Ein offener Applikationsrahmen für den Heim- und Telematikbereich wird derzeit bei der OSGi (Open Service Gateway initiative) standardisiert.

Die im folgenden beschriebene Erfindung wird am Beispiel eines solchen OSGi-Systems beschrieben; sie ist allerdings im Zusammenhang mit jedem Applikationsrahmen anwendbar, d.h. sie ist nicht auf Applikationsrahmen nach OSGi festgelegt.

Ein OSGi-System ist ein Java Applikationsframework, innerhalb dessen verschiedene einzelne Java- Anwendungen, sogenannte Bundles miteinander in Verbindung stehen und ablaufen. Diese Bündle sind jar-Dateien (Java archive), die einer bestimmten vorgegebenen Form genügen, um sich durch das Framewerk verwalten zu lassen. Zentral ist die Bereitstellung von Schnittstellen, um im Rahmen eines Lifecycle Management festgelegte Zustände einzunehmen. Deren wichtigste sind installed, uninstalled, resolved und active. Die Kommunikation zwischen Bundles geschieht, indem ein Bündle A

Dienste (Services) am Framework bzw. Applikationsrahmen anmeldet und ein Bündle B diese vom Framework anfordert und in Anspruch nimmt.

üblicherweise wird ein angebotener Dienst direkt bei der Anmeldung des Bundles am Framework angemeldet und bleibt über die gesamte Laufzeit des OSGi-Systems vorhanden. Entsprechend bleibt das Bundle-Objekt, das diesen Dienst bereitstellt, über die gesamte Zeit instanziiert und belegt Speicherplatz (z.B. heap).

Bei einer Vielzahl angebotener Dienste, die nicht alle zur gleichen Zeit in Anspruch genommen werden, muss dennoch der Speicher für alle Bundles bereitgehalten werden, auch wenn sie aktuell nicht verwendet werden.

Die vom Framework angebotenen Mechanismen, ein Bündle bei NichtVerwendung des Dienstes zu entfernen, so dass sein Speicherplatz freigegeben werden kann, laufen auf eine komplette Deinstallation des Bundles hinaus, die mit einem Abmelden des Dienstes einhergeht.

Erläuterung der Erfindung

Ausgehend von diesem Stand der Technik liegt der Erfindung die Aufgabe zugrunde, ein Verfahren zu schaffen, mit dem ein Großteil der Bundle-Ressourcen vorübergehend freigegeben werden können, um derart über freie Speicherkapazität zu verfügen.

Weiterhin soll eine entsprechend ausgebildete Datenbank angegeben werden.

Diese Aufgaben werden durch die Merkmale der Ansprüche 1 und 9 gelöst.

Der Kerngedanke der Erfindung besteht darin, dass die verschiedenen Dienste eines

Bundles nicht mehr unmittelbar über geeignete Schnittstellen mit anderen Bundles in Verbindung stehen bzw. Daten austauschen, sondern dass ein schlankes Proxy-Objekt dazwischengeschaltet ist. Der Dienst wird in Form dieses Proxy-Objekts am Applikationsrahmen angemeldet. Somit ist der eigentliche Dienst nur über dieses Proxy- Objekt zu erreichen. Das Proxy-Objekt enthält dazu alle Schnittstellen des Dienstes.

Darüberhinaus enthält das Proxy-Objekt zum Einen eine Schnittstelle, um den zu verbindenden Dienst in einen Suspend- oder Ruhezustand zu versetzen und um das Dienstobjekt wieder frei zu geben. Zum Anderen enthält es vorzugsweise softwaremäßig ausgestaltete Mechanismen, um den Dienst bei Bedarf wieder herzustellen. Dabei wird vorzugsweise im letzten, abgespeicherten Zustand des Dienstes dieser fortgesetzt.

Weiterhin sind an dem Dienst zusätzliche Schnittstellen vorgesehen, die ein Sichern der aktuell relevanten Zustände, sowie ein Wiederherstellen derselben ermöglichen.

Das Proxy-Objekt verfügt über die gleichen Schnittstellen wie der zu verbindende Dienst selbst und kann somit anstelle des ursprünglichen Dienstes am Applikationsrahmen angemeldet werden. Weiterhin enthält das Proxy-Objekt eine Bezugnahme oder eine Referenz auf das eigentliche Dienstobjekt.

Soll der Dienst in Anspruch genommen werden, erfolgt in dem Proxy-Objekt zunächst eine Abfrage, ob das entsprechende Dienst-Objekt existiert, wobei eine im

Nachfolgenden beschriebene Instanziierung aufgerufen sowie bei vorheriger Suspendierung der ursprüngliche Zustand des Dienstes wieder hergestellt werden kann.

- A -

SoIl der Dienst suspendiert werden, wird im Proxy-Objekt dessen Status lokal gespeichert. Das Proxy-Objekt versetzt das Dienst-Objekt in den Ruhezustand. Das Proxy-Objekt meldet den Dienst nicht ab sondern hält ihn für das restliche System aufrecht. Dies erfolgt nachdem dessen Status gespeichert wurde. Gegebenenfalls können überflüssige Daten auch gelöscht oder das Dienst-Objekt vollständig entfernt werden.

Auf die Schnittstellen des Diensts wird dabei ausschließlich über die gleichnamigen Schnittstellen des Proxy-Objekts zugegriffen. Das Dienst-Objekt kann zum Suspendieren des Dienstes und Freigeben der beanspruchten Ressourcen seinen Zustand an das Proxy- Objekt übermitteln, um später wieder hergestellt zu werden.

Der Vorteil der Erfindung besteht darin, dass kein zusätzlicher Festplatten-Speicherplatz benötigt wird, um momentan nicht notwendige Dienste beispielsweise in einem Swap- Vorgang auszulagern. Weiterhin wird der Applikationsrahmen nicht mit dem Aufrechterhalten oder Bedienen von momentan nicht benötigten Diensten belastet, so dass eine Verarbeitungs- und/oder übertragungskapazität nicht unnötig beansprucht wird.

Eine entsprechend ausgebildete Datenbank bzw. ein mit einem entsprechenden Softwareprogramm versehener Computer verfügt nach Anspruch 9 zur Ausführung des Verfahrens über eine Einrichtung, mit der vorstehend beschriebene Proxy-Objekte erzeugt werden können, um als Schnittstelle zwischen dem Applikationsrahmen und verschiedenen Diensten eines Bundles zu dienen. Dabei können die Proxy-Objekte entweder hard- und/oder softwaremäßig in der Datenbank bzw. dem Computer implementiert werden.

Um das Wiederaufrufen eines suspendierten Diensts zu beschleunigen bzw. wenn der Dienst suspendiert und wiederhergestellt wird und das Dienst-Objekt entfernt und wiederum instanziiert/erzeugt wird, kann das zugehörige Dienst-Objekt entsprechend dem Anspruch 2 in einem Thread niedriger Priorität instanziiert werden. Wird das Instanziieren nicht bereits vorbereitet kann das Wiederherstellen eines suspendierten

Diensts leicht zu Verzögerungen führen, insbesondere wenn dies nach einer Eingabe eines Nutzers erfolgt. Dem kann folgendermaßen begegnet werden: Beispielsweise beim Aufrufen eines Menüs ist es wahrscheinlich, dass einer der Menüpunkte kurz nachfolgend aufgerufen wird, so dass die entsprechenden Dienste der einzelnen Menüpunkte darauf

vorbereitet sein sollten, wieder hergestellt zu werden. Hierzu kann im Hintergrund ein Thread niedriger Priorität gestartet werden, um die Instanziierung des Dienst-Objekts vorzubereiten. Im Optimalfall, beispielsweise wenn der entsprechende Menüpunkt aufgerufen wird, ist das entsprechende Dienst-Objekt bereits wieder hergestellt, so dass es übergangslos ablaufen kann. Ein Nutzer hat in diesem Fall von einer vorübergehenden

Suspendierung des Dienstes nichts bemerkt.

Falls das entsprechende Dienst-Objekt noch nicht wieder hergestellt worden sein sollte, kann entsprechend dem Anspruch 3 die Priorität des zugehörigen Threads heraufgesetzt werden, um das Wiederherstellen des Dienst-Objekts zu beschleunigen.

Vorzugsweise wird eine aktuelle Ressourcenbelegung, wie im Anspruch 4 gekennzeichnet, durch einen sogenannten Manager des Applikationsrahmens überwacht. Dieser identifiziert anhand der aktuellen Ressourcenbelegung einen Bedarf an zusätzlichem Hauptspeicher. Gleichzeitig werden diejenigen Dienste, die zwar angemeldet aber selten und/oder momentan überhaupt nicht benutzt werden, identifiziert. Bei diesen Diensten wird nachfolgend in den zugehörigen Proxy-Objekten das Suspendieren der Dienste veranlasst. Mit dem Manager kann auch eine nahe bevorstehende Verwendung eines suspendierten Dienstes vorausberechnet werden, beispielsweise wenn ein entsprechendes Menü aufgerufen wird. Somit kann die

Wiederherstellung der zugehörigen Dienstobjekte vorab ausgelöst werden. Ebenso kann der Manager eine persistente Speicherung von Dienstzuständen realisieren. Somit kann ein Dienstzustand über einen Applikationsrahmen-Neustart hinaus erhalten werden. Hierzu ist lediglich eine Erweiterung der Schnittstelle im Proxy-Objekt notwendig, mit der ein Austausch des Zustande zwischen dem Proxy-Objekt und dem Manager möglich ist. Der Manager ist hierfür hard- und/oder softwaremäßig in einer Datenbank bzw. einem Applikationsrahmen implementiert.

Es versteht sich, dass im Rahmen der Erfindung beliebige Applikationsrahmen erfindungsgemäß ausgestaltet sein können. Bevorzugt sind dies jedoch, wie im

Anspruch 5 beschrieben, Applikationsrahmen nach dem OSGi-Standard, der bereits vorstehend beschrieben wurde.

Zur Beschleunigung des Hochfahrens eines Computersystems, das mit einem entsprechenden Applikationsrahmen versehen ist, ist im Anspruch 6 vorgeschlagen, dass beim Starten des Systems die Proxy-Objekte instanziiert werden anstelle der Dienst- Objekte. Dies erfordert wesentlich weniger Rechen- und Speicherkapazität. Auch werden die Proxy-Objekte als Diensteanbieter im System angemeldet. Das Dienst-Objekt selbst bzw. der Dienst befindet sich im sogenannten Suspend-Zustand und wird erst aufgerufen, wenn über die Schnittstelle Proxy-Objekt eine Anforderung erfolgt. Dabei ist es allerdings nicht zu vermeiden, dass bei einem beliebigen Diensteaufruf eine Verzögerung auftreten kann, beispielsweise weil der Dienst erst instanziiert werden muss.

Hierzu kann, wie im Anspruch 7 angegeben, der zugehöriger Thread des Dienst-Objekts bereits im Verlauf des Hochfahrens des Systems, beispielsweise eines OSGi-Systems, beim Start des Bundles erfolgen. Dies geschieht wiederum mit niedriger Priorität, um den weiteren Startvorgang möglichst wenig zu beeinflussen.

Alternativ kann entsprechend dem Anspruch 8 das Starten des Threads erst nachdem der Applikationsrahmen gestartet wurde und alle Proxy-Objekte mit ihren Diensten am Applikationsrahmen angemeldet sind, vorgenommen werden.

Kurzbeschreibung der Zeichnung

Eine Ausführungsform der Erfindung wird nachstehend anhand der Zeichnung näher erläutert. Es zeigt in rein schematischer Darstellung:

Figur 1 ein Blockschaltbild eines Applikationsrahmens.

In Figur 1 ist ein Applikationsrahmen 100 schematisch dargestellt. über entsprechend konfigurierte Schnittstellen, wie durch die Verbindungslinien angedeutet, steht der Applikationsrahmen 100 mit mehreren Diensten, realisiert durch die Dienst-Objekte 1, die jeweils zu einem oder verschiedenen Bundles zugehörig sind, in Verbindung. Diese Dienst-Objekte 1 erfordern üblicherweise eine große Rechen- und Speicherkapazität, wenn sie im aktivierten Zustand sind. Zur Verringerung der benötigten Rechenkapazität können nicht benötige Dienst-Objekte 1 auch deaktiviert oder suspendiert werden.

Erfindungsgemäß wird nun zwischen die Dienst-Objekte 1 und den Applikationsrahmen 100 jeweils ein Proxy-Objekt 2 dazwischen geschaltet, das über eine geeignete Schnittstelle mit den Dienst-Objekten 2 in Verbindung steht. Der Dienst wird über das Proxy-Objekt 2 am Applikationsrahmen angemeldet. Dabei können die Dienst-

Objekte 1 suspendiert sein und werden in dem Fall erst instanziiert wenn über das zugehörige Proxy-Objekt 2 ein entsprechender Aufruf erfolgt. Da die Proxy-Objekte 2 wesentlich schlanker sind, bzw. weniger Speicherkapazität beanspruchen, ist die Rechenkapazität des Gesamtsystems bzw. einer entsprechend ausgebildeten Datenbank oder eines Computers wesentlich weniger belastet. Zum Wiederherstellen des Dienstes 1 bzw. eines Dienst-Objekts sind in den Proxy-Objekten 2 entsprechende Mechanismen hard- und/oder softwaremäßig implementiert.

Zusätzlich muss ein Manager 3 vorgesehen sein, der z.B. in den Applikationsrahmern 100 integriert ist, um die Ressourcenbelegung zu überwachen und insbesondere um nicht benötigte Dienste 1 zu suspendieren.