-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren zum Betreiben
einer Datenverarbeitungseinrichtung und insbesondere auf ein Verfahren zum
Betreiben einer solchen Einrichtung, um es der Einrichtung zu ermöglichen,
zu entscheiden, welches aus der Anzahl von Plug-ins das am besten
geeignete ist für
die Eigenschaften, die durch eine anfordernde Anwendung auf der
Einrichtung spezifiziert werden.
-
Der
Ausdruck Datenverarbeitungseinrichtung, wie er hier verwendet wird,
soll weitreichend ausgelegt werden, um jegliche Form einer Datenverarbeitungseinrichtung
abzudecken, und beinhaltet Datenaufzeichnungseinrichtungen jeglicher
Form, Computer jeglicher Art und Form, einschließlich tragbarer und Personal-Computer
und Kommunikationseinrichtungen jeglicher Form, einschließlich Mobiltelefone,
Smartphones, Kommunikatoren, die Kommunikationen, Bildaufnahmen
und/oder eine Wiedergabe und eine Computer-Funktionalität innerhalb einer einzigen
Einrichtung und anderen Formen von drahtlosen und verdrahteten Informationseinrichtungen
kombiniert.
-
Ein
Plug-in kann definiert werden als ein ersetzbares Objekt ausführbaren
Codes, das spezielle Services für
eine lose verbundene Anwendung bereitstellt, die das Plug-in während der
Laufzeit laden oder verwerfen kann. Plug-ins werden im Allgemeinen
als dynamische Link-Bibliotheken
bzw. dynamic link libraries (DLLs) oder vergleichbare Arten von
Modulen geladen, die innerhalb des gleichen Prozessraumes wie die
Anwendung, die sie aufruft, ablaufen, obwohl sie auch als separate
Prozesse erzeugt oder ablaufen können.
-
Plug-ins
werden weithin in vielen Betriebssystemen und von vielen Anwendungen
verwendet. Die wichtigsten Vorteile dieser Technologie sind:
- • Anwendungen,
die in der Lage sind, Plug-ins zu verwenden, sind inhärent erweiterbar,
da Plug-in-Module
hinzugefügt
oder ersetzt werden können,
wenn neue Eigenschaften erforderlich sind
- • Betriebscode
für Plug-ins
wird durch Anwendungen nur auf Anforderung geladen, was es Programmen
ermöglicht,
geringere Anforderungen bezüglich
des Speichers der Einrichtung zu haben und schneller gestartet zu
werden.
-
Diese
Technologie ist den meisten Nutzern von Datenverarbeitungseinrichtungen
durch das weitverbreitete Einfügen
von Plug-ins in Webbrowsern vertraut, wie zum Beispiel Microsoft
Internet Explorer und Netscape, was Gegenstand des
US-Patents 5 838 906 (allgemein als
Eolas-Patent bekannt) war. Obwohl sie auch die Basis sind für die Verwendung
von Java-Applikationen
in Browsern, besteht die allgemeinste Manifestierung der Verwendung
von Plug-ins darin, daß Browser-Anwendungen
sich auf sie stützen,
um bestimmte Arten von Inhalt zu verteilen. Die Verwendung von Plug-ins in Bezug auf
Multimedia-Dateien ist besonders verbreitet.
-
Da
Plug-ins definitionsgemäß inhärent unabhängig von
den Anwendungen sind, die sie laden, ist es für alle Systeme, die eine Plug-in-Technologie
verwenden, notwendig, Mechanismen bereitzustellen, durch die die
Anwendungen von verfügbaren Plug-ins
in Kenntnis gesetzt werden und auf das Verfahren zum Laden oder
Aufrufen derselben hingewiesen werden.
-
Frühe Verfahren,
wie zum Beispiel jene, die durch WindowsTM-Anwendungen
verwendet wurden, die ausschließlich
von der OLE-Technologie von Microsoft abhängen, erfordern fest programmierte Links
zu den Namen und den Positionen der Plug-ins. Dies wird als unbefriedigend
betrachtet, da es nur eine Plug-in-Ersetzung erlaubt und es erfordert,
daß die
Host-Anwendung aktualisiert
wird, um das Hinzufügen
von extra Plug-in-Komponenten zu erlauben.
-
Nachfolgende
Verfahren speichern Namen und Positionen der Plug-ins in einem Register
oder einer Plug-in-Datenbank;
dies wird als besser angesehen als das Festprogammieren von Namen,
da es sowohl flexibel als auch erweiterbar ist. Für eine maximale
Flexibilität
und um es zu ermöglichen,
daß das gleiche
Plug-in durch verschiedene Anwendungen verwendet werden kann, sind solche
Register oder Datenbanken typischerweise eher systemweit als Anwendungs-spezifisch.
Es ist darum verbreitet, einen oder mehrere Zwischenebenen bereitzustellen, zwischen
Anwendung und deren Plug-ins, die gemeinsame Services bereitzustellen,
einschließlich:
- • Der
Position von geeignet registrierten Plug-ins für Anwendungen
- • Entscheiden,
welches Plug-in unter den potentiellen Plug-in-Kandidaten aufgerufen
werden soll
- • Instanziieren
des Plug-ins im Auftrag des Anwendung
-
Das
Component-Object-Model (COM) von Microsoft ist ein gut bekanntes
Verfahren zum Ausführen
desselben, wobei das Betriebssystem eine Zwischenebene bereitstellt,
die das Plug-in-Modul in dem Register lokalisiert, die Instanziierung
bearbeitet und dann Aufrufe der Anwendung zu der Plug-in-Instanz
umleitet. COM wurde entwickelt, so daß Software-Entwickler neue
Zusatzanwendungen in existierende Anwendungen hineinstecken können, ohne ein
Neubau der existierenden Anwendung zu erfordern. COM-Komponenten sollten
darum als austauschbare Plug-ins konzipiert werden, falls die COM-Komponente
eine lokale Im-Prozess-DLL oder ein Fern-Server-Ausführungselement
ist.
-
WO 00/67114 im Namen von
Sun Microsystems beschreibt „A
System and Method for discovering and binding a program object", wobei eine Zwischenebene
ein Register verwendet, um ein Plug-in zu entdecken und zu instanziieren,
und eine Referenz zu der Instanz an die Anwendung zurückgibt, damit
sie mit ihr direkt kommunizieren kann.
-
US 6 279 030 beschreibt
eine Technik, in der mehrere Versionen einer Programm-Komponente verfügbar sind
und eine spezielle Version auf Grundlage von gegenwärtigen Kennzeichen-Werten
dynamisch ausgewählt
und heruntergeladen werden kann.
-
Systemweite
Verfahren wie diese werden oft mit weniger generischen Zwischenebenen
kombiniert, wie zum Beispiel Anwendungs-spezifische Plug-in-Verwalter
oder spezialisierte Server, die es erlauben, Plug-ins zu verwenden,
um mehrere simultane Anwendungen zu betreuen.
-
Ein
Bedenken im Bezug auf die gegenwärtige
Technologie besteht darin, daß,
wenn es eine Zahl von Plug-in-Kandidaten
gibt, die Auswahl, welches Plug-in das am besten geeignete ist,
ein in hohem Maße
technischer Prozess sein kann, die potentiell komplexe Entscheidungs-Intelligenz
oder -Algorithmen erfordert, um zu einer optimalen Auswahl zu kommen.
-
Jeglicher
Zugang, der darauf basiert, daß die dazwischen
liegenden Einheiten eine solche Entscheidung trifft, würde es erfordern,
möglicherweise komplexe
Zustands-Information
aufrecht zu halten, und Teil spezialisierter Information zu sein.
Davon abhängend,
wie generisch die dazwischen liegenden Einheiten sind, kann dies
infolge der Einbeziehung von Routinen für alle Arten von existierenden Plug-ins
zu einem unnötig
aufgeblähten Code
führen. Architektonisch
steht dies im Konflikt mit der Rolle der generischen Service-Ebenen,
die sich darauf beschränken
sollten, allgemeine Services wie das Auffinden und die Intanziierung
von Plug-ins bereitzustellen. Somit werden sich wahrscheinlich alle
Typen von dazwischen liegenden Einheiten als unzureichend erweisen,
um neue Arten von Plug-ins zu behandeln, die möglicherweise in der Zeit noch
nicht bekannt waren, in der die Zwischenebene geschrieben wurde.
-
Ein
spezieller Fall, der diese Bedenken illustriert, ist die Implementierung
von Standortbezogenen Services bzw. Location-Based-Services (LBS) auf
einer drahtlosen Informationseinrichtung wie zum Beispiel ein Mobiltelefon.
LBS beinhaltet Positions-basierte Information, Positions-sensitive
Gebührenerfassung,
Notfall-Services und Positionserfassung. Alle diese Kennzeichen
hängen
davon ab, daß das
Mobiltelefon in der Lage ist mitzuteilen, wo es ist (Positionsbestimmung).
Es gibt jedoch viele verschiedene Wege zum Erhalten von Positions-Information.
Das am meisten verbreitete System verwendet das Global-Positioning-System
(GPS). Es gibt auch alternative Technologien, die verwendet werden,
viele von ihnen basieren auf einem Netzwerk, wie zum Beispiel Zellen-Triangulation.
Es ist auch bekannt, daß das
vorhandenen Verfahren zum Erhalten von Positions-Information in der Zukunft erweitert wird;
zum Beispiel wird das Europäische
Galileo-Projekt schließlich
eine Alternative zu GPS bereitstellen.
-
Die
Sachverständigen
in der Technik werden erkennen, daß ein Plug-in-Design zum Implementieren
von LBS, das es einer Anwendung erlaubt, irgendein Verfahren zum
Erhalten von Positions-Information zu verwenden, äußerst dienlich
wäre und
signifikante Vorteile bereitstellen würde. Dies ist der Fall, da:
- • alle
oben erwähnten
Positions-Techniken identische Informations-Typen bereitstellen
- • sie
alle geschrieben werden können,
um der gleichen Programmierschnittstelle bzw. Application-Programming-Interface
(API) zu entsprechen
- • eine
Anwendung, im Allgemeinen, nur eine von ihnen verwenden muss.
-
Die
obigen Verfahren zum Erhalten von Positionen haben jedoch signifikant
unterschiedliche Merkmale, wie zum Beispiel Genauigkeit, benötigte Leistung,
Kosten für
den Nutzer und die benötigte Zeit
zum Erhalten einer Positionsfeststellung. Die Wahl, welche aufzurufen
ist, ist daher komplex, wobei sie von einer Anzahl von Faktoren
abhängt.
Keine Zwischenebene zum Aufrufen von Plug-ins würde in der Lage sein, alle
diese zu berücksichtigen.
Im schlimmsten Fall würde
eine Unfähigkeit,
eine sinnvolle Entscheidung zu treffen, wie Positions-Information
zu erhalten ist, darin resultieren, einen einfachen „Last-fit"-Mechanismus zu verwenden,
wobei das zuletzt installierte, mit der entsprechenden API-konforme
Anpassungs-Plug-in instanziiert wird.
-
Es
ist daher ersichtlich, daß es
zur Zeit keinen flexiblen und erweiterbaren Weg zum automatischen
Bestimmen gibt, welches Plug-in in Situationen verwendet werden
soll, in denen mehrere Plug-ins zur Verfügung stehen, wobei jedes von
ihnen eine bestimmte Aufgabe durchführen kann, aber in einer hinreichend
unterschiedlichen Art, um es vorteilhaft zu machen, ein bestimmtes
Plug-in für
einen bestimmten Fall auszusuchen.
-
Demnach
ist es ein Gegenstand der vorliegenden Erfindung, ein verbessertes
Verfahren zum Auswählen
von Plug-ins in einer Datenverarbeitungseinrichtung bereitzustellen.
-
Entsprechend
eines ersten Aspekts der vorliegenden Erfindung wird ein Verfahren
bereitgestellt, das es ermöglicht,
eine auf einer Datenverarbeitungseinrichtung laufende Software-Anwendung
zu veranlassen, das am besten geeignete Code-Modul aus einem Satz
von Code-Modulen
auszuführen,
wobei das Verfahren umfasst
- a) Identifizieren
von Merkmalen oder Eigenschaften, die das am besten geeignete Code-Modul
besitzen sollte;
- b) Weiterleiten der Merkmale oder Eigenschaften an jedes der
möglichen
funktionell kompatiblen Code-Module, entweder direkt oder über eine oder
mehrere Zwischenebene;
- c) Verwenden der Code-Module, eine deterministische Berechnung
für jedes
auszuführen, über wie
gut sie mit den Merkmalen oder Eigenschaften übereinstimmen, und das Ergebnis
als eine numerische Punktzahl zurückzugeben, entweder an die
Software-Anwendung oder an eine Zwischenebene; und
- d) Ausführen
des Moduls mit der besten Punktzahl, entweder direkt durch die Software-Anwendung
oder über
eine durch eine Zwischenebene durchgeführte Instanziierung.
-
Entsprechend
eines zweiten Aspekts der vorliegenden Erfindung wird eine Datenverarbeitungseinrichtung
bereitgestellt, die eingerichtet ist, um in Übereinstimmung mit dem Verfahren
des ersten Aspekts zu arbeiten.
-
Entsprechend
eines dritten Aspekts der vorliegenden Erfindung wird ein Betriebssystem
bereitgestellt, das eine Datenverarbeitungseinrichtung entsprechend
des zweiten Aspekts veranlasst, in Übereinstimmung mit dem Verfahren
des ersten Aspekts zu arbeiten.
-
Das
Symbian-OSTM-Betriebssystem für Mobiltelefone,
hergestellt durch Symbian Software Ltd. in London, hat, seit seiner
ersten Ausgabe im Jahr 1997, ausgiebigen Gebrauch von Plug-ins gemacht. Während diese
Plug-ins traditionell auf polymorphen DLL basieren, die durch den
oben beschriebenen Typ einer Zwischenebene geladen werden, wird
eine zunehmende Zahl vorgeschlagen als ausführbare Einheiten bzw. Executables
zu implementieren, die in ihrem eigenen Prozessraum laufen.
-
Diese
Erfindung kann auf beide Plug-in-Typen angewendet werden.
-
Während die
hier beschriebene Erfindung beschreibt, wie das oben umrissene Problem
im Zusammenhang mit LBS gelöst
wird, wird es von den Sachkundigen in der Technik leicht anerkannt
werden, daß die
der Erfindung zu Grunde liegenden Prinzipien in gleichem Maße auf jegliche
Situation anwendbar ist, in der eine Auswahl zwischen möglichen Plug-ins
getroffen werden muss. Somit wird der Fall von LBS nur für einen
darstellenden Zweck verwendet, und soll nicht ausgelegt werden als
ein Beschränken
des Bereiches oder der Anwendbarkeit der Erfindung in anderen Bereichen.
In gleichem Maße
wird das hier beschriebene Symbian-OSTM-Betriebssystem
auch nur für
einen darstellenden Zweck verwendet und soll ebenfalls nicht ausgelegt
werden als ein Beschränken
des des Bereiches oder der Anwendbarkeit der Erfindung auf andere
Betriebssysteme, wie es für
Personen, die mit dieser Technik vertraut sind, ersichtlich sein
wird.
-
Das
Location-Based-Services-Positierungs-Subsystem in dem Symbian-OSTM-Betriebssystem setzt eine Client/Server-Framework-Architektur
ein, um es mehreren Clients (Anwendungen) zu erlauben, periodische
Aktualisierungen der Einrichtungsposition von mehreren Positions-Technologien abzurufen.
-
Diese
Architektur umfasst einen Singleton-Positions-Server, der Technologie-unabhängig ist,
und auf den durch eine konsistente Programmierschnittstelle bzw. Application-Program-Interface (API)
zugegriffen wird, die eine Technologie-unabhängige Abstraktionsebene bereitstellt,
die für
jegliche der früher
beschriebenen Verfahren geeignet ist.
-
Der
Server verwaltet den Zugriff auf Positions-Technolgie-spezifische Module. Diese
Module werden als Plug-ins implementiert, die dem Betriebssystem
dynamisch hinzugefügt
oder von ihm entfernt werden können,
und die durch den Positions-Server erfasst und verwendet werden,
ohne daß der
Client-Server es wissen muss.
-
Wenn
ein Client sich mit dem Positions-Server verbindet, kann er ein
Kriterien-Objekt anbieten, um gewünschte oder erforderliche Eigenschaften
der zu verwendenden Positions-Technologie zu spezifizieren. Diese
Kriterien-Objekte
werden in der Abstraktions-API spezifiziert und erlauben es, Servicequalitäts- bzw.
Quality of Service (QoS) Parameter, wie zum Beispiel horizontale
Genauigkeit, vertikale Genauigkeit, Zeit bis zur ersten Behebung,
zu spezifizieren. Andere Parameter von potentiellem Interesse für die Anwendung
können
auch spezifiziert werden, wie zum Beispiel Kosten und Leistungsverbrauch.
-
Mit
der vorliegenden Erfindung iteriert der Positions-Server durch die
verfügbaren
Plug-ins, wobei er jedes einzelne nacheinander fragt, ob es besser
mit den durch den Client spezifizierten Kriterien übereinstimmt,
als das vorhergehende Plug-in. Der Positions-Server bemerkt selbst
nicht, wie die Auflösung
des „besser/schlechter" von Plug-in zu Plug-in ausgeführt wird.
-
Der
mit dieser Anmeldung beschriebene Zugang basiert darauf, daß jedes
Plug-in in der Lage ist, eine deterministische Berechnung einer
Punktzahl auszuführen,
die angibt, wie gut das Plug-in zu den spezifizierten QoS-Kriterien
passt. Die Berechnung verwendet die gegenwärtigen Werte der Kennzeichen,
wie zum Beispiel „Zeit
bis zur nächsten
Behebung", die jedem
Plug-in bekannt sind. Die Berechnung ist deterministisch und jedes
Plug-in folgt denselben Regeln, um zu gewährleisten, daß man immer zu
einer fairen und korrekten Entscheidung kommt. Viele verschiedene
Algorithmen oder Verfahren sind für die endgültige Auswahl möglich, wie
zum Beispiel:
- 1. Die Server-Komponente fragt
jedes Plug-in ab und behält
die Übersicht,
welches Plug-in die höchste
(d. h. die am besten geeignete) Punktzahl zurückgibt, und sobald alle Plug-ins
abgefragt wurden, wählt
sie das Plug-in mit der höchsten Punktzahl
aus.
- 2. Die Server-Komponente fragt jedes Plug-in der Reihe nach
ab, wobei die bisher höchste
Punktzahl an jedes Plug-in eingereicht wird. Wenn das Plug-in diese
Punktzahl nicht „schlagen" kann, entfernt es
sich selbst von der Berücksichtigung; wenn
es die Punktzahl schlagen kann, informiert es dann den Server, daß es nun
die höchste Punktzahl
hat.
-
Das
erste dieser Verfahren erfordert einiges begrenztes Entscheiden
durch die Server-Komponente, das zweite ist eine wahre Übertragung
der Entscheidung, so daß der
Server überhaupt
nicht involviert ist. Diese Erfindung ist jedoch nicht auf diese zwei
Verfahren beschränkt
und wird mit jeglichem Algorithmus arbeiten, den die Sachkundigen
in der Technik entwickeln können.
-
Die
Erfindung beruht auf Plug-ins, die sich korrekt verhalten, wenn
deren Punktzahl berechnet wird (d. h. den veröffentlichten Regeln für die deterministische
Berechnung folgend). Dies wird nicht als Mangel der involvierten
Prinzipien betrachtet und führt
kein extra Risiko ein, da eine Anwendung in allen Fällen darauf
vertrauen muss, daß Plug-ins,
die sie aufruft, sich gutartig verhalten. Wenn es aber entschieden
wird, daß nicht
allen Plug-ins blind vertraut werden soll, ist es immer noch möglich, das
Verhalten jedes einzelnen zu einem geeigneten Punkt zu überprüfen, wie
zum Beispiel, wenn das Plug-in installiert, getestet, verifiziert
oder unterzeichnet wird. Alternativ können Anwendungen ein dynamisches Überprüfen des
Verhalten eines Plug-ins während der
Laufzeit durchführen,
durch eine Überwachungseinheit
oder einen anderen Mechanismus.
-
Es
wird angesehen, daß die
vorliegende Erfahrung die folgenden exemplarischen Vorteile bereitstellt:
Sie
ist anwendbar auf alle Architekturen, in denen mehrere, vergleichbare
Services bereitstellende Plug-ins für Anwendungen zur Verfügung stehen.
-
Sie
entfernt den Bedarf an potentieller Entscheidungs-Intelligenz in allen
Zwischenebenen der Anwendungs- und Betriebssystem-Plug-in-Architekturen.
-
Sie
lehrt wie die Verantwortung zum Optimieren der Auswahl von Plug-ins
effektiv an die Plug-ins selbst übertragen
werden kann.
-
Sie
erzwingt ein gutes Design durch ein Umgehen einer Einführung von
unnötigen
Abhängigkeiten
zwischen Zwischen-Einheiten bzw. intermediaries und Plug-in-Modulen, für die sie
einen Service bereitstellen.
-
Diese
Erfindung spezifiziert ein Verfahren und eine Einrichtung, die die
Auflösung
ermöglicht, welches
aus einem Satz von zur Verfügung
stehenden Plug-ins am besten geeignet ist gegenüber einem Satz von erwünschten
Eigenschaften, die durch die anfordernde Anwendung spezifiziert
werden.
-
Die
Mitglieder des Satzes von Plug-ins werden jedes gefragt, eine deterministische
Berechnung auszuführen,
darüber,
wie gut sie mit einem Satz von gewünschten Eigenschaften übereinstimmen,
und geben dann das Ergebnis als eine numerische Punktzahl zurück.
-
Dies
ermöglicht
die Auswahl des am besten geeigneten Moduls, ohne einen Bedarf an
einer expliziten Intervention durch eine Entscheidungs-Intelligenz
in irgendeinem anderen Teil der die Einrichtung steuernden Software.
-
Obwohl
die vorliegende Erfindung mit Bezug auf bestimmte Ausführungsformen
beschrieben wurde, wird es geschätzt
werden, daß Modifikationen
erfolgen können,
solang man innerhalb der vorliegenden Erfindung verbleibt, wie sie
durch die angefügten Ansprüche definiert
wird.