Das Konzept von Composite Applications unter Lotus Notes/Domino haben wir im ersten Teil dieser Serie erklärt. Dieser Teil beschäftigt sich mit der Definition der Dienste über WSDL. In vielen Fällen wird der erste Schritt auf dem Weg zu Composite Applications sein, dass man Funktionen von vorhandenen Notes-Anwendungen als NSF-Komponenten bereitstellt, um sie dann entweder mit anderen Eclipse-Komponenten oder mit NSF-Komponenten anderer Notes-Anwendungen zu neuen Applikationen zu kombinieren.
NSF-Komponenten sind dabei letztlich nichts anderes als Verknüpfungen zu bestehenden Design-Elementen, mit denen bestimmte Informationen dieser Elemente für andere Anwendungen verfügbar gemacht werden.
Die Komponenten werden in einem oder mehreren Design-Elementen beschrieben, die man als „Composite Applications“-Design-Elemente bezeichnet. Es gibt allerdings auch an anderen Stellen entsprechende Erweiterungen, beispielsweise bei Ansichten. Für die Komponenten sind WSDL-Dateien von zentraler Bedeutung, die die Struktur der Komponenten beschreiben.
Die Vorgehensweise
Zunächst benötigen Sie die richtige Entwicklungsumgebung: Dazu gehören der Domino Designer 8 und Eclipse. Ohne dieses Duo steht der Property Broker Editor nicht zur Verfügung, den Sie für die Bearbeitung der Komponenten-Eigenschaften benötigen. Daher muss man die „vollständige“ Version von Notes und nicht nur die Basis-Version installieren.
Bei der Entwicklung von Komponenten ist folgende Vorgehensweise zu empfehlen:
-
Festlegung der Design-Elemente, die in der Anwendung sichtbar sein sollen.
-
Bedarfsweise Entwicklung zusätzlicher Design-Elemente in Domino, um zusätzliche Funktionen abzudecken.
-
Festlegung der Aktionen, die von den Komponenten ausgeführt werden müssen.
-
Erstellung einer WSDL-Datei, in der die Aktionen und Eigenschaften der Komponente beschrieben sind.
-
Importieren der WSDL-Datei in die Notes-Anwendung, die bestimmte Design-Elemente oder Dokumente über eine NSF-Komponente bereitstellt.
-
Gegebenenfalls noch Anpassung vorhandener Design-Elemente, insbesondere für die Kommunikation mit dem Property Broker, unter Nutzung der neuen Klassen in LotusScript. Dabei handelt es sich um Erweiterungen, nicht um Modifikationen bestehender Funktionen.
Die Anpassungen in der Anwendung
Bei der Erstellung von NSF-Komponenten gibt es drei Ansätze:
-
Die Komponenten können Eigenschaften bereitstellen, also Daten für andere Komponenten verfügbar machen.
-
Die Komponenten können Eigenschaften anderer Komponenten konsumieren.
-
Die Komponenten können auch sowohl Eigenschaften bereitstellen als auch konsumieren.
In den meisten Fällen wird eine NSF-Komponente in eine der ersten beiden Gruppen gehören. Das bietet sich aus Gründen einer übersichtlichen, nachvollziehbaren Programmierung auch an. In den meisten Fällen wird das sogar auf Anwendungsebene gelten, weil eine Anwendung meistens entweder Funktionen zusammenstellt oder eben als eine Composite Application auf andere Komponenten zugreift.
Daher sind in vielen Fällen tatsächlich keine Änderungen bestehenden Codes erforderlich, sondern nur Erweiterungen – immer dann, wenn Funktionen nur bereitgestellt werden. In einzelnen Fällen, bei Ansichten und Ordnern, geht das sogar direkt über die Eigenschaften. Dort können Sie bei Spalteneigenschaften einen Verweis auf eine Eigenschaft (Property) setzen. Die entsprechende Einstellung findet sich im Register Advanced im Abschnitt Composite Settings.
Einsatzbereiche der LotusScript-APIs
In allen anderen Fällen muss man aber tatsächlich die neuen LotusScript-APIs für die Kommunikation mit dem Property Broker und die Bereitstellung von Eigenschaften nutzen. Dabei definieren Sie Aktionen, die bei dem entsprechenden WSDL-Aktionen ausgeführt werden oder umgekehrt und für die Bereitstellung respektive Verarbeitung der Änderungen sorgen.
Wenn dagegen eine Anwendung Eigenschaften anderer Komponenten konsumiert, sind Änderungen erforderlich, weil diese Eigenschaften (Daten) in bestehenden oder zusätzlichen Design-Elementen verarbeitet werden müssen. Dabei handelt es sich dann um funktionale Erweiterungen der Anwendung, die ohnehin – auch bei „konventioneller“ Softwareentwicklung – Änderungen an der Anwendung erfordert hätten.
Die Erstellung einer WSDL-Datei
Die Eigenschaften, Typen und Aktionen werden in einer WSDL-Datei beschrieben. Diese lässt sich direkt im Domino Designer erstellen. Sie lässt sich alternativ auch importieren, falls sie bereits auf anderem Wege erzeugt wurde. In den meisten Fällen werden Sie aber zu Beginn erst einmal eine neue Datei erzeugen.
Dazu wechseln Sie im Domino Designer in den Bereich Composite Applications – Wiring Properties. Mit New Wiring Properties erstellen Sie dort ein neues Design-Element für diese „Wiring Properties“, das letztlich nichts anderes ist als ein Verweis auf die WSDL-Datei mit den entsprechenden Beschreibungen.
Bei der Erstellung des Design-Elements legen Sie zunächst nur den Namen fest. Beachten Sie, dass die WSDL-Definition hier nicht sichtbar ist. Das Design-Element fungiert zunächst eher als eine Art Platzhalter oder Bindeglied zu der Beschreibung, die aber nicht direkt hier editiert werden kann.
Der Property Broker Editor
Um die Informationen zu bearbeiten, wählen Sie in der Aktionsleiste die Option Open File. Damit wird der Property Broker Editor geöffnet, sofern Sie die vollständige Version von Notes 8 auf Eclipse-Basis installiert haben - der Property Broker Editor ist nämlich eine Eclipse-Anwendung.
Außerdem empfiehlt es sich, den Property Broker Editor und den Designer auf einem anderen System zu nutzen als den Composite Application Editor. Letzterer ist ebenfalls ein Eclipse-Tool für das Zusammenfügen von Komponenten, auf das wir in einem gesonderten Artikel eingehen. Wenn beide Tools parallel auf einem System zum Einsatz kommen, können Konflikte auftreten, durch die der Property Broker Editor später nicht mehr korrekt aufgerufen werden kann.
Datentypen
Im Property Broker Editor definieren Sie nun Datentypen, Namensbereiche, Aktionen und eben die Eigenschaften. Diese Informationen werden dann in der WSDL-Datei zusammengefasst.
Die Datentypen sind keine exakten Beschreibungen, wie man sie beispielsweise von vielen Programmiersprachen kennt. Es handelt sich hierbei vielmehr um Konventionen, damit das Verständnis über die Struktur von Eigenschaften bei der Nutzung von Komponenten identisch ist.
Es lassen sich nur zwei grundsätzlich unterschiedliche Typen definieren, nämlich Zeichenketten und Datumswerte. Allerdings kann man mehrere Zeichenketten festlegen. Wie die interne Struktur aussieht, also beispielsweise welche speziellen Zeichen für einen Typ emailAddress zulässig sind und welche nicht, ist dagegen eine Konvention, die außerhalb der WSDL-Beschreibung festgelegt werden muss.
Mit der Funktion Import Types importieren Sie Datentypen aus einer bestehenden WSDL-Datei. Damit können Sie beispielsweise eine Datei mit Standard-Datentypen für die in einem Unternehmen definierten Komponenten festlegen, auf die zentral zugegriffen wird.
Namensbereiche
Ein weiteres wichtiges Element sind die Namensbereiche. Auch dabei handelt es sich letztlich um eine Konvention. Ein Namensbereich (Namespace) beschreibt eine zusammengehörige Gruppe von Typen und Eigenschaften. Ein Typ kann in mehreren Namensbereichen vorkommen und dort jeweils eine unterschiedliche Bedeutung haben. Das ist vor allem bei unspezifischen Typen wie Kategorie wichtig, die oftmals unterschiedlich interpretiert werden.
Für die Realisierung eigener Komponenten ist es sinnvoll, einen eigenen, einheitlichen Namensbereich zu definieren und diesen durchgängig zu nutzen. Standardmäßig wird dabei http://com.<Firmenname>.propertybroker empfohlen. Man kann aber auch eine andere Konvention verwenden.
Für vorhandene Eclipse-Komponenten wird beispielsweise mit http://www.ibm.com/wps/c2a gearbeitet. Wichtig ist vor allem, dass es innerhalb eines Unternehmens – und gegebenenfalls auch im Zusammenspiel mit externen Dienstleistern für die Entwicklung von Notes-Anwendungen – eine einheitliche Konvention für die Verwendung von Namensbereichen und Datentypen gibt, um Probleme im Zusammenspiel unterschiedlicher Komponenten zu vermeiden.
Eigenschaften
Im folgenden Schritt sind die Eigenschaften zu definieren. Hier können Sie auch den Target Namespace angeben, zu dem diese Eigenschaften gehören sollen. Die Konfiguration erfolgt im Register Properties des Property Broker Editors.
Die Namen der Eigenschaften können (und sollten) sprechend gewählt werden. Dabei sind auch Leerstellen zulässig. Die Namen sollten möglichst ausdrücken, um welche Information es sich handelt, also beispielsweise um geänderte Kundendaten, eine neue Email-Adresse, einen zusätzlichen Benutzer oder dergleichen mehr.
Je nach Art der Komponente sind sowohl „input properties“ als auch „output properties“ zu definieren. Erstere werden von der Komponente empfangen, letztere für andere Komponenten bereitgestellt.
Bei der Definition von Eigenschaften müssen Sie den Namen, den Typ und einen ergänzenden Titel angeben. Zusätzlich können Sie auch eine Beschreibung verfassen. Das ist grundsätzlich empfehlenswert, um die Nachvollziehbarkeit zu erhöhen, wenn andere Benutzer auf die erzeugte WSDL-Datei zugreifen.
Aktionen
Schließlich gibt es noch die Aktionen, die im Register Actions beschrieben werden. Aktionen werden in der Regel verwendet, um Datenelemente zu suchen und auszuwählen.
Zu einer Aktion gehören Eingabe- und Ausgabeparameter, also die Eigenschaften. Sie können Aktionen also erst dann definieren, nachdem Sie die Eigenschaften festgelegt haben. Auch hier gilt, dass die Namen der Aktionen sprechend sein können und sollten. Leerzeichen sind auch hier zulässig.
Die nächsten Schritte
Mit der Definition von Eigenschaften, Aktionen, Namensbereichen und Typen haben Sie die Basis geschaffen, um die eigentliche NSF-Komponente zu erzeugen. Im nächsten Schritt geht es nun darum, dass eine Anwendung die Eigenschaften bereitstellt und auf Aktionen reagieren respektive diese auslösen kann.
Die Anwendung muss also beispielsweise über eine Notes-Aktion eine Aktion der Komponente erzeugen oder alternativ dazu bei einem Aufruf von einer externen Anwendung die Rückgabewerte, also die Eigenschaften, bereitstellen.
Dazu können Sie, wie weiter vorne erwähnt, entweder die LotusScript-APIs für die Ansteuerung des Property Brokers und die Bereitstellung von Eigenschaften nutzen oder in einzelnen Fällen auch Spalteneigenschaften von Ansichten oder Ordnern anpassen.
Erst danach können Sie diese Komponente bereitstellen. Da es sich bei der Codierung um eine relativ komplexe Angelegenheit handeln kann, gehen wir darauf in einem späteren Artikel gesondert ein. (Kuppinger/mha)