DE10104043A1 - Die Schaffung der Möglichkeit, dass vorhandene Anwendungen andere Sprachen als ihre eingebauten Makrosprachen benutzen, ohne die vorhandene Anwendung zu ändern - Google Patents

Abstract

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zur Verbesserung der Verwwendung von eingebauten Makrosprachen von Anwendungen, die von Endnutzern zur Programmierung verwendet werden, und ermöglicht dem Nutzer, die Programmiersprache seiner Wahl zu benutzen. Dies geschieht im Wesentlichen durch Speichern des Quellcodes der vom Nutzer ausgewählten Sprache in Objekten der vorhandenen Anwendung und, falls es eine Compilerspracche ist, durch Speicherung des übersetzten Codes und des Compilers selbst. DOLLAR A Weiterhin wird das Konzept eines Bytecode verarbeitenden Servers (BPS) erläutert, der selbst in einem Objekt der vorhandenen Anwendung gespeichert wird, was die Verwendung der neuen Makrosprache an beliebiger Stelle ohne zusätzlichen Installationsaufwand erlaubt. DOLLAR A Und es wird die Kommunikation zwischen dem BPS und der existierenden Anwendung über ein Stubmittel erläutert, das in der eingebauten Makrosprache geschrieben ist. Dies umfasst die Parameterübergabe und die Datenübertragung.

Description

1. HINTERGRUND DER ERFINDUNG 1.1. BEREICH DER ERFINDUNG

Die vorliegende Erfindung bezieht sich auf den Bereich der Erleichterung der Arbeit der Kundenanpassung von Anwendungsprogrammen. Insbesondere bezieht sie sich auf ein Verfahren und ein System zur Verbesserung der Verwendung von eingebauten Makrosprachen von Anwendungen, die von Endnutzern für die Programmierung verwendet werden.

1.2. BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK

Standardisierte Anwendungsprogramme werden in modernen Geschäftsumgebungen allgemein verwendet. Beispiele sind Bürolösungen, die die Basissoftwarewerkzeuge enthalten, die für die Durchführung der täglichen Arbeit erforderlich sind, darunter Textverarbeitung, Arbeitsblatt-Analyse, die Verwendung relationaler Datenbanken, Präsentationsprogramme usw. Leute, die diese Anwendungsprogramme benutzen, werden hier im weiteren als Endnutzer eines solchen Programms bezeichnet.

Weiterhin sind viele Anwendungsprogramme, die jeweils einen besonderen Aspekt des Arbeitsablaufes eines Unternehmens überdecken, wie zum Beispiel die Implementation der Berechnung der nationalen Steuern, die Verwaltung der Gehaltszahlung, die Personalverwaltung oder die Verwaltung von Materialien, ein Teil der Anwendungsprogramme.

Da es sich um standardisierte Programme handelt, die für die öffentliche Verwendung bestimmt sind, sind sie nicht auf Kunden zugeschnitten, d. h. an die Bedürfnisse eines speziellen Unternehmens, einer Firma oder einer Privatperson angepasst.

Somit ist es für Endnutzer oft notwendig, eine vorhandene Anwendung anzupassen, um ihre speziellen Bedürfnisse zu befriedigen. In diesem Zusammenhang ist der "Endnutzer" normalerweise ein Entwickler. Deshalb werden "Endnutzer" und "Entwickler" im gesamten Dokument äquivalent verwendet.

Um diese Anpassungsarbeit durchzuführen, ist der Endnutzer normalerweise auf die eingebauten Makrosprachen der Anwendung angewiesen. Andere Sprachen als die eingebauten Makrosprachen können nicht benutzt werden. Dies ist jedoch ein beträchtlicher Nachteil, weil dann die Arbeit besondere Kenntnisse erfordert. Außerdem kann man bereits existierenden Code, der in einer anderen Programmiersprache programmiert wurde, für diesen Zweck nicht wiederverwenden und muss ihn umschreiben.

Die vorliegende Erfindung ist von sehr allgemeiner Art und kann immer dann angewendet werden, wenn eis Anwendungsprogramm zur Implementation von Änderungen nicht angefasst werden darf, was wiederum eine Neuübersetzung des Anwendungsprogramms selbst erfordern würde.

Spezielle und willkürlich ausgewählte Beispiele sind Anwendungen wie Lotus Notes oder Microsoft Word. Die eingebauten Makrosprachen sind Lotusscript bzw. WordBasic. Bei der Benutzung von Microsoft Word hat ein Endnutzer nicht die Möglichkeit, beispielsweise Java als Makrosprache zu benutzen. Das Gleiche gilt für alle Versionen von Notes 4.x.

Wenn in diesen Fällen ein Endnutzer die Sprache seiner Wahl benutzen möchte, wäre er darauf beschränkt, ein Programm zu schreiben, beispielsweise ein C-Programm, es zu übersetzen, es zu verbinden und dann das selbstgeschriebene Programm von einer Stelle innerhalb der vorhandenen Anwendung aufzurufen.

Der Hauptnachteil dieser dem Stand der Technik entsprechenden Vorgehensweise ist die Trennung zwischen dem selbstgeschriebenen Code und der vorhandenen Anwendung. Im günstigsten Fall ist es nur eine Unbequemlichkeit für den Endnutzer, Code und Anwendung an unterschiedlichen Orten zu haben, was die Wartung erschwert. Aber in der Mehrzahl der Fälle, in der eine Vielzahl von Nutzern eine Vielzahl von anzupassenden Programmen besitzt, ist diese Vorgehensweise überhaupt nicht praktikabel, da der selbstgeschriebene Code getrennt von der Anwendung gespeichert wird.

Ein Grund dafür liegt im praktischen Einsatz. Das selbstgeschriebene Programm muss überall installiert werden, wo die vorhandene Anwendung benutzt werden soll. Ein anderer Grund ist die Vervielfältigung (replication). Wenn eine vorhandene Anwendung die Vervielfältigung unterstützt, werden nur die Objekte vervielfältigt, die zu dieser Anwendung gehören, nicht aber getrennte zusätzliche Codestücke oder Programme. Weiterhin wird die Leistungsfähigkeit eines Netzwerk-Anwendungsservers durch diese zusätzliche(n) Aufgabe(n) belastet.

Bei den dem Stand der Technik entsprechenden Lotus Notes R5 kann Java als eingebaute Makrosprache benutzt werden.

Wenn jedoch das JAVA-Programm ausgeführt wird, dann ist Java darauf beschränkt, in speziellen Programmbereichen zu laufen, zum Beispiel den Notes Agents. Dies ist aber nicht vorteilhaft, insbesondere in Fällen, wenn das Anwendungsprogramm in einem Netzwerk installiert und von einer Vielzahl von Nutzern angewendet wird. Dann wird die Leistungsfähigkeit des Anwendungsservers beträchtlich verringert.

1.3. AUFGABEN DER ERFINDUNG

Es ist deshalb eine Aufgabe der vorliegenden Erfindung, die Flexibilität von Anwendungsprogrammen bezüglich der Makroprogrammierung zu verbessern, um dem Endnutzer die Möglichkeit einzuräumen, eine Sprache seiner Wahl zu verwenden. Es ist beabsichtigt, eine neue Möglichkeit anzubieten, andere Sprachen als die eingebauten Makrosprachen vorhandener Anwendungen zu benutzen, ohne die vorhandenen Anwendungen zu ändern und ohne die Notwendigkeit, spezielle zusätzliche Programme zu installieren, um den Code zu verarbeiten, der in einer vom Nutzer ausgewählten Sprache geschrieben wurde.

2. ZUSAMMENFASSUNG UND VORTEILE DER ERFINDUNG

Die Aufgabe der Erfindung wird durch die Eigenschaften erreicht, die in den beigefügten unabhängigen Ansprüchen formuliert sind, auf die jetzt Bezug genommen wird. Weitere vorteilhafte Anordnungen und Ausführungsformen der Erfindung werden in den jeweiligen Unteransprüchen erläutert.

Die grundlegende Voraussetzung, von der die vorliegende Erfindung ausgeht, besteht darin, dass eine vorhandene Anwendung eine eingebaute Makrosprache besitzt. Diese Makrosprache wird normalerweise an einer bestimmten Stelle gespeichert, wo die vorhandene Anwendung, beispielsweise ein WORD-Dokument in MICROSOFT WORD für WINDOWS, ein Formular von LOTUS NOTES, ein Arbeitsblatt von LOTUS 1-2-3 oder eine Datenbank von MICROSOFT ACCESS usw., auf sie zugreifen und sie verwenden kann.

Im Allgemeinen gibt es verschiedene Möglichkeiten, Daten innerhalb von Objekten einer vorhandenen Anwendung zu speichern, auf die durch die eingebaute Makrosprache oder durch den Endnutzer zugegriffen und von diesen bearbeitet werden können: verborgene Felder im RTF-Format (rich text field) in einem NOTES-Formular, ein verborgenes Kapitel in einem WORD-Dokument, ein Unterprogramm der Makrosprache oder ein Kommentar in einem Programm einer Makrosprache.

Um die vorliegende Einführung in die Konzepte der Erfindung einfach zu halten, wird vorausgesetzt, dass die selbst gewählte Sprache, die der Endnutzer anstelle der eingebauten Makrosprache benutzen möchte, eine Interpretersprache ist. Entsprechend einem Aspekt der vorliegenden Erfindung wird der Interpreter selbst in Form von Daten in einem Objekt der vorhandenen Anwendung gespeichert.

Um die Sprache seiner Wahl zu verwenden, muss der Endnutzer zuerst den Code in geeigneter Syntax schreiben und ihn dann an einer bestimmten Stelle speichern, d. h. in einem Objekt, wo mit der eingebauten Makrosprache auf ihn zugegriffen werden kann. Dann wird während der Laufzeit ein in der ursprünglichen eingebauten Makrosprache geschriebenes Codefragment aufgerufen. Dieser Code ist vergleichbar mit einem Stumpf (stub) und wird deshalb auch einfach so bezeichnet.

Zuerst muss dieser Stub prüfen, ob der Interpreter unter dem Betriebssystem verfügbar ist. Falls nicht, wird der Interpreter von seiner Position innerhalb der Anwendung geholt. Falls notwendig, gibt es verschiedene Möglichkeiten, das Betriebssystem festzustellen, beispielsweise durch Aufruf einer speziellen Funktion, die nur innerhalb eines bestimmten Betriebssystems verfügbar ist oder durch Aufruf einer Funktion, die das Betriebssystem direkt erkennt.

Als Nächstes wird der Code in der vom Nutzer gewählten Sprache freigegeben, d. h., der Code wird aus dem zugeordneten Objekt der vorliegenden Programmanwendung herausgelöst. Der Interpreter wird mit diesem Code zur Verarbeitung aufgerufen.

Schließlich gibt der Stub nach der Verarbeitung die Steuerung an die Anwendung zurück.

Im Wesentlichen kann diese grundlegende Vorgehensweise der Erfindung mit jeder beliebigen Interpretersprache und auch mit jeder beliebigen Compilersprache realisiert werden. Besondere Vorteile können durch Verwendung der JAVA-Sprache erreicht werden, weil der Endnutzer die Virtuelle Javamaschine (Virtual Java Machine) seiner Wahl benutzen und somit seinen Makro überall dort laufen lassen kann, wo es ihm vorteilhaft erscheint, d. h., wo er das; Ergebnis so schnell wie möglich erhält. Beispielsweise könnte er ihn auf einem Server in dem Netzwerk laufen lassen, der nicht mit dem Anwendungsserver selbst identisch ist. In vielen Fällen hilft das, die Antwortzeit zu reduzieren, insbesondere in Situationen, in denen viele Endnutzer in einem Netzwerk den gleichen Anwendungsserver gemeinsam benutzen. Darüber hinaus kann die JAVA-Programmiersprache in eine beliebige Laufzeitumgebung integriert werden, die von Haus aus JAVA als Endnutzer-Makrosprache nicht unterstützt.

Weiterhin gibt es, gleichgültig ob es sich um einen einzelnen Kunden oder um ein Unternehmen handelt, immer ein Bedürfnis danach, so wenig Programmiersprachen wie möglich zu haben, die an der Lösung eines speziellen Problems beteiligt sind. Die Hauptgründe dafür sind Wartungs- und Ausbildungskosten. Andere Gründe bestehen darin, dass möglicherweise ein gegebenes Problem nicht mit der eingebauten Makrosprache gelöst werden kann oder die Leistungsfähigkeit nicht ausreichend ist.

Somit besteht der wesentliche Vorteil der Erfindung darin, dass ein Endnutzer die Sprache seiner Wahl innerhalb einer vorhandenen Anwendung nutzen kann, was eine positive Auswirkung auf die Wartungs- und Ausbildungskosten hat, ohne die Nachteile der Trennung des selbstgeschriebenen Codes von der vorhandenen Anwendung.

3. KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird mit Hilfe eines Beispiels veranschaulicht und ist durch die Form der Abbildungen der beigefügten Zeichnungen nicht beschränkt, wobei

Fig. 1 eine Bildschirm-Aufnahme (screen shot) ist, die schematisch die Speicherung des Quellcodes in der durch den Nutzer ausgewählten Sprache in einem Objekt der vorhandenen Anwendung darstellt, in diesem Fall eines LOTUS NOTES-Ereignisses,

Fig. 2 eine schematische Darstellung wichtiger Schritte ist, die auszuführen sind, wenn die selbst ausgewählte Programmiersprache zur Ausführung einen Compiler benötigt, und zeigt, wie die Übersetzung funktioniert,

Fig. 3 eine schematische Darstellung ist, die die wesentlichen Schritte der Verarbeitung des Codes der vom Nutzer ausgewählten Programmiersprache während der Laufzeit zeigt,

Fig. 4 eine Bildschirmaufnahme ist, die schematisch einen Stub zeigt, der in der eingebauten Makrosprache der vorhandenen Anwendung geschrieben ist, und

Fig. 5 eine Bildschirmaufnahme ist, die schematisch das Ergebnis des Beispiels darstellt, wobei die vom Nutzer gewählte Sprache verwendet wird.

4. BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM 4.1. EINLEITUNG

Die vorliegende Erfindung ist für eine beliebige vorhandene Anwendung anwendbar, die die Verwendung einer Makrosprache erlaubt, die in das Anwendungsprogramm 'eingebaut' ist. Der Terminus 'eingebaut' soll jede beliebige, dem Stand der Technik entsprechende Vorkehrung überdecken, die dem Nutzer des Programms eine Makrosprache zur Verfügung stellt, d. h. er enthält alle oben erwähnten Makrosprachen, die normalerweise in dem Anwendungsprogrammpaket oder einem zusätzlichen Erweiterungspaket enthalten sind, wenn es beim Lizenzgeber bestellt wird.

Die Benutzung dieser Makrosprache sollte einen Zugriff zu Objekten erlauben, die zu dieser Anwendung gehören. Der Terminus 'Objekt' sollte einen sehr weiten Bereich umfassen.

Er sollte explizit Objekte im Sinne der objektorientierten Programmierung (OOP) überdecken. Aber darüber hinaus überdeckt er im Allgemeinen jede beliebige logische Datenstruktur, wie beispielsweise eine Datei, einen Datensatz innerhalb einer Datenbank, eine Datei-Anlage, den Inhalt einer Variablen oder Teile davon usw. Somit kann auf ein Objekt innerhalb der vorhandenen Anwendung mit der eingebauten Makrosprache oder über eine Anwendungsprogrammierungs-Schnittstelle (API) lesend oder schreibend zugegriffen werden.

Im Kontext dieser Beschreibung soll der Terminus 'vorhandene Anwendung' eine Anwendung bedeuten, die so zu nehmen ist, wie sie ist, d. h., eine Veränderung im Quellcode der Anwendung und eine Neuübersetzung soll strikt vermieden werden. Als Beispiel für eine solche vorhandene Anwendung wird in der folgenden Beschreibung LOTUS NOTES verwendet.

Die Beschreibung wird zeigen, wie die vorliegende Erfindung die Verwendung der JAVA-Sprache anstelle der ursprünglich eingebauten Macrosprache LOTUS-Script erlaubt.

Die zentrale Idee der folgenden Ausführungsform besteht darin, die gesamte relevante Information, d. h. den Java- Quellcode, den Java-Bytecode und den den Java-Bytecode verarbeitenden Server (Bytecode Processing; Server) (BPS) in Objekten zu speichern, die von der vorhandenen Anwendung bereitgestellt werden. Es ist auch möglich, die virtuelle Java-Maschine (Java Virtual Machine) und den Java-Compiler in Objekten zu speichern.

Java-Quellcode ist ein Programm, das in der Java- Programmiersprache geschrieben wurde. Java-Bytecode ist die binäre Ausgabe nach der Übersetzung eines Java-Programms mit dem Java-Compiler. Dieser Bytecode enthält Maschinenbefehle für einen virtuellen Prozessor, das heißt einen Prozessor, der nicht als Hardware implementiert ist. Um diesen Bytecode zu verarbeiten, wird eine virtuelle Maschine benötigt. Eine virtuelle Java-Maschine simuliert einen Hardware-Prozessor durch Software und übersetzt diese Befehle in Befehle eines vorhandenen Hardware-Prozessors. Die virtuelle Maschine kann jedesmal gestartet werden, wenn die Verarbeitung des Bytecodes benötigt wird, oder sie kann gestartet bleiben, wie zum Beispiel in einem Webbrowser. In dieser Beschreibung ist ein Java-Bytecode verarbeitender Server (BPS) eine virtuelle Java-Maschine, die Java-Bytecode verarbeiten kann und die ganze Zeit gestartet bleibt. Dieser Server ist entsprechend einem weiteren Aspekt ein Teil der vorliegenden Erfindung.

Das Ziel besteht darin, eine vom Nutzer ausgewählte Sprache (Java) als Alternative zur eingebauten Makrosprache so reibungslos zu integrieren, dass es einem Endnutzer transparent erscheint. Dies soll von einem Fachmann als wertvoll angesehen werden, wenn er die folgende Beschreibung zusammen mit den Zeichnungen liest.

4.2. AUSFÜHRLICHE BESCHREIBUNG

Unter allgemeiner Bezugnahme auf die Figuren, und jetzt unter spezieller Bezugnahme auf Fig. 1, wird ein Lotus Script-Programm - der zuvor erwähnte Stub - erzeugt und mit Java-Quellcode gefüllt. Um das zu tun, muss der Endnutzer zuerst ein Objekt definieren, in dem der Java-Quellcode gespeichert werden soll. In diesem Beispiel wird ein neues Ereignis 100 mit dem Namen cdMicroLogic, das zu einem Notes- Dokument gehört, benutzt.

Der nächste Schritt 102 besteht darin, ein Java-Programm in diesem Ereignis unterzubringen. Da einige Notes-Versionen die Syntax prüfen, muss das ganze Java-Programm zwischen die Anweisungen "%REM JavaSourceCode" 101 und "%END REM" 105 geschrieben werden. Wenn man das macht, ist das Java- Programm nur ein Kommentar innerhalb der Lotusscript- Sprache, und deshalb wurde ein gültiges Lotusscript-Programm erzeugt.

Wir beziehen uns jetzt auf Fig. 2; wenn der Endnutzer die Programmierung beendet hat, verlässt er das aktuelle Notes- Formular, d. h. den Dokumententwurf, der das Ereignis mit dem Java-Programm enthält, indem er die ESC-Taste drückt oder alternativ hierzu 'Speichere Datei' in der Menüleiste wählt, Schritt 200.

Jede Aktion des Endnutzers und somit auch die oben erwähnten können über einen Anwendungs-Nachrichtenzeiger (application message hook) überwacht werden. Ein solcher Zeiger ist eine Funktion, die auf Informationen in einer Warteschlange zugreifen kann. Eine Anwendungsnachrichten-Warteschlange ist eine Warteschlange, die von einer auf Nachrichten beruhenden Anwendung wie zum Beispiel Notes bereitgestellt wird. Der Anwendungs-Nachrichtenzeiger ist normalerweise eine selbstgeschriebene DLL, die in dem Moment geladen wird, wenn die Anwendung gestartet wird.

Sobald die Nachricht ESC oder 'Speichere Datei' von dem Zeiger empfangen wird, wird eine selbstgeschriebene Funktion aufgerufen. Diese Funktion benutzt das C-API von Lotus Notes, um den Inhalt des neuen Notes-Ereignisses 100 herauszuholen, Schritt 201.

Danach wird der Java-Quellcode, der sich zwischen "%REM JavaSourceCode" und "%END REM" befindet, Anweisungen 101, 105, in eine Datei geschrieben.

Dann wird von dieser Funktion in einem Schritt 202 eine Kennzeichnung (indicator) für den Java-Quellcode gesucht.

Als Nächstes wird, wenn die Kennzeichnung gefunden wurde (der Ja-Zweig der Entscheidung 202), ein Java-Compiler mit dieser Datei als Eingabedatei aufgerufen. Das Ergebnis ist eine Ausgabedatei, die den Java-Bytecode enthält. Die selbstgeschriebene Funktion nimmt diesen Bytecode und schreibt ihn zusammen mit dem Java-Quellcode zurück in das Notes-Ereignis. Der neue Inhalt des Notes-Ereignisses nach der Verarbeitung ist der Java-Quellcode und der Java- Bytecode, Schritt 204.

In den Nein-Zweigen der Entscheidungen 200 bzw. 202 wird die Steuerung zum Monitor für die Nutzeraktionen zurückgegeben, Schritt 200.

Während Fig. 1 und 2 Aspekte der vorliegenden Erfindung zeigen, die relevant sind, während das Makro erzeugt wird, sind Fig. 3, 4 und 5 wichtig für Laufzeitaspekte.

Wir beziehen uns jetzt auf Fig. 3, Fig. 4 und Fig. 5; während der Laufzeit wird die eingebaute Makrosprache immer dann aufgerufen, wenn ein spezielles Ereignis eintritt. Das Gleiche geschieht jetzt, wenn die vom Nutzer gewählte Sprache Java benutzt wird. Der Unterschied besteht darin, dass die eingebaute Makrosprache nur als ein Stub benutzt wird, der, kurz zusammengefasst, das Folgende macht:
als erstes Prüfung, ob der den Java-Bytecode verarbeitende Server vorhanden ist und läuft. Falls nicht, Freigabe und Start dieses Servers, Entscheidung 300, Schritt 301;
Danach Herausholen des Java-Bytecodes, der in einem Objekt zwischen den Anweisungen "%REM JavaßyteCode" und "%END REM" gespeichert ist, Schritt 302;
Weiterhin Senden des Bytecodes an den den Java-Bytecode verarbeitenden Server und Warten, bis die Verarbeitung beendet ist. Wahlweise können Daten, die zu bearbeiten sind, gesendet werden, Schritt 303.

In größerer Ausführlichkeit wird vorgeschlagen, dass die Verarbeitung des Java-Bytecodes während der Laufzeit entsprechend dem folgenden Schema realisiert wird:

Immer dann, wenn das spezielle Ereignis in Notes auftritt, zum Beispiel als PostOpen, was aufgerufen wird, wenn ein Notes-Document geöffnet wird, oder als QueryClose, Initialize oder Terminate, kann jetzt die eingebaute Makrosprache benutzt werden, um ein selbstgeschriebenes Programm laufen zu lassen.

Das Gleiche gilt, wenn Java verwendet wird, die vom Nutzer ausgewählte Sprache seiner Wahl. Wenn das ursprüngliche Notes-Ereignis stattfindet, in diesem Falle ist es ein Ereignis Postopen 400, 401, siehe Fig. 4, wird zuerst ein in der eingebauten Makrosprache geschriebenes kleines Programm aufgerufen. Dieses "Programm" besteht aus einer Zeile 402, die eine selbstgeschriebene Funktion mit dem Namen cdMainFormPostOpen aufruft.

Diese Funktion spricht den Java-Quellcode und den Bytecode an und prüft zuerst, ob der den Java-Bytecode verarbeitende Server (BPS) gestartet wird, Schritt 300. Falls nicht, wird BPS freigegeben. Im Beispiel wird vorausgesetzt, dass der BPS an ein spezielles Notes-Dokument angehängt ist, das zur gleichen Datenbank gehört. Da der BPS selbst in Java geschrieben ist, wird er über den Start einer virtuellen Java-Maschine mit dem BPS als zu verarbeitendes Programm gestartet. Alternativ hierzu könnten BFP und JVM (Virtuelle Java-Maschine) EIN Programm sein.

Nach dem Start des BPS hat in Schritt 302 die Funktion cdMainFormPostOpen 402 den Java-Bytecode aus dem Ereignis 100 heraus. Der Bytecode wird in eine Datei geschrieben. Dann ruft die Funktion 402 den BPS über TCP/IP auf, Schritt 303, wobei sie eine Netzwerksituation voraussetzt, in der ein und dasselbe Anwendungsprogramm über das Netzwerk von einer Vielzahl von Nutzern genutzt wird, und dem Anwendungsserver mitteilt, welches Programm, d. h. welcher freigegebene Bytecode, d. h. welche Datei zu verarbeiten ist.

Die Übergabe von Parametern an den Java-Code ist für den Endnutzer nahezu transparent. Alle benötigten Parameter werden an die Funktion 402 übergeben. Diese Funktion übergibt die Parameter über TCP/IP an den BPS. Der BPS lädt den Java-Code und übergibt die Parameter an diesen Java- Code, wenn die Verarbeitung des Codes beginnt. Im Beispiel werden die Parameter über ein cdTools 103 genanntes Java- Objekt übergeben, siehe wiederum Fig. 1. Dieses Objekt enthält alle Eingabeparameter und stellt dem Endnutzer Methoden zur Verfügung, auf sie zuzugreifen.

Nach der Verarbeitung des Java-Bytecodes durch den BPS funktioniert die Übergabe von Rückgabewerten genau auf die gleiche Weise wie die Übergabe von Parametern: das Objekt cdTools stellt beispielsweise eine Methode cdError() 104 zur Verfügung, um Fehler an die Funktion 402 zurückzumelden.

Durch die Übergabe von Parametern und Rückgabewerten werden die Daten, mit denen die Java-Programme arbeiten, indirekt übergeben. Im Beispiel ist ein Parameter der Name einer Datendatei, die Daten enthält, mit denen das Java-Programm arbeiten soll. Die Ergebnisse der Verarbeitung werden auch in die gleiche Datei geschrieben.

Das beschriebene Beispiel berechnet tatsächlich einige Informationen für ein Dokument. Wenn ein bestimmtes Dokument geöffnet wird, startet das Ereignis Postopen ein Java- Programm, so wie oben beschrieben. Dieses Java-Programm greift auf Daten zu, die in relationalen Datenbanken aufbewahrt werden, wie der Vorname und der Familienname, ein Kennzeichen für Mr./Mrs., die Anzeige einer Kennzeichnung "formal", ob der Kunde eine formale oder nichtformale Eröffnung wünscht und Informationen über Preisnachlass. Auf der Grundlage dieser Informationen wird die Eröffnungszeichenkette 502 eines Dokumentes berechnet, siehe Fig. 5 als Referenz. In Abhängigkeit von der Preisnachlassinformation wird ein "Erinnerungs"- Konstruktionsblock 501 in das Dokument aufgenommen. Wenn der Preisnachlass beispielsweise 0% beträgt, dann wird die Mahnung nicht in das Dokument einbezogen.

In der vorangegangenen Spezifikation wurde die Erfindung beschrieben unter Bezugnahme auf eine ihrer speziellen exemplarischen Ausführungsformen. Es ist jedoch offensichtlich, dass an ihr verschiedene Modifikationen und Veränderungen vorgenommen werden können, ohne vom weiteren Geist und Bereich der Erfindung abzuweichen, so wie in den beigefügten Ansprüchen dargestellt. Die Spezifikation und die Zeichnungen sind dementsprechend eher als Veranschaulichung als in einer restriktiven Art und Weise anzusehen.

In der oben beschriebenen, sich auf LOTUS NOTES beziehenden Ausführungsform der Methode der Erfindung gibt es eine Vielzahl von expliziten oder impliziten Entscheidungen bezüglich der Ausführungsform.

Somit werden als Nächstes nachstehend einige Ausführungs- Alternativen angegeben.

Als Erstes kann die Speicherung des Codes unterschiedlich ausgeführt werden:

Es gibt verschiedene andere Möglichkeiten, den Java- Quellcode zu speichern, zum Beispiel in Notes ScriptLibraries, Notes Agent oder als ein Anhang an ein Notes-Dokument. Allgemein gesprochen kann es ein beliebiges Objekt innerhalb der vorhandenen Anwendung sein, auf das über die eingebaute Makrosprache oder über ein API zugegriffen werden kann.

Im Beispiel wurde der Java-Quellcode zwischen den Anweisungen "%REM JavaSourceCode" und "%END REM" gespeichert. Wenn man das so macht, wird der Java-Quellcode, entsprechend der in den Notes eingebauten Makrosprache Lotusscript, als ein Kommentar gespeichert. Wenn die vorhandene Anwendung eine Java-Syntax erlaubt oder die Syntax überhaupt nicht prüft, ist diese "Umgehung" überflüssig.

Für von LOTUS NOTES verschiedene Anwendungsprogramme gelten ähnliche Betrachtungen.

Zum Zweiten gibt es Sprachalternativen:

Java ist eine Compilersprache für einen virtuellen Prozessor. Die vom Nutzer ausgewählte Sprache könnte auch eine Interpretersprache sein. Dies vereinfacht die Entwicklung, da keine Übersetzung notwendig ist und der übersetzte Code nicht an das Objekt angefügt werden muss.

Bezüglich der Compilersprachen wurde in dem Beispiel erwähnt, dass ein Anwendungs-Nachrichtenzeiger benötigt wird, um die Nachricht ESC oder die Nachricht über das Kommando 'Speichere Datei' zu finden. Diese Nachrichten können der Auslöser für den Start der Übersetzung sein. Diese Ausgestaltung ist nur notwendig, um dem Endnutzer soviel "Einfachheit der Benutzung" wie möglich zur Verfügung zu stellen. Es würde sich für den Endnutzer kaum auswirken, stattdessen eine Übersetzungstaste (compile button) oder irgendein anderes geeignetes Element der grafischen Nutzerschnittstelle (GUI) zu drücken, das die eingebaute Makrosprache anbietet. Natürlich kann ein derartiges GUI- Element benutzt werden, um ein oder mehrere in der vom Nutzer ausgewählten Sprache geschriebene Programme zu übersetzen. Das bedeutet, dass der Anwendungs- Nachrichtenzeiger kein notwendiges technisches Merkmal ist, von dem die vorliegende Erfindung abhängt.

Wenn eine Compilersprache verwendet wird, muss auch der übersetzte Code in einem Objekt der vorhandenen Anwendung gespeichert werden. In dem Beispiel ist dies das Ereignisobjekt 100 unter dem Java-Quellcode. Für den übersetzten Code gilt das Gleiche wie für den Quellcode. Er kann auch in einem beliebigen Objekt gespeichert werden, das die vorhandene Anwendung anbietet. Natürlich könnten Objekte verwendet werden, die dem Endnutzer selbst nicht sichtbar oder zugänglich sind, sondern nur dem Programm.

Eine weitere Alternative bezüglich einer Compilersprache bestünde darin, den Quellcode unmittelbar während der Laufzeit zu übersetzen. In diesem Falle ist keine vorherige Übersetzung und kein Speichern des entstehenden übersetzten Codes erforderlich. Natürlich bedeutet das eine Auswirkung auf die Leistungsfähigkeit.

Zum dritten kann der den Bytecode verarbeitende Server (BPS) unterschiedlich implementiert werden:

Allgemein gesprochen, ist der den Bytecode verarbeitende Server ein Server, der die vom Nutzer ausgewählte Makrosprache verarbeiten kann, gleichgültig, ob es eine Compilersprache für einen virtuellen Prozessor oder eine Interpretersprache ist.

In dem obigen Beispiel ist der BPS in Java geschrieben. Das bedeutet, dass eine virtuelle Java-Maschine benötigt wird, um diesen Server laufen zu lassen. Er könnte auch in C geschrieben sein. In diesem Falle könnten die virtuelle Java-Maschine und der BPS ein Programm sein. Die Forderung nach einer gesonderten virtuellen Maschine wäre überflüssig.

Der BPS könnte auf einem Computer in einem Netzwerk freigegeben und gestartet werden. Wenn man das macht, könnten mehrere Nutzer gleichzeitig einen BPS nutzen, und die Verarbeitung des Codes würde auf einer anderen Maschine stattfinden.

Um die Leistungsfähigkeit zu erhöhen, könnte ein BPS mehrere Male freigegeben und gestartet werden. Es gibt Mechanismen nach dem Stand der Technik für einen BPS, andere BPS zu entdecken und, falls notwendig, die Verarbeitung eines Programms, das in der vom Nutzer geschriebenen Sprache geschrieben ist, einem anderen BPS zuzuordnen. Dies kann als Synergie-Effekt einer Kombination der vorliegenden Erfindung und der Java-Möglichkeiten der Laufzeitunabhängigkeit genutzt werden.

Eine vorherige Installation des BPS wäre auch möglich, womit man vermeidet, ihn freizugeben und zu starten. Aber dies würde den oben erwähnten Hauptvorteil der Erfindung unterminieren, nämlich die Benutzung einer vorhandenen Anwendung mit einer vom Nutzer ausgewählten Makrosprache ohne die Notwendigkeit, ein spezielles Programm vorher zu installieren.

Was oben bezüglich des Java-Quellcodes und des Java- Bytecodes erwähnt wurde, gilt auch für den BPS: ein beliebiges Objekt der vorhandenen Anwendung reicht aus, um den BPS zu speichern.

Eine andere Variation besteht darin, eine Compilersprache für einen vorhandenen Prozessor zu nutzen, selbst wenn man die Nachteile der Größe der Programme, des Verlustes der Plattformunabhängigkeit und in den meisten Fällen der Komplexität der Sprache für Endnutzer betrachten muss.

Schließlich kann die Parameter- und Daten-Übergabe auf unterschiedliche Arten implementiert werden.

Es ist möglich, alle Parameter für die vom Nutzer ausgewählte Sprache über eine Datei zu übergeben, anstatt sie über TCP/IP oder eine andere Netzwerkverbindung zu schicken.

Andererseits können die Daten über TCP/IP oder eine beliebige andere Netzwerkverbindung geschickt werden, anstatt sie über eine Datei zum BPS zu übertragen.

Im Beispiel werden alle Parameter über das Objekt cdTools 103 übergeben, das alle Parameter enthält und Verfahren zur Verfügung stellt, um auf sie zuzugreifen. Dies ist eine willkürlich getroffene Entscheidung über die Ausführungsart. Es ist auch möglich, alle Parameter im entsprechenden ursprünglichen Format zu übergeben. Das Gleiche gilt für die Rückgabewerte.

Einige Teile der oben beschriebenen Ausführungsform benutzen das Notes-C-API. Das ist aber auch nur eine willkürlich getroffene Entscheidung über die Ausführungsart. Die gleichen Ergebnisse können auch erreicht werden, wenn nur LOTUS-Script benutzt wird. Es ist auch eine Entscheidung über die Ausführungsart, wo und wie der Quellcode und der übersetzte Code in Notes-Objekten gespeichert werden. Das Gleiche gilt für die Ereignisbehandlung.

Wie man aus der gesamten obigen Darstellung einschätzen kann, enthalten die Konzepte der Erfindung primär die Speicherung des Quellcodes der vom Nutzer ausgewählten Sprache in Objekten der vorhandenen Anwendung und, falls es sich um eine Compilersprache handelt, die Speicherung des übersetzten Codes sowie die Übersetzung selbst.

Weiterhin wird das Konzept eines BPS einbezogen, der selbst in einem Objekt der vorhandenen Anwendung gespeichert wird, was es erlaubt, die neue Makrosprache überall zu nutzen, ohne zusätzlichen Installationsaufwand.

Und es ist die Kommunikation zwischen dem BPS und der vorhandenen Anwendung über einen Stub eingeschlossen, der in der eingebauten Makrosprache geschrieben ist. Dies umfasst die Übergabe von Parametern und die Datenübertragung.

Schließlich sollte angemerkt werden, dass die Konzepte der Erfindung erweitert werden können, um Makromodule zu erzeugen und abzuarbeiten, die mehr als zwei Sprachen umfassen. Hierfür können Aufrufe nach dem Stand der Technik zwischen den Sprachen nacheinander verwendet werden.

Die vorliegende Erfindung kann in ein Computerprogrammprodukt eingebettet werden, zum Beispiel in ein Anwendungsprogrammprodukt, so wie weiter oben erwähnt, das alle die Eigenschaften umfasst, die die Implementation der jeweiligen Schritte der hier beschriebenen Verfahren ermöglichen, und das, wenn es in ein oder mehrere Computersysteme geladen wird, diese Verfahren ausführen kann.

Computerprogramm-Mittel oder Computerprogramm in diesem Kontext ist jeder beliebige Ausdruck, in irgendeiner Sprache, irgendeinem Code oder beliebiger Notation, einer Menge von Befehlen, die dazu bestimmt sind, ein System mit Informationsverarbeitungsfähigkeit zu veranlassen, eine bestimmte Funktion entweder direkt oder nach einem oder beiden der folgenden Schritte auszuführen:

• a) Umwandlung in eine andere Sprache, einen anderen Code oder eine andere Notation;
• b) Reproduktion in unterschiedlicher materieller Form.

Claims (12)

1. Verfahren zur Erzeugung eines wenigstens zweisprachigen Makromoduls zur Verwendung in einem Anwendungsprogramm, das Makrosprachen-Programmiermittel einer Sprache bereitstellt, die für das Anwendungsprogramm die ursprüngliche Sprache ist,
wobei das Verfahren dadurch gekennzeichnet ist, dass es den Schritt der Speicherung (102, 204) des Quellcodes einer vom Nutzer wählbaren Programmiersprache in einem oder mehreren Objekten umfasst, die dem Anwendungsprogramm zugeordnet sind.

2. Verfahren nach Anspruch 1, wobei die vom Nutzer wählbare Programmiersprache eine Interpreter-Sprache ist und das Verfahren den Schritt enthält, Interpretermittel zu nutzen, die in einem oder mehreren Objekten des Anwendungsprogrammes selbst gespeichert sind.

3. Verfahren nach Anspruch 1, wobei die vom Nutzer wählbare Programmiersprache eine Sprache mit später Bindung ist und das Verfahren den Schritt umfasst (203), Bytecode erzeugende Mittel zu nutzen, die in einem oder mehreren Objekten des Anwendungsprogrammes selbst gespeichert sind.

4. Verfahren nach dem vorhergehenden Anspruch, das weiterhin den Schritt umfasst, ein Byteprogrammierungs- Servermittel als virtuelle Maschine für das Abarbeiten des Codes in der vom Nutzer gewählten Sprache zu benutzen, und das Byteprogrammierungs-Servermittel in einem oder mehreren Objekten des Anwendungsprogrammes selbst gespeichert wird.

5. Verfahren nach dem vorhergehenden Anspruch, in dem eine Kommunikation zwischen dem Byteprogrammierungs- Servermittel und der Anwendung über ein Stubmittel realisiert wird, das in der eingebauten Makrosprache geschrieben ist und so gestaltet werden kann, dass es die Übergabe von Parametern und die Übertragung von Daten umfasst.

6. Verfahren nach dem vorhergehenden Anspruch, wobei das Byteprogrammierungs-Servermittel in einem oder mehreren fernen Computermitteln gespeichert wird und Parameter und/oder Daten, die dem Quellcode der vom Nutzer ausgewählten Programmiersprache zugeordnet sind, von einem Computermittel, auf dem sich die Anwendung befindet, zu einem oder mehreren entfernten Computermitteln übertragen werden.

7. Verfahren nach dem vorhergehenden Anspruch, wobei die Programmiersprache die JAVA-Sprache ist.

8. Verfahren nach Anspruch 1, wobei die vom Nutzer ausgewählte Programmiersprache eine Sprache mit früher Bindung ist und die Sprache den Schritt umfasst (203), Compilermittel zu benutzen, die in einem oder mehreren Objekten des Anwendungsprogrammes selbst gespeichert sind.

9. Verfahren nach dem vorhergehenden Anspruch, das weiterhin den Schritt umfasst (204), einen Aufruf der Compilermittel und/oder den übersetzten Code in einem oder mehreren Objekten zu speichern, die dem Anwendungsprogramm selbst zugeordnet sind.

10. Verfahren zum Abarbeiten von wenigstens einem zweisprachigen Makromodul, der entsprechend dem Verfahren nach einem der Ansprüche 1 bis 9 erzeugt wurde.

11. Anwendungsprogrammprodukt, das Computermittel zur Ausführung eines Codes umfasst, der von dem Quellcode der vom Nutzer gewählten Programmiersprache abgeleitet wurde und einen zweisprachigen Makromodul nach einem der vorhergehenden Ansprüche umfasst.

12. Anwendungsprogrammprodukt nach dem vorhergehenden Anspruch, in dem das Programmmittel zur Ausführung des Codes, der vom Quellcode der vom Nutzer ausgewählten Programmiersprache abgeleitet wurde, eines der folgenden Mittel ist: Interpretermittel, Compilermittel oder Bytecode-Konvertierungsmittel.