EP2035927A1 - Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank - Google Patents

Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank

Info

Publication number
EP2035927A1
EP2035927A1 EP07729478A EP07729478A EP2035927A1 EP 2035927 A1 EP2035927 A1 EP 2035927A1 EP 07729478 A EP07729478 A EP 07729478A EP 07729478 A EP07729478 A EP 07729478A EP 2035927 A1 EP2035927 A1 EP 2035927A1
Authority
EP
European Patent Office
Prior art keywords
service
objects
services
proxy
bundles
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP07729478A
Other languages
English (en)
French (fr)
Inventor
Gerrit De Boer
Werner Praefcke
Bjoern Hornburg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP2035927A1 publication Critical patent/EP2035927A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44594—Unloading
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Definitions

  • the invention relates to a method for operating an application framework, which manages several bundles, wherein a bundle other bundles different services that are realized by service objects (1), offers and the services for releasing storage capacities are suspendable and a correspondingly formed database ,
  • An application framework provides a standardized environment for the administration and execution of programs, so-called applications
  • the applications have prescribed interfaces via which the application frame manages the applications and makes them available to the user.
  • the application frame provides a number of service functions that can be used by the applications.
  • the functions include eg mechanisms for configuration, life cycle and user management.
  • the application framework can be platform-independent, ie it runs, for example, in a Java runtime environment, can be configured dynamically and dynamically expanded by software components. He can also communicate with electronic components that are networked to the system. These may be Java-based components or other modules that be addressed with dedicated drivers, act.
  • An open application framework for the home and telematics sector is currently being standardized at the OSGi (Open Service Gateway initiative).
  • An OSGi system is a Java application framework within which various individual Java applications, so-called bundles, are connected and run. These bundles are jar files (Java archive), which satisfy a certain predetermined form, in order to be managed by the frame work. Central to this is the provision of interfaces for assuming defined conditions within the framework of lifecycle management. Their most important are installed, uninstalled, resolved and active. The communication between bundles happens by a bundle A
  • Services logs on the framework or application framework and a Bundle B requests this from the framework and claims.
  • an offered service will be registered with the framework directly when the bundle is registered and will remain available for the entire life of the OSGi system.
  • the bundle object providing this service remains instantiated throughout the time and occupies space (e.g., heap).
  • the present invention seeks to provide a method by which a large part of the bundle resources can be temporarily released to have such free storage capacity.
  • the core idea of the invention is that the various services of a
  • Bundles are no longer directly connected to other bundles via suitable interfaces or exchange data, but that a slim proxy object is interposed.
  • the service is logged on to the application frame in the form of this proxy object. Thus, the actual service can only be reached via this proxy object.
  • the proxy object contains all interfaces of the service.
  • the proxy object contains an interface for putting the service to be connected in a suspend or idle state and for releasing the service object.
  • it preferably contains software-configured mechanisms to restore the service when needed. In this case, it is preferably continued in the last stored state of the service.
  • the proxy object has the same interfaces as the service itself and can therefore be logged in instead of the original service on the application frame. Furthermore, the proxy object contains a reference or a reference to the actual service object.
  • a query is first made in the proxy object as to whether the corresponding service object exists, with one in the
  • the proxy object hibernates the service object.
  • the proxy object does not log off the service but keeps it for the rest of the system. This happens after the status has been saved. If necessary, superfluous data can also be deleted or the service object can be completely removed.
  • the interfaces of the service are accessed exclusively via the interfaces of the same name of the proxy object.
  • the service object may transmit its state to the proxy object for suspending the service and releasing the claimed resources to be later restored.
  • the advantage of the invention is that no additional hard disk space is needed to outsource currently unnecessary services, for example, in a swap process. Furthermore, the application frame is not burdened with the maintenance or operation of services not currently required, so that a processing and / or transmission capacity is not unnecessarily claimed.
  • a correspondingly formed database or provided with a corresponding software program computer according to claim 9 for the execution of the method on a device with the proxy objects described above can be generated to serve as an interface between the application frame and various services of a bundle.
  • the proxy objects can be implemented either in hardware and / or software in the database or the computer.
  • the associated service object may be instantiated in a low-priority thread according to claim 2. If the instantiation is not already prepared, you can restore a suspended one
  • Service is likely to lead to delays, especially if it occurs after a user has entered. This can be countered as follows: For example, when calling a menu, it is likely that one of the menu items will be called shortly after, so that the corresponding services of the individual menu items on it should be prepared to be restored. To do this, a low priority thread can be started in the background to prepare for the instantiation of the service object. In the optimal case, for example, when the corresponding menu item is called, the corresponding service object is already restored, so that it can run smoothly. A user in this case has a temporary
  • the priority of the associated thread can be increased in accordance with claim 3 in order to accelerate the restoration of the service object.
  • a current resource allocation as characterized in claim 4, monitored by a so-called manager of the application frame.
  • This identifies a need for additional main memory based on the current resource allocation.
  • those services that are registered but rarely and / or not used at all are identified. These services are subsequently caused to suspend the services in the associated proxy objects.
  • the manager may also predict an imminent use of a suspended service, for example, when a corresponding menu is invoked.
  • the manager can realize a persistent storage of service states.
  • a service state can be obtained beyond an application frame restart.
  • the manager is implemented in hardware and / or software in a database or an application framework.
  • Claim 5 described, application frame according to the OSGi standard, which has already been described above.
  • the proxy objects are instantiated instead of the service objects. This requires much less computing and storage capacity.
  • the proxy objects are registered as service providers in the system. The service object itself or the service is in the so-called suspend state and is only called when a request is made via the proxy object interface.
  • suspend state is only called when a request is made via the proxy object interface.
  • the associated thread of the service object already during the startup of the system such as an OSGi system, take place at the start of the bundle. This is again done with low priority, to influence the further startup process as little as possible.
  • Figure 1 is a block diagram of an application frame.
  • an application frame 100 is shown schematically. Via correspondingly configured interfaces, as indicated by the connecting lines, the application frame 100 is connected to a plurality of services realized by the service objects 1, which are in each case associated with one or different bundles. These service objects 1 usually require a large amount of computation and storage capacity when they are in the activated state. To reduce the required computing capacity unnecessary service objects 1 can also be disabled or suspended.
  • a proxy object 2 is now interposed between the service objects 1 and the application frame 100, which is in communication with the service objects 2 via a suitable interface. The service is logged on to the application frame via the proxy object 2.
  • the service is logged on to the application frame via the proxy object 2.
  • Objects 1 are suspended and are only instantiated in the case when a corresponding call is made via the associated proxy object 2. Since the proxy objects 2 are much slimmer, or require less storage capacity, the computing capacity of the entire system or a correspondingly formed database or a computer is much less burdened. To restore the service 1 or a service object, corresponding mechanisms are implemented in hardware and / or software in the proxy objects 2.
  • a manager 3 must be provided, e.g. is integrated in the application frames 100 in order to monitor the resource usage and, in particular, to suspend unneeded services 1.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Bei einem Verfahren zum Betreiben eines Applikationsrahmens (100), der mehrere Bundles verwaltet, wobei ein Bundle anderen Bundles verschiedene Dienste, die durch Dienst-Objekte (1) realisiert werden, anbietet und die Dienste zur Freigabe von Speicherkapazitäten suspendierbar sind, ist zur Verbesserung der Leistungsfähigkeit vorgeschlagen, dass die Dienst-Objekte (1) durch Proxy-Objekte (2) ergänzt werden und dadurch entfernt werden können. Weiterhin wird eine entsprechend ausgebildete Datenbank angegeben.

Description

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.

Claims

Ansprüche
1. Verfahren zum Betreiben eines Applikationsrahmens (100), 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, dadurch gekennzeichnet, dass die Dienst-
Objekte (1) durch Proxy-Objekte (2) ergänzt werden und dadurch entfernt werden können.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zum Wiederherstellen eines suspendierten oder noch nicht vorhandenen Dienstes das Dienst- Objekt (1) in einem Thread niedriger Priorität instanziiert wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Priorität des Threads heraufgesetzt wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass ein Manager (3) eine aktuelle Ressourcenbelegung überwacht.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der Applikationsrahmen (100) in einem OSGi-System betrieben wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass beim Starten eines Systems die Proxy-Objekte (2) instanziiert werden.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass ein Thread zur
Instanziierung eines Dienst-Objektes (2) im Verlauf des Startens eines Systems gestartet wird.
8. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Thread erst nach dem Anmelden aller Proxy-Objekte (2) am Applikationsrahmen (100) gestartet wird.
9. Datenbank mit einem Applikationsrahmen (100), 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 , dadurch gekennzeichnet, dass die Dienst- Objekte (1) durch Proxy-Objekte (2) ergänzbar und dadurch entfernbar sind.
EP07729478A 2006-06-19 2007-05-24 Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank Ceased EP2035927A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200610028012 DE102006028012A1 (de) 2006-06-19 2006-06-19 Verfahren zum Betreiben eines Applikationsrahmens sowie eine entsprechende Datenbank
PCT/EP2007/055047 WO2007147697A1 (de) 2006-06-19 2007-05-24 Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank

Publications (1)

Publication Number Publication Date
EP2035927A1 true EP2035927A1 (de) 2009-03-18

Family

ID=38268708

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07729478A Ceased EP2035927A1 (de) 2006-06-19 2007-05-24 Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank

Country Status (3)

Country Link
EP (1) EP2035927A1 (de)
DE (1) DE102006028012A1 (de)
WO (1) WO2007147697A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7761571B2 (en) * 2003-11-25 2010-07-20 Panasonic Corporation SIP service for home network device and service mobility
US8151281B2 (en) * 2004-01-09 2012-04-03 International Business Machines Corporation Method and system of mapping at least one web service to at least one OSGi service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007147697A1 *

Also Published As

Publication number Publication date
WO2007147697A1 (de) 2007-12-27
DE102006028012A1 (de) 2007-12-20

Similar Documents

Publication Publication Date Title
DE102012009482B4 (de) Funktional erweiterbares Fahrzeugsteuergerät und Verfahren zum Ergänzen der Funktionalität eines Fahrzeugsteuergeräts
EP0849666B1 (de) Verfahren zum Instantiieren einer versionsbehafteten Klasse
DE102010029209B4 (de) Verfahren zur dynamischen Verteilung von einem oder mehreren Diensten in einem Netz aus einer Vielzahl von Rechnern
DE19754640A1 (de) Verfahren zur Koordination von Netzwerkkomponenten
DE102010011658A1 (de) Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen
EP0525432A2 (de) Verfahren zur Änderung von Systemkonfigurationsdatensätzen in einem Fernmeldevermittlungssystem
EP0807883A2 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
WO2005073852A1 (de) Verfahren zum betreiben einer anordnung mehrerer rechner bei einem rechnerausfall
DE102009004726A1 (de) Systeme und Verfahren zum Verfolgen von Befehlszeigern und Datenzugriffen
DE102017100118A1 (de) Skalierbares Steuersystem für ein Kraftfahrzeug
WO2005055056A1 (de) Laden von software-modulen
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
DE102010011652A1 (de) Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen
DE102004030781A1 (de) SCADA-System und Verfahren zum Betreiben eines solchen Systems
EP0360135B1 (de) Verfahren zur Interruptverarbeitung in einer Datentverarbeitungsanlage
WO2005018193A1 (de) Verfahren und system zur ereignisübertragung
EP2035927A1 (de) Verfahren zum betreiben eines applikationsrahmens sowie eine entsprechende datenbank
EP4002098A1 (de) Verfahren zur bereitstellung der funktionalität von mehreren mikrodiensten und/oder der funktionalität von mehreren software-containern mittels einer cloud-infrastruktur, system, verwendungssystem, computerprogramm und computerlesbares medium
WO2020078835A1 (de) Steuergerät zur steuerung eines informationssystems
EP1428116A2 (de) Verfahren zur initialisierung einer verteilten software architektur und elektronisches system
DE2507405A1 (de) Verfahren und anordnung zum synchronisieren der tasks in peripheriegeraeten in einer datenverarbeitungsanlage
WO2009087056A1 (de) Verfahren zur verwaltung von rechenprozessen in einem dezentralen datennetz
EP1461699A2 (de) Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung
WO2021037378A1 (de) Verfahren zum automatischen markieren, cluster-arbeitsknoten, cluster, netzwerk, computerprogramm und computerlesbares medium
DE102005053275B4 (de) Hochverfügbares Computerverbundsystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090119

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090917

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20121108