Integrationsmöglichkeiten unterschiedlicher Anwendungstypen in der IBM Workplace-Technologie

Solange allerdings Portlets in einer gewöhnlichen Portalumgebung laufen, stößt man bei der Anwendungszusammenführung im Rahmen des Workplace-Clients auf das gleiche Problem wie bei den oben besprochenen Web-Applikationen. Das heißt, dass die JSR-168Spezifikation zwar für lokale Portlets innerhalb von Web-Portalen gültig, keineswegs aber auf den in Kapitel 4.4.1 angesprochenen Rich-Client-„Portlets“ angewandt werden kann. Dennoch stellen Portlets in diesem Zusammenhang einen hoffnungsvollen Träger im Bereich der Client-Technologie dar, nämlich auf Basis der erweiternden Spezifikation von Remote Portlets (siehe Kapitel 4.5.3). Diese ermöglichen die volle Integrationsstufe auf der Workplace Client-Seite dahingehend, dass mit Hilfe eines vom Workplace-Client zur Verfügung gestellten WSRP-Plug-ins Kontextinformationen mit anderen Plug-in-UIElementen geteilt werden können. In weiterer Folge bedeutet dies, dass durch eine ähnliche Vorgangsweise wie bei der Zusammenführung herkömmlicher Plug-ins die Nutzung sämtlicher WCT-Features möglich wird. Bevor allerdings die Anlehnung von Portlets an die Workplace-Architektur via WSRP betrachtet wird, ist zunächst die Funktionsweise entfernter Portlets zu verstehen. [...]

Nicht nur das Provisioning zeichnet die Client-Technologie als wesentliches Merkmal aus. Ein lokaler Workplace bietet als sichere Plattform genau wie das Netzwerksystem, das diesen verwaltet, entsprechende Sicherheitsmechanismen im Bereich der Kommunikation innerhalb des Netzwerkes sowie SSO (Single Sign-On) mit dem Betriebssystem. Dazu bietet er seine eigene lokale relationale Datenhaltung (mitunter zur Offline-Unterstützung), die standardmäßig auf einer Cloudscape-Datenbank basiert und Datenzugriffe über Credentials (Berechtigungsnachweise) abwickelt. Solche Credentials werden durch eine lokal abgelegte und verschlüsselte XML-Datei (Credential Store) beschrieben, die bei erstmaliger Installation eines Workplaces eingerichtet wird. Die Verschlüsselung von Benutzername und Kennwort erfolgt mit Hilfe eines 3DES-Schlüssels. Im Zuge dieser Einrichtung wird auch das erste Credential in Form der Anmeldedaten für den WebSphere Application Server (sind ursprünglich identisch mit jenen zur Workplace-Anmeldung) abgelegt. Erst durch eine erfolgreiche Anmeldung eines Desktop-Clients werden diese Daten wieder entschlüsselt. Die Motivation in der Nutzung dieses mitgelieferten Features liegt im sicheren Zugriff auf verschlüsselte Daten, die durch Einsatz spezieller Client-APIs ermöglicht wird. Die beiden Plug-in-Komponenten com.ibm.workplace.database.db2j.jdbc und com.ibm.rcp.security unterstützen den Anwendungsentwickler in diesem Vorhaben. Folgendes Beispiel (Listing 4.4) zeigt einen sicheren Zugriff auf die verschlüsselte Datenbank my_wct_db und erzeugt diese, falls sie noch nicht existiert: [...]

Bis auf den letzten stellen die in Abbildung 4.3 angeführten Parameter Optionen für die vorläufig betrachtete Oberflächen-Transformation dar. In weiterer Folge geht es aber auch darum, spezielle Funktionen der Client-Technologie nutzen zu können. Der Parameter rcpUpdate deutet im Wesentlichen auf den nächsten Schritt in der Plug-in-Integration hin — der Nutzung des Client-Provisionings auf Policy-Basis. Er definiert das zu installierende Feature, das zum automatischen Herunterladen neuer Komponenten und Upgrades auf den Workplace-Client notwendig ist. WMC-Umgebungen werden über Komponenten von Update-Sites versorgt, die am HTTPServer vorliegen müssen. Um Clients eigene Plug-ins automatisch zur Verfügung zu stellen, reicht es nicht aus, die in JAR-Dateien verpackten Plug-ins selbst anzubieten. Vielmehr müssen entsprechende Features vorhanden sein, von denen jedes mehrere Plugin-Komponenten umfassen kann. Die Erstellung einer Eclipse Update Site ermöglicht hierbei die Verwaltung mehrerer Features und unterstützt den Prozess des ClientProvisionings sowohl bei der Installation am Workplace-Server als auch bei der lokalen Entwicklung. So kann beispielsweise der Provisioning-Vorgang für Testzwecke ohne eine aktuelle Server-Verbindung mit Hilfe einer Update-Site lokal simuliert werden. Ihr Aufbau (Plug-in- und Feature-JARs) wird durch eine Site-Beschreibung in site.xml folgendermaßen spezifiziert: [...]