Eberhard-Karls-Universität Tübingen Der IBM WebSphere

Eberhard-Karls-Universität
Tübingen
Fakultät für Informations- und
Kognitionswissenschaften
Studienarbeit im Rahmen des
Universität-Praxis-Projekt von Herr Prof. Dr. Klaeren
im WS 2001/02
Der IBM WebSphere
Portalserver 2.1
Il-Hyun Kim
Horst Rechner
Betreuer: Markus E Leypold
INHALTSVERZEICHNIS
i
Inhaltsverzeichnis
1 Einleitung
1
2 Der IBM WebSphere Portalserver 2.1
4
2.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2 Die IBM WebSphere Portalserver 2.1 Architektur . . . . . . .
7
3 Zuständigkeiten
3.1 Portalserver . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
3.2 Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Portalentwicklung
12
4.1 Portalmodifikation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1
Company Information . . . . . . . . . . . . . . . . . . 12
4.1.2
Look and Feel (Themes und Skins) . . . . . . . . . . . 13
4.1.3
Portal Stylesheet Klasse . . . . . . . . . . . . . . . . . 17
4.1.4
Änderung der Portal Hilfe Seiten . . . . . . . . . . . . 18
4.2 Portal Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Portlet
20
5.1 Was sind Portlets? . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 API (Application Program Interface) . . . . . . . . . . . . . . 21
5.2.1
Portlet API . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2
Servlet API . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.3
J2EE API . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Lebenszyklus eines Portlets (API Aufrufe) . . . . . . . . . . . 23
6 Portletprogrammierung
25
INHALTSVERZEICHNIS
ii
6.1 Spannbreite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Portlet Archiv Datei . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Statisches Portlet . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3.1
Portlet Deployment Descriptor . . . . . . . . . . . . . . 26
6.3.2
Java Portlet Klasse . . . . . . . . . . . . . . . . . . . . 27
6.3.3
Java Server Page . . . . . . . . . . . . . . . . . . . . . 28
6.4 Einbinden in den Portalserver . . . . . . . . . . . . . . . . . . 28
6.5 Dynamisches Portlet . . . . . . . . . . . . . . . . . . . . . . . 28
6.5.1
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.2
Controller . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.5.3
View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Der IBM WebSphere Portalserver 4.1
35
7.1 Merkmale von WPS 4.1 . . . . . . . . . . . . . . . . . . . . . 35
7.2 Unterschiede zwischen WPS 2.1 und WPS 4.1 . . . . . . . . . 36
8 Fazit
39
VORWORT
iii
Vorwort
Die Studienarbeit ist das Ergebnis des Universitäts-Praxis-Projekts im Wintersemester 2001/2002.
Das Projekt war eine Zusammenarbeit der Universität Tübingen und der
Württembergischen und Wüstenrot Versicherung.
Teilnehmer auf Universitätsseite waren Il-Hyun Kim, Clemens Oertel, Horst
Rechner und als Betreuer Markus Leypold.
Basierend auf einer Präsentation von I.-H. Kim, C. Oertel und H. Rechner
wurden die Kapitel 1-5 und 7 von I.-H. Kim und Kapitel 6 und 8 von H.
Rechner ausgearbeitet.
1 EINLEITUNG
1
1
Einleitung
Portale dienen als allgemeinen Einstiegspunkt um Informationen und Applikationen einheitlich aufzubereiten und im Browser darzustellen.
Portale findet man im Internet, z.B. bei Yahoo, AOL, Compuserve oder TOnline. Die ursprüngliche Idee zur Entwicklung eines Portals war eine Entsprechung der Gelbe Seiten für das Internet. Diese Idee wurde weiterentwickelt und die Information, auf die ursprünglich gelinkt wurde, wird jetzt
direkt auf der Portalseite angezeigt. Z.B. können bei MyYahoo1 die Nachrichten, Aktienkurse und das Wetter angezeigt werden.
Abbildung 1: Beispiel einer unpersonalisierten Portalseite von my.Yahoo.com
1
my.yahoo.com
1 EINLEITUNG
2
Sie bieten ihren Kunden u.a. eine Personalisierung, d.h. eine individuelle
Anpassung von Umfang und Layout ihrer Portalseiten an.
Abbildung 2: Beispiel einer personalisierten Portalseite von my.Yahoo.com
Neben der Personalisierung sind weitere typische Funktionen eines Portals:
• Eine einmalige Authentifizierung und Authorisierung (single
sign-on login) durch den Benutzer ermöglicht diesem, alle im Portal enthaltenen Dienste mit einem Passwort zu benutzen.
• Eine Personalisierung basierend auf Profilen bzw. dem Verhalten des Benutzers, d.h. passend zu Benutzerdaten, wie z.B.
Geschlecht und Geburtstag, können das Verhalten des Portals
beeinflussen.
• Navigation- und Layouteinstellungen der Seiten wird durch
eine Administrationsseite ermöglicht. Der Benutzer kann damit
die Anzahl der angebotenen Dienste und das Aussehen bestimmen.
• Suchfunktion
Dabei werden die aufsteckbaren Portalkomponenten Portlets genannt. Ein
1 EINLEITUNG
3
Beispiel für ein Portlet wäre das Wetter oder die Nachrichten auf einer Portalseite.
Abbildung 3: Beispiel einer Portalseite mit einheitlicher Oberfläche
2 DER IBM WEBSPHERE PORTALSERVER 2.1
2
4
Der IBM WebSphere Portalserver 2.1
In diesem Kapitel werden kurz die Voraussetzungen für die Installation eines
IBM WebSphere Portalserver 2.1 geklärt2 .
2.1
Voraussetzungen
Abbildung 4: Zusammenspiel anderer Komponenten mit IBM WPS Portalserver 2.1
Um den IBM WebSphere Portalserver (WPS) installieren zu können, braucht
man entweder einen Intel basierten Computer, eine RS/6000 SP oder eine
Solaris.
Nach IBM benötigt man 60 MB oder mehr freien Festplattenspeicher, 512
MB oder mehr Arbeitsspeicher und ein CD-ROM Laufwerk.
Ein Intel basierter PC benötigt eines der folgenden Betriebssysteme:
2
WebSphere Portal Enable Solution Version 2.1
2 DER IBM WEBSPHERE PORTALSERVER 2.1
•
•
•
•
Windows
Windows
Windows
Windows
5
NT Server 4.0 mit SP4 oder SP6a
2000 Advanced Server
2000 Server Edition
2000 Database Server
Eine RS/6000 SP benötigt den AIX V4.3.3.02.
Unter Solaris benötigt man für eine Standard- oder Development-Installation
das Sun Solaris V7 oder eine Solaris V8. Für die Advanced-Installation
benötigt man die Sun OS 2.7 für einen Sun Server.
Wie die Abbildung 4 verdeutlicht, benötigt der IBM WebSphere Portalserver
folgende Softwares, die bereits installiert sein müssen:
•
•
•
•
•
Ein Windowsbetriebssystem, AIX oder Solaris
Eine relationale Datenbank, z.B. die DB2
Ein LDAP Server, z.B. die IBM SecureWay Directory
Ein HTTP Server, z.B. den IBM HTTP Server
Der Websphere Application Server, Advanced Edition (WAS)
Für unsere WebSphere Portalserver Installation benötigten wir keine LDAP
Directory, da wir eine Entwickler-Installation benutzten. Mit dieser Installationsart werden die Benutzerdaten in eine lokale Datenbank gespeichert.
Ansonsten empfiehlt IBM die IBM SecureWay Directory, Version 3.2.1.
In der Praxis hat es sich gezeigt, dass die von IBM angegebenen Anforderungen Mindestanforderungen sind.
Es ist empfehlenswert mehr als 512 MB Arbeitsspeicher zu besitzen, da der
IBM WebShpere Portalserver sonst zu langsam arbeitet. Auch reichen nicht
die angegebenen 60 MB für den Portalserver. Zwar braucht der Portalserver allein nur 60 MB Festplattenspeicher, jedoch benötigt der Portalserver
zusätzliche Software, die insgesamt mehr als 500 MB Festplattenspeicher
benötigen.
Inklusive Betriebssystem benötigte man ca. 1,4 GB Festplattenspeicher (Win2K:
∼800MB; DB2: ∼315MB; WAS+JDK: ∼162MB; HTTP Server: ∼28MB;
WPS: ∼60MB).
Außerdem ist es empfehlenswert, die genaue Version der jeweiligen Produkte
zu installieren. Es ist also eine Installation von bestimmten Fixpacks notwendig. Falls man zum Beispiel nicht die IBM DB2 7.1 mit dem Fixpack 2a
installiert hat, funktioniert der Portalserver nicht.
Im Falle der Datenbank kann man auch den IBM DB2 Universal Database
(DB2), Version 7.2 installieren. Somit entfällt die Installation des Fixpacks.
Bei dem WebSphere Application Server, Advanced Edition (WAS) ist dabei
2 DER IBM WEBSPHERE PORTALSERVER 2.1
6
zu beachten, dass die Version 3.5.4 benötigt wird. Der WPS läuft NICHT
unter WAS 4.
2 DER IBM WEBSPHERE PORTALSERVER 2.1
7
Unsere Versuchsplattform war ein Windowsbetriebssystem.
Für unsere Installation benutzten wir folgende Software:
•
•
•
•
•
2.2
Windows 2000 Advanced Server
IBM DB2 Universal Database, Version 7.1, Fixpack 2a
IBM Webshpere Application Server 3.5.4, Advanced Edition
IBM HTTP Server 1.3.12
IBM WebSphere Portalserver 2.1
Die IBM WebSphere Portalserver 2.1 Architektur
Wir wissen jetzt, welche Programme der Portalserver benötigt, damit er korrekt arbeiten kann.
Jetzt wollen wir die Frage klären, wie nun diese Komponenten mit dem Portalserver zusammenarbeiten.
Abbildung 5: Portalserver Architektur
2 DER IBM WEBSPHERE PORTALSERVER 2.1
Als erstes meldet sich der Benutzer über einen Internet Browser, mobiles Telefon oder einem PDA an einem Webserver an,
indem er eine URL Adresse benutzt.
Der Webserver hat dabei die Aufgabe die URL Adresse an
den WAS weiterzuleiten. Wird nun die URL des Portalservers
aufgerufen, ruft der WAS den WPS, der als Servlet unter dem
WAS eingebunden ist, auf. Die gültigen URL Adressen für den
Portalserver sind im WAS gespeichert.
Ruft der Benutzer jetzt den Portalserver auf, so muss er sich
zuerst authentifizieren. Der Portalserver schaut dabei in der
LDAP Directory nur nach, ob der Benutzer existiert. Das
Leightweight Directory Access Protocol ist dabei ein offener
Standard für globale oder lokale Verzeichnisdienste und/oder
im Internet. Das LDAP Verzeichnis wird dabei wie ein Telefonbuch betrachtet, in der Namen mit Telefonnummern und
E-Mail Adressen verknüpft sind3 . In unserem Fall wird nur
nach dem Namen des Benutzers geschaut.
Hat sich der Benutzer nun authentisiert, werden seine Portlets
vom Portalserver geladen. Die Benutzerdaten, sowie Daten,
die die Portlets benötigen, werden in der DB2 gespeichert.
Zudem liegen Daten vom LDAP Server, WAS und WPS in
der DB2.
Benötigen Portlets Daten aus dem Internet, wie z.B. die aktuellen Wetterdaten, so haben sie die Möglichkeit, diese direkt
aus dem Internet zu besorgen. Dafür wird also nicht der Portalserver benötigt.
3
http://linuxline.epfl.ch/Doc/rhl-rg-de-7.0/ch-ldap.html
8
3 ZUSTÄNDIGKEITEN
3
9
Zuständigkeiten
Hat man nun den Portalserver installiert, stellt sich die Frage, welche Aufgaben vom Portalserver und welche vom Portlet übernommen werden. Anders
gefragt: Welche Funktionen stellt IBM bereit, und was muss man selber programmieren?
3.1
Portalserver
Abbildung 6: Der Portalserver ohne Portlets
3 ZUSTÄNDIGKEITEN
10
Die Abbildung 6 deutet an, für was der Portalserver zuständig ist:
•
Authentifizierung
Der Portalserver wickelt die Verwaltung der Authentifizierungsabfragen, wie
z.B. mit dem LDAP Server, ab. Das Layout der Login und Passwortabfragen
können hier verändert werden.
•
Corporate Identity
Das Layout der HTML Seiten wird vom Portalserver festgelegt. Dabei verwendet der Portalserver Stylesheets. Stylesheets sind ein Zusatz zu HTML,
die es ermöglicht, die Formatierung von Webseiten für den Programmierer
übersichtlicher und eindeutiger zu gestalten, so dass das Ergebnis nicht auf
unterschiedlichen Plattformen unterschiedlich aussieht. Viele Darstellungsfehler können mit Stylesheets verhindert werden. Durch Veränderungen der
Stylesheets usw. kann man das Aussehen verändern und sie somit dem einer
Firma anpassen. Man kann also Farbe und Buttons oder Bilder verändern
bzw. reinstellen.
•
Positionierung von Portlets, Tabs, Anzahl Spalte
Die Positionierungen gehören auch zum Layout und werden im Portalserver
verwaltet und können auch dort verändert werden.
•
Portlet Management
Der Portalserver ist durch den Administrationsportlet in der Lage zu bestimmen, welche Seiten und welche Portlets für welchen Benutzer gezeigt werden
sollen.
Die Funktionen der Authentifizierung, Positionierung von Portlets usw. und
das Portlet Management werden vom IBM geliefert. So ist eigene Programmierung, außer zur Veränderung des Aussehens, nicht notwendig.
3 ZUSTÄNDIGKEITEN
3.2
11
Portlets
Abbildung 7: Beispiel eines Portlets
Am Beispiel der Abbildung 7 wird verdeutlicht, für was das Portlet zuständig
ist.
• Inhalt
Für den Inhalt sind Daten zuständig, die abgefragt bzw. abgearbeitet. Die ganze Datenverarbeitung läuft über also das Portlet
ab.
• Logik
Für die Logik verwendet das Portlet Beans.
• Ansicht
Im Portlet werden auch die verschiedenen Ansichten behandelt.
Dabei gibt es die minimierte, normale und maximierte Ansicht.
Dabei wird klar, dass der Programmierer nur die Portlets programmieren
muss. In unserem Fall W&W. Der Rest übernimmt der Portalserver, d.h.
also IBM.
4 PORTALENTWICKLUNG
4
12
Portalentwicklung
Im vorherigen Kapitel haben wir nun gelernt, für was der Portalserver zuständig
ist.
In diesem Kapitel wird nun gezeigt, was und wo man am Portalserver programmieren kann4 .
4.1
Portalmodifikation
Der Portalserver dient als Präsentationsframework. Die internen Abläufe wie
die Authentifizierung werden vom IBM geliefert und müssen nicht programmiert werden. Das einzige, was man verändern kann, ist das Aussehen des
Portals.
Hier wird nun kurz erklärt, wie man den Portalserver den optischen Ansprüchen einer Firma anpassen kann. In unserem Beispiel W&W.
Das schließt das Hinzufügen, Entfernen oder Ändern von Texten, Farben,
Bildern, Links, Portletsgrenzen, und sogar das Layout der Portalseite mit
ein. Viele Änderungen erfordern das Löschen des Portal Server Caches, der
sich im Application Servers /temp/default host Verzeichnis befindet und den
Neustart des Portalservers.
4.1.1
Company Information
Der Text das im Banner angezeigt wird ist in der Datei
engine\_lang.properties definiert und befindet sich im Verzeichnis
wps\_root/app/web/WEB-INF/classes/nls/. Dabei ist lang der Sprachcode, entsprechend den Lokalen Einstellungen des Clients. Als Beispiel ist die
engine\_es.properties die Datei, in der das Banner Text für spanische
Clients definiert ist. Falls der WebSphere Portal Server die Sprache des Clients nicht bestimmen kann, so ist der Banner Text in engine.properties
definiert. Um nun den Banner Text für jede unterstützte Sprache zu ändern,
befolge diese Schritte:
1. Editiere die engine\_lang.properties Datei.
2. Ändere die title Parameter in den Namen der im Portalbanner angezeigt werden soll.
4
WebSphere Portal Enable Solution Version 2.1
4 PORTALENTWICKLUNG
13
3. Speichere und schließe die engine\_lang.properties Datei.
4. Starte den Application Server für den WebSphere Portal Server neu.
4.1.2
Look and Feel (Themes und Skins)
Das Aussehen der Portal Server Seiten werden durch Themes und Skins bestimmt. Themes repräsentieren das allgemeine ,,Look and Feel“ des Portals.
Das schließt die Schriftart und Farbe mit ein. Skins repräsentieren das Rahmen Rendering um ein einzelnes Portlet. Skins benutzen den Theme Namen
um die passenden Grafiken auszusuchen.
Der WebSphere Portalserver liefert schon eine Reihe von vorgefertigten Themes und Skins. Nach der Installation benutzt WebSphere Portalserver den
DefaultTheme. Um die vorgefertigten Themes und Skins zu benutzen befolgen Sie folgende Schritte:
1. Bearbeite die Datei TurbineResources.properties im Verzeichnis wps\_root/app/web/WEB-INF/conf.
2. Ändere die skin.default Parameter in eine der folgende Werte:
• Album
• Hint
• Outline
• Shadow
Beachte: Falls Sie die Werte leer lassen, werden die
Standardwerte genommen.
3.
Ändere die theme.default in eine der folgende Werte:
• GreyTheme
• KhakiTheme
• LilacTheme
• TealTheme
Beachte: Sie können die Werte als DefaultTheme
belassen. Jedoch im Gegensatz zu skin.default können
Sie den Wert nicht leer lassen.
4. Speichern und schließen Sie die TurbineResources.properties
Datei.
4 PORTALENTWICKLUNG
14
5. Starten Sie den WebSphere Application Server für den WebSphere Portalserver neu.
Man kann natürlich auch eigene Themes definieren. Dies setzt voraus, dass
man eigene Bilder und ein passendes Stylesheet erstellt. Die folgende Schritte
setzt voraus, dass man keinen Skin für den Portal benannt hat (d.h. der
skin.default Parameter ist leer).
1. Gehe in das wps\_root/app/web/images/theme Verzeichnis.
2. Erstelle ein Unterverzeichnis mit dem Namen des neuen Themes, z.B. WWTheme.
3. Kopiere die Dateien vom Verzeichnis
wps\_root/app/web/images/themes/DefaultTheme in das Verzeichnis /WWTheme.
4. Ändere die neuen Bilder damit sie mit dem neuen Theme
übereinstimmen. Alle Veränderungen sollten mit den Änderungen
des Stylesheets übereinstimmen.
a.
b.
Portal Banner
Navigation Icons
i.
ii.
iii.
iv.
v.
vi.
vii.
c.
Nav\_create\_account.gif
Nav\_customize.gif
Nav\_forget\_password.gif
Nav\_help.gif
Nav\_login.gif
Nav\_logoff.gif
Nav\_profile.gif
Tab Ecken
i. Tab\_left.gif
ii. Tag\_right.gif
d.
Icons für Portlet Titelbalken
i. Title\_back.gif
ii. Title\_help.gif
iii. Title\_edit.gif
iv. Title\_maximize.gif
v. Title\_minimize.gif
vi. Title\_restore.gif
4 PORTALENTWICKLUNG
15
5. Wechseln in das wps\_root/app/web/css Verzeichnis.
6. Erstelle Kopien von den Dateien DefaultTheme.css und
DefaultTheme\_ie.css mit dem neuen Theme Namen,
z.B. WWTheme.css und WWTheme\_ie.css.
7. Bearbeite die beiden Stylesheets und passe die Änderungen
des neuen Themes an. Die WWTheme\_ie.css Stylesheet is speziell
für den Internet Explorer. Alle Änderungen der Style Definitionen zwischen den beiden Dateien sind gleich mit Ausnahme der
Schriftgröße, welche je nach verwendeten Browser unterschiedlich
sein können. Wie man die Portal Style Klassen ändert wird im
nächsten Kapitel (Portal Stylesheet Klasse) erläutert.
8. Speichere und schließe die Dateien.
9. Bearbeite die Datei TurbineResources.properties in dem
Verzeichnis wps\_root/app/web/Web-Inf/conf.
10. Ändere den theme.default Parameter in den neuen Theme Namen, z.B. WWTheme.
11. Speichere und schließe die TurbineResources.properties
Datei.
12. Starte den WebSphere Application Server für den WebSphere Portalserver neu.
Nun haben wir einen eigenen Theme erstellt und müssen jetzt die Skins
erstellen:
1. Wechseln in das Verzeichnis wps\_root/app/web/images/skins.
2. Erstelle ein neues Unterverzeichnis mit dem Namen der neuen Skins, z.B. WWSkin.
3. Kopiere die Dateien vom Verzeichnis
wps\_root/app/web/\\images/skins/Album in /WWSkin.
4. Ändere die Folgenden Bilder um den neuen Skin anzupassen.
a. Border\_theme\_name\_BottomLeft.gif
b. Border\_theme\_name\_Bottomright.gif
c. Border\_theme\_name\_TopLeft.gif
d. Border\_theme\_name\_TopRight.gif
Diese Bilder definieren die Ecken der Portlet Rahmen.
Man braucht vier Bilder für jedes Theme das dem Portlet zu Verfügung steht, einschließlich den angepassten
Themes.
5. Wechseln zum Verzeichnis
wps\_root/app/web/temp\-lates/skins/html.
4 PORTALENTWICKLUNG
16
6. Erstelle ein neues Unterverzeichnis mit dem Namen des neuen Skins, z.B. WWSkin.
7. Kopiere die Datei TitleBarControl.jsp vom Verzeichnis
wps\_root/app/web/templates/skins/html/Album in das /WWSkin
Verzeichnis.
8. Bearbeite die TitleBarControl.jsp Datei.
9. Suche die Datei für die Bilder der Ecken der Rahmen. Diese
Bilder sind mit dem <img> Tag definiert. Die Quelle der Bilder
sieht so aus:
Src=’<wps:url type=“base“/>images/skins/Album/Border
<wps:theme/> TopLeft.gif ’. Ändere den /Album Teil des Bildquel-
lenpfades in den des neuen Skins, z.B.:
Src=’<wps:url type=“base“/>images/skins/WWSkin/Border
<wps:theme/> TopLeft.gif ’. Wiederhole diesen Schritt für alle wei-
teren Eckbilder.
10. Speichere und schließe TitleBarControl.jsp.
11. Bearbeite die Datei TurbinResources.properties im Verzeichnis wps\_root/app/web/WEB-INF/conf.
12. Ändere den Wert von skin.default in den Namen des neuen Skins.
13. Speichere und schließe die TurbinResources.properties
Datei.
14. Starte den WebSphere Application Server für den WebSphere Portalserver neu.
4 PORTALENTWICKLUNG
4.1.3
17
Portal Stylesheet Klasse
Die im vorherigen Kapitel (Look and Feel) erwähnten Stylesheets besitzen
Klassen, die sich im Verzeichnis wps\_root/app/web/css befinden und vom
Portal benutzt werden.
1.
Portalfenster
Abbildung 8: Portal Window Style
A
Stylesheet Klasse
wpsPortalBanner
B
wpsPortalText
C
wpsMainNav, wpsMainNavTabs
D
wpsTabs, wpsSelectedTabs
2.
Beschreibung
Definiert Farbe und Schriftart in dem Gebiet
in dem der Firmenname erscheint
Gleiches Style wie wpsPortalBanner mit
Ausnahme das das Hintergrundbild fehlt. Benutze dies für Gebiete des Banners in der kein
Hintergrundbild benutzt wird.
wpsMainNav wird für die rechte Seite des
Navigationsgebietes, wpsMainNavTabs wird
für die linke Seite des Navigationsgebietes
um die Seitentabs benutzt.
Benutze diese Klassen für die Eigenschaften
der Navigationstabs
Portletrahmen
Abbildung 9: Portlet Frame Style
4 PORTALENTWICKLUNG
E
Stylesheet Klasse
wpsPortletTitle
F
wpsPortletBody
18
Beschreibung
Für Portlet Titel Eigenschaften, einschließlich Hintergrund- und Vordergrundfarbe,
Padding und Schriftart
Für das Gebiet in der das Portlet seinen Inhalt anzeigt, einschließlich der Seitenrandhöhe und Breite (margin width und
height).
Weitere Portlet Stylesheet Klassen sind Text und Hintergrund Style und
Table Style5 .
4.1.4
Änderung der Portal Hilfe Seiten
Der WebSphere Portalserver stellt eine Hilfe Seite zur Verfügung. Man kann
die Hilfe Seite den eigenen Bedürfnissen anpassen und z.B. Informationen
der eigenen Firma hineinstellen. Die Portal Hilfe ist eine Ansammlung von
HTML Dateien und GIFs. Sie befinden sich im Verzeichnis
wps\_root/app/web/html/lang, wobei wps\_root das Hauptverzeichnis vom
WebSphere Portalserver ist und lang der Sprachcode.
Die Hauptdatei des Portals ist phelp\_index.html. Diese Datei enthält
Links zu allen anderen Hilfe Dateien.
Die Original Hilfe Dateien gibt es in mehreren Sprachen. Falls man mehrere
Sprachen unterstützen will, muss man die neuen Dateien übersetzen.ˆ
Bevor man mit Änderungen anfängt, sollte man einen Satz Kopien der Original Hilfe Dateien als Backup machen
4.2
Portal Layout
Die folgenden Punkte beinhalten Informationen, die das Bearbeiten des HTML
Layouts erleichtern sollen.
Beachte: Falls Änderungen von Portalseiten beim Testen nicht auftreten,
sollte man den WebSphere Application Server Cache löschen, der sich in
was\_root/temp/default\_host/wps befindet.
• Elemente von Portalseiten
Das Layout der Portalseiten beginnt mit dem Markup in Default.jsp
5
WebSphere Portal Enable Solution Version 2.1, S. 215f
4 PORTALENTWICKLUNG
im Verzeichnis
wps\_root/app/web/templates/layout/html. Default.jsp teilt
die Portalseite in drei Gebiete ein:
1. Head
Die Datei ./elements/Head.jsp fragt die Titelseiten
ab und ruft Style Sheets für verschiedene Browser auf.
Head ist nicht Teil des Portal Layout.
• Ändern der Titelseite haben wir schon in
I. kennengelernt.
• Um neue Style Sheets zu benutzen, erstelle
neue und setze ein Link zu den Stylesheets von
Head.jsp. Benutze den <wps:url> Tag um den
Standort der Stylesheets anzuzeigen.
2. Banner
Die elements/Banner.jsp definiert das Layout des Kopfes der Portalseite.
3. Screen
Das <wps:screen/> Element definiert das Gebiet für
die Portlets, das angezeigt wird. Administratoren und
Benutzer definieren das Layout der Portlets, indem sie
den Customizer benutzen.
• Tags, die von dem Portal JSPs benutzt werden:
Vom Portal Engine verfügbare Tags beginnen mit <wps:...>. Die
entsprechende Taglib Datei ist engine.tld und befindet sich im
wps\_root/app/web/WEB-INF/tld Verzeichnis. Diese Tags können
benutzt werden, um das Layout der Portalseite zu modifizieren.
Einige Tags sind:
<wps:date> Schreibt die aktuelle Zeit.
<wps:if> Damit können Bedingungen abgefragt werden.
<wps:theme\texttt> Fragt den Wert des default.theme Parameter in Turbine.properties ab. Abhängig vom Wert wird das
entsprechende Theme gesetzt.
Es gibt noch viel mehr Tags6 , die wir aber hier nicht alle vorstellen
werden.
6
WebSphere Portal Enable Solution Version 2.1, S.221f
19
5 PORTLET
5
20
Portlet
Nun kennen wir den Portalserver. Was ist nun mit den Portlets?
In diesem Kapitel werden kurz die Portlets erklärt. Deren Programmierung
wird im nächsten Kapitel gezeigt. Hier werden kurz die Funktionen und Zusammenhänge aufgezeigt.
5.1
Was sind Portlets?
Abbildung 10: Beispiel eines Portlets
Portlets sind:
• Komponenten eines Portals.
Sie sind also eine Java Applikation, die unter dem Portalserver
läuft. Sie führen eine vordefinierte Rolle aus. Ein Portlet ist eine
Funktion.
• spezialisierte Servlets.
Sie benutzen neben der Servlet API auch eine Portlet API. Dadurch ist der Zugriff auf Informationen von Benutzerprofilen, die
in einer Datenbank gespeichert sind, möglich.
Sie verbinden sich also mit Datenbanken und verarbeiten die Informationen, die sie erhalten. Die Daten werden pro Portlet Instanz durch das Portal gespeichert, d.h. die Ausgabe verläuft über
das Portal.
5 PORTLET
21
Mit der Portlet API lassen sich auch verschiedene Ansichten des
Portlets definieren.
5.2
API (Application Program Interface)
Der Portalserver unterstützt verschiedene Schnittstellen und Methoden, genannt API, um verschiedene Dienste zu erhalten. Die APIs definieren die
Schnittstellen die Kompatibilität zwischen Portal und Portlets. Dabei basieren die APIs auf die Java Servlet API. Die verschiedenen APIs, die der
Portalserver verwendet, werden nun im folgenden beschrieben7 .
Abbildung 11: Kommunikation erfolgt mit unterschiedlichen APIs
7
Portlet Development Guide. Introduction to the Portlet API. Edition 1.1
5 PORTLET
5.2.1
22
Portlet API
Die Portlets befinden sich innerhalb des Portalservers in einem Portlet Container. Mit der Portlet API kommunizieren die Portlets mit dem Portlet
Container des Portalservers. Die Klassen für die Portlet API wird vom IBM
mitgeliefert.
Abbildung 12: Portlet API
5.2.2
Servlet API
Der Portalserver wird als Servlet in den WAS eingehängt. Um nun mit dem
WAS zu kommunizieren, verwendet der Portalserver die Servlet API.
Abbildung 13: Servlet API
5 PORTLET
5.2.3
23
J2EE API
Portlets und Portalserver unterstützen auch die J2EE API (Java 2 Platform,
Enterprise Edition). Diese wird benötigt, um z.B. mit Java Enterprise Beans
kommunizieren zu können. U.a. auch mit Web Services.
Abbildung 14: Portalserver APIs
Portlets benutzen also nicht nur eine API (Application Programmer Interface). Sie benutzt neben der Portlet API auch die Servlet API, um z.B. mit
dem WAS zu kommunizieren. Der Portalserver wird als Servlet in den WAS
eingehängt. Es unterstützt auch die J2EE (Java 2 Enterprise Edition) API,
um z.B. mit den Java Enterprise Beans kommunizieren zu können.
Beispiele von API Aufrufen werden im Rahmen des nächsten Kapitels, Lebenszyklus eines Portlets, gezeigt.
5.3
Lebenszyklus eines Portlets (API Aufrufe)
Im Laufe des Lebens eines Portlets werden darin entprechende Methoden
aufgerufen. Dabei ist der Lebenszyklus eines Portlets dem eines Servlets sehr
ähnlich. Zu den schon bekannten Methoden eines Servlets besitzt der Lebenszyklus eines Portlets noch zwei zusätzliche Methoden8 9 .
•
init();
Das Portlet wird nach der Portalinizialisierung aufgebaut und dann mit der
init Methode initialisiert. Das Portal instanziiert immer nur eine Instanz
vom Portlet, und diese Instanz wird von allen Benutzern geteilt. Ähnlich wie
das Servlet, das mit allen Benutzern eines Applikationsservers geteilt wird.
8
9
Portlet Development Guide. Introduction to the Portlet API. Edition 1.1
WebSphere Portal Enable Solution Version 2.1
5 PORTLET
•
24
login();
Nachdem ein Benutzer sich in das Portal eingeloggt hat, erstellt jedes Portlet
eine Session für den Benutzer. Die Kombination der physikalischen Portlet
Instanz und der Benutzer Session bringt die virtuelle Portlet Instanz hervor.
Der Beginn einer virtuellen Instanz wird durch den Portal mit der login
Methode an das Portlet signalisiert. Diese Methode erlaubt dem Portlet die
Initialisierung der Benutzer Session Instanz des Portlets, um z.B. Attribute
in die Session zu speichern.
•
service();
Das Portal ruft die service Methode auf, wenn es für das Portlet erforderlich
wird, seinen Inhalt zu rendern. Während das Lebenszyklus eines Portlets wird
typischerweise die service Methode oft aufgerufen.
•
logout();
Wenn der Benutzer die Verbindung (Sitzung) mit dem Portal beendet (sich
vom Portal abmeldet), ruft der Portalserver die logout Methode auf, um
den Portlet zu informieren, dass die Session Instanz des Benutzers beendet
wird. Das Portlet sollte nun alle Ressourcen der virtuellen Instanz löschen.
•
taken out of service:
destroy();
Werden Portlets einmal geladen und initialisiert, dann laufen, wie bei den
Servlets, immer. Der Systemadministrator kann aber das Portlet zerstören,
z.B. durch das Runterfahren des Portalservers. Dabei wird die destroy Methode aufgerufen. Sie gleicht dem des Servlets. Diese Methode wird nur einmal aufgerufen, bis der Portalserver wieder die init Methode aufruft, um
das Portlet wieder zu laden und zu initialisieren. Typischerweise beim Starten
des Portalservers.
6 PORTLETPROGRAMMIERUNG
6
6.1
25
Portletprogrammierung
Spannbreite
Für die Implementierung eines Portlets gibt es eine große Spannbreite. Zum
einen kann man ein Portlet lediglich dazu benutzen eine statische HTML
Datei zu generieren. Auf der anderen Seite steht eine Kombination aus Java
Beans, Java Server Pages und XML, die dynamisch die verschiedenen Ansichten des Portlets mit Inhalten aus einer Datenbank füllt.
Im folgenden werden beide Varianten in ihrer einfachsten Ausprägung mit
Codebeispielen behandelt.
6.2
Portlet Archiv Datei
Für statische und dynamische Portlets gelten die selben Richtlinien für die
Integration in den Websphere Portalserver.
Die Portlets werden dem Server in einer gepackten Datei übergeben, die beim
Start dann in das Arbeitsverzeichnis entpackt, und von dort aus ausgeführt
wird. Die grundlegende Verzeichnisstruktur für die einzelnen Dateien ist dabei folgende (siehe auch [3]):
/ - Root Directory
/PORTLET-INF/portlet.xml - Der Portlet Descriptor, der grundlegende Informationen über das Portlet enthält.
/PORTLET-INF/classes/ - In diesem Verzeichnis befinden sich die Java Klassen.
/PORTLET-INF/html/ - Die Java Server Pages befinden sich in diesem Verzeichnis.
Diese Struktur spiegelt sich innerhalb der Portlet Archiv (PAR) Datei wieder.
Um diese zu erhalten, empfiehlt es sich eine kleine Batch Datei zu schreiben,
welche die Übersetzung der Java Klassen und das anschließende Komprimieren automatisiert. Eine typische Batch Datei hat folgende Gestalt:
1
2
3
4
5
set root = C :/ Portlets / statPortlet
javac - d % root %/ PORTLET - INF / classes % root %/ PORTLET - INF /
classes / statPortlet / statPortlet *. java
jar cvf0 statPortlet . jar PORTLET - INF
erase statPortlet . par
rename statPortlet . jar statPortlet . par
6 PORTLETPROGRAMMIERUNG
26
Listing 1: Batch Datei zum compilieren der PAR Datei
Der Befehl jar erzeugt die PAR Datei, die schlußendlich in den Portalserver
eingebunden wird, und um Grunde genommen nichts anderes als eine Java
Archiv Datei mit anderer Endung ist.
6.3
Statisches Portlet
Für ein statisches Portlet sind drei Dateien notwendig, die in die PAR Datei
eingebunden werden.
6.3.1
Portlet Deployment Descriptor
Der Portlet Deployment Descriptor (PDD)
enthält
Metainformationen
über
das
Portlet, wie die unterstützten Sprachen
(<language locale="en"> und den damit
verbundenen Titel), sowie die unterstützten
Anzeigearten (<markup name="html"> und die
damit verbundenen Ansichten).
Diese Datei ist die erste, die der Portalserver beim
Einbinden liest. Danach wird die Java Klasse, die
unter <portlet-class> definiert ist ausgeführt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<? xml version = " 1.0 " ? >
<! DOCTYPE portlet - app PUBLIC " -// IBM // DTD Portlet Application
1.0// EN " " portlet . dtd " >
< portlet - app >
< portlet - app - name > statPortlet </ portlet - app - name >
< context - param >
< param - name > Portlet Master </ param - name >
< param - value > name@domain . de </ param - value >
</ context - param >
< portlet >
< portlet - name > statPortlet </ portlet - name >
< portlet - class > statPortlet . statPortlet </ portlet - class >
< portlet - type > instance </ portlet - type >
< allows >
< maximized / >
</ allows >
< language locale = " en " >
6 PORTLETPROGRAMMIERUNG
17
18
19
20
21
22
23
24
25
26
27
28
27
< title > statPortlet </ title >
< title - short > statPortlet </ title - short >
< description > statPortlet macht folgendes </ description >
< keywords > statPortlet , MeinErstesPortlet </ keywords >
</ language >
< supports >
< markup name = " html " >
< view / >
</ markup >
</ supports >
</ portlet >
</ portlet - app >
Listing 2: PORTLET-INF/portlet.xml
6.3.2
1
Java Portlet Klasse
package statPortlet ;
2
3
4
5
import org . apache . jetspeed . portlet .*;
import org . apache . jetspeed . portlets .*;
import java . io .*;
6
7
8
public class statPortlet extends AbstractPortlet {
protected static final String jspNormalView = " / PORTLET INF / html / statPortletView . jsp " ;
9
public void service ( PortletRequest request ,
PortletResponse response )
throws PortletException , IOException {
String jsp = jspNormalView ;;
( getPortletConfig () . getContext () ) . include ( jsp , request ,
response ) ;
}
10
11
12
13
14
15
}
Listing 3: PORTLET-INF/classes/statPortlet.java
Die Minimalanforderung an diese Klasse ist die Selektion einer Java Server
Page (JSP), die beim Aufruf des Portlets angezeigt wird. In diesem Beispiel
gibt es nur die Normalansicht, die in der JSP Datei statPortletView.jsp
definiert wird.
Alle Ansichten, die im PDD in der <supports> Sektion definiert sind, müssen
in der Java Klasse selektiert werden und umgekehrt, d.h. der PDD teilt dem
Portalserver nur die Existenz der verschiedenen Ansichten mit.
6 PORTLETPROGRAMMIERUNG
6.3.3
28
Java Server Page
Eine Java Server Page verhält sich ähnlich zu Skriptseiten, die in PHP oder
ASP programmiert werden. Es wird HTML mit Präprozessoranweisungen
vermischt, die vor der Anzeige der Seite in statischen HTML Code umgewandelt werden. In diesem Beispiel haben wir auf solchen dynamischen Code außer dem setzen des Typs des Content Typs vollkommen verzichtet. Die
Ausgabe des Portlets ist lediglich: statPortlet Ausgabe.
1
<% @ page contentType = " text / html " errorPage = " " % >
2
3
<P > statPortlet Ausgabe </ P >
Listing 4: PORTLET-INF/html/statPortletView.jsp
6.4
Einbinden in den Portalserver
Nach dem Erstellen des Portlet-Archivs statPortlet.jar mittels der Batch
Datei enthält diese 5 Dateien:
\PORTLET-INF\portlet.xml
\PORTLET-INF\classes\myPortlet\statPortlet.java
\PORTLET-INF\classes\myPortlet\statPortlet.class
\PORTLET-INF\html\statPortletView.jsp
\META-INF\MANIFEST.MF
Die Datei MANIFEST.MF wird vom Java Archiver automatisch hinzugefügt,
und enthält Meta-Informationen über das PAR, die in unserem Fall nicht
relevant sind. Weitere Informationen zum Manifest unter [4].
Diese PAR Datei wird dann über das Administrationsinterface des Websphere Portal Servers installiert, und einer Portalserver Seite zugeordnet (siehe
Abbildung 15).
6.5
Dynamisches Portlet
Natürlich macht es wenig Sinn, JSP und Java zu verwenden, nur um statische
Information in einem Portlet anzuzeigen, deshalb erweitern wir in diesem
Abschnitt das Portlet, um folgende Punkte zu ermöglichen:
6 PORTLETPROGRAMMIERUNG
29
Abbildung 15: Zuordnen der Portlets zu einer Seite
• Lesen von Daten aus einer Datenbank
• Zwischenspeichern der Daten in einem JavaBean
• Verschiedene Sichten auf die Information
Um den Datenfluß zwischen den einzelnen Komponenten des Portlets besser erklären zu können
bedienen wir uns des Model-View-Controller
(MVC) Patterns (siehe auch [5]), das eine Einteilung der physikalischen Komponenten des Portlets
in logische Einheiten erlaubt.
6.5.1
Model
Das Modell bildet eine oder mehrere externe Datenquellen in eine interne
Struktur ab. Dieses Modell wird durch Java-Beans repräsentiert, die eine
Zwischenschicht zwischen Datenbank und Portlet-Logik bilden. Folgendes Listing enthält einen einfachen Code für ein Java-Bean.
1
package dynPortlet ;
6 PORTLETPROGRAMMIERUNG
2
3
4
import java . util .*;
import java . text .*;
5
6
7
8
9
public class dynPortletBean
{
private String userid ;
private Integer custno ;
10
public void setUserid ( String i ) {
userid = i ;
}
11
12
13
14
public void setCustno ( Integer i ) {
custno = i ;
}
15
16
17
18
public String getUserid () {
return ( userid ) ;
}
19
20
21
22
public Integer getCustno () {
return ( custno ) ;
}
23
24
25
26
}
Listing 5: PORTLET-INF/classes/dynPortlet/dynPortletBean.java
Für alle Variablen existiert jeweils eine set- und
eine get-Methode. Der Zugriff auf die Variablen
erfolgt immer indirekt über diese Selektoren. Der
Vorteil dieser Vorgehensweise ist, dass die Daten
der jeweiligen Felder an dieser Stelle auf Konsistenz überprüft (z.B. ist die Custno immer 3stellig?) und vor der Ausgabe formatiert werden
können. In unserem Beispiel werden die Werte nur
gespeichert.
30
6 PORTLETPROGRAMMIERUNG
6.5.2
31
Controller
Der Controller agiert als Schaltzentrale zwischen
den anderen Komponenten. Er erneuert bei Benutzereingaben sowohl die Ausgabe für den Benutzer (View) als auch das Datenmodell (Model). In unserem Beispiel fungiert die Java-Klasse
dynPortlet.java als Controller. Beim statischen
Portlet hatte sie lediglich die Aufgabe, den View
zu selektieren, wenn das Portlet angezeigt werden.
Die Änderungen im Vergleich zum statischen Portlet sind folgende:
• Es gibt nun 2 Ansichten für das Portlet (Zeilen 9 und 10), die je nach
Anzeigetyp selektiert werden.
• In Zeile 17 wird das Java Bean instanziiert, in das die Userid (Login
Name des Benutzers) und die Custno aus der Datenbank geschrieben
wird.
1
package dynPortlet ;
2
3
4
5
6
import
import
import
import
org . apache . jetspeed . portlet .*;
org . apache . jetspeed . portlets .*;
java . io .*;
java . sql .*;
7
8
9
10
public class dynPortlet extends AbstractPortlet {
protected static final String jspNormalView = " / PORTLET INF / html / dynPortletView . jsp " ;
protected static final String jspMaxView
= " / PORTLET INF / html / dynP ortlet MaxView . jsp " ;
11
12
13
14
public void service ( PortletRequest request ,
PortletResponse response )
throws PortletException , IOException {
String jsp = null ;
15
16
17
if ( request . getMode () == Portlet . Mode . VIEW ) {
dynPortletBean dPB = new dynPortletBean () ;
18
19
20
21
Integer custno = new Integer (0) ;
PortletSession session = request . getSession () ;
User user = session . getUser () ;
22
23
PrintWriter writer = response . getWriter () ;
6 PORTLETPROGRAMMIERUNG
32
24
response . getWriter () . println ( " Href = ’ " + url ) ;
25
26
try {
ResultSet result ;
Connection con = DriverManager . getConnection ( " jdbc :
db2 : WW " , " db2name " , " db2pass " ) ;
Statement select = con . createStatement () ;
result = select . executeQuery ( " select dP . custno from
administrator . dynPortlet dP where dP . userid = ’ " +
user . getUserID () + " ’" ) ;
27
28
29
30
31
32
if ( result . next () ) {
custno = new Integer ( result . getInt (1) ) ;
}
else {
writer . println ( " Keinen Eintrag für UserID gefunden .
");
return ;
}
33
34
35
36
37
38
39
}
catch ( Exception e ) {
writer . println ( " D at en bankv e rbindung schlug fehl . " ) ;
return ;
}
40
41
42
43
44
45
PortletData pData = request . getData () ;
46
47
dPB . setUserid ( user . getUserID () ) ;
dPB . setCustno ( custno ) ;
48
49
50
request . setAttribute ( " dynPortletBean " , dPB ) ;
51
52
if ( ( request . getWindow () ) . isMaximized () == true ) {
jsp = jspMaxView ;
}
else {
jsp = jspNormalView ;
}
53
54
55
56
57
58
}
59
60
( getPortletConfig () . getContext () ) . include ( jsp , request ,
response ) ;
61
}
62
63
}
Listing 6: PORTLET-INF/classes/dynPortlet/dynPortlet.java
Im try-catch-Block des Controllers wird die Information zur Übergabe an
6 PORTLETPROGRAMMIERUNG
33
das Bean aus der Datenbank entnommen. An dieser Stelle könnte man sich
überlegen, ob die Datenbankabfrage innerhalb des Controllers oder innerhalb des Beans gemacht werden soll. Welche Möglichkeit sinnvoller ist, muss
von Fall zu Fall entschieden werden. Bei mehreren Beans und einer Datenbank ist es sinnvoller die Verbindungsdaten zentral zu halten, sei dies nun
im Controller, in einer Bean-Superklasse oder dem Session Objekt. Bei mehreren Beans, die jeweils für sich eine Verbindung zu einer unterschiedlichen
Datenbank öffnen kann eine dezentrale Speicherung der Verbindungsdaten
sinnvoller sein. Da wir hier lediglich mit einer Datenbank und einem Bean
arbeiten haben wir uns für die zentrale Speicherung entschieden.
6.5.3
View
Grundsätzlich wird ein View im MVC-Pattern
dazu verwendet, die Daten aus dem Model anzuzeigen. Diese Aufgabe übernehmen bei Portlets
die Java Server Pages. Die statische JSP Datei
wurde erweitert, um die Felder Userid und
Custno mittels der Selektoren aus dem Bean zu
holen (Zeilen 8 und 10).
1
<% @ page contentType = " text / html " errorPage = " " % >
2
3
< jsp : useBean id = " dynPortletBean " class = " dynPortlet .
dynPortletBean " scope = " request " / >
4
5
<P > dynPortletView . jsp : </P >
6
7
8
9
10
11
<P >
myPortletBean . getUserid () : <%= myPortletBean . getUserid () % >
<BR >
myPortletBean . getCustno () : <%= myPortletBean . getCustno () % >
</P >
Listing 7: PORTLET-INF/classes/dynPortlet/dynPortletView.jsp
Diese Sicht auf die Daten definiert die normale Ansicht auf das Portlet, wenn
es im Portalserver aufgerufen wird. Da die Java Klasse eine weitere Sicht vorsieht (maximierte Sicht), wird entsprechend eine weitere JSP Datei angelegt,
die die Daten für diese Ansicht entsprechend aufbereitet. Da unsere Datenbasis im Beispiel sehr klein ist, verzichten wir hier auf das Listing. Im folgenden
sind 3 Screenshots von möglichen verschiedenen Sichten auf die Datenbasis
eines Versicherungsportfolio abgebildet, die jeweils nach einer Benutzeraktion
6 PORTLETPROGRAMMIERUNG
(Klick auf einen Link) eine andere Ansicht der Daten bieten.
Abbildung 16: Verschiedene Ansichten auf die Daten
Abbildung 17: Verschiedene Ansichten auf die Daten
34
7 DER IBM WEBSPHERE PORTALSERVER 4.1
35
Abbildung 18: Verschiedene Ansichten auf die Daten
7
Der IBM WebSphere Portalserver 4.1
Als unser Projekt im Jahre 2001 begann, bedienten wir uns der Version 2.1
des WebSphere Portalservers. Im Jahre 2002 wurde die Version 4.1 veröffentlicht,
und wir wollen kurz auf die Unterschiede dieser beiden aufeinanderfolgenden
Releases aufmerksam machen.10 .
7.1
Merkmale von WPS 4.1
Ein Hauptmerkmal von WPS 4.1 ist der Versuch der Standardisierung. IBM
arbeitet im Java Community Process mit anderen Firmen zusammen um den
Portlet Container und die dazugehörende Portlet API zu standardisieren.
Der Portlet Container ist das interne Portal Framework, das Host-Portlet
im Portalserver. Der Grund ist einfach: Eine Standardisierung ermöglicht
dem Entwickler das Schreiben eines Portlets, welches dann auf verschiedenen
Portalplattformen laufen kann.
Die Portlet API in WPS 4.1 wurde an den Java Community Process geschickt
und ist ein möglicher erster Schritt zur Portlet API Standardisierung.
Weitere WPS 4.1 Features:
• Einverständnis mit der J2EE Spezifikation
• Engere Integration mit dem Application Server.
• Erneuerte und verbesserte Portlet API:
10
WebShpehere Portal Version 4.1 - Portlet Migration Guide, 2nd Edition
7 DER IBM WEBSPHERE PORTALSERVER 4.1
36
– Portlets erben von der Servlet Klasse.
– Portlets benutzen Dienste, die der Application Server zur Verfügung
stellt.
– Neue Portal Funktionen:
∗ Portlet dynamic configurations
∗ Portlet page contributions
Durch die Unterstützung neuer Funktionen in der API wurden Änderungen
eingebracht, die die die Abwärtskompatibilität beeinträchtigen, und das Ändern
existierender Portlets notwendig machen. Diese Änderungen sind meist minimal, doch sie erfordern das erneute kompilieren und komprimieren jedes
Portlets.
7.2
Unterschiede zwischen WPS 2.1 und WPS 4.1
Zusätzliche Designänderungen das existierende Portlets beeinflussen:
• Portlet Interface wurde mit der Abstract Portlet Klasse in WPS 4.1
ersetzt. Portlets können direkt von der Portlet Klasse erben. Jedoch ist
es zu empfehlen das Portlets Hilfsklassen benutzen, wie MVCPortlet
oder PortletAdapter, da diese Methoden und Signaturen dieser Klassen entlang den Portalversionen beibehalten wurden.
• Portlet Messaging wurde erweitert. Portlets können jetzt Nachrichten
zu anderen Portlet Anwendungen senden, indem man die
DefautlPortletMessage Klasse benutzt. Das Nachrichten sendende
Portlet und das Nachrichten empfangende Portlet müssen auf der gleichen Portlalseite sein.
• Portlets können nur Werte im PortletData Objekt speichern, wenn der
Portlet im Edit Modus ist. Vorher war diese Funktion im Portlet View
Modus möglich und während allen Portlet Event Handlings. Falls ein
Portlet versucht Werte zu aktualisieren, wenn es nicht im Edit Modus
ist, dann wird eine Exception geworfen.
• Erhaltung von JAAS (Java Authentication and Authorization Service)
Benutzer wurde geändert.
7 DER IBM WEBSPHERE PORTALSERVER 4.1
37
• Eine Portlet Anwendung ist definiert in zwei XML Dokumenten. Der
portlet.xml bleibt das Dokument um Portlet Anwendungenspezifische Informationen zu speichern. Das web.xml Dokument definiert die
Portlet Anwendung Klassen und initialisiert Daten zum Portal und dem
Applikation Server.
• Die SaxPortlet Klasse wurde entfernt und wird nicht mehr unterstützt.
7 DER IBM WEBSPHERE PORTALSERVER 4.1
38
Änderung der Pakete:
• Portlets werden nun in WAR (WebARchiv) Dateien zusammengefasst.
Als Minimum muss man die Portlets neu kompilieren und wieder neu
packen.
• Die Verzeichnisstruktur in einer Portlet Anwendung WAR Datei stimmt
mit der Verzeichnisstruktur einer J2EE Web Anwendung überein. Genauer gesagt, gechützte Ressourcen, Java Klassen, JAR Dateien, usw.
werden in WEB-INF Verzeichnis gespeichert. In vorherigen Versionen
wurden Portlet Assets in der PORTLET-INF Verzeichnis der PAR Datei
gespeichert.
• MVCPortlet oder AbstractPortlet bleiben unverändert.
• JSP: Vorherige Versionen benutzen PortletRequest, PortletResponse
und andere Objekte um Informationen und Werte zu erhalten um in
der JSP zu benutzen. Einige Methoden haben sich geändert. Um diese
Änderungen des Portlets zu isolieren, sollte man anstatt die request
oder response Objekte in den JSP aufzurufen, diese in dem Portlet
ausrufen und die Information zum JSP weiterleiten in einem request
bean. So wird die Änderungen der JSPs für WPS 4.1 minimiert.
• Benutze static class Variablen nur für endgültige, konstante Werte.
• Implementiere event handlers direkt in die Portlet Klasse.
Durch die Neuerungen von WPS 4.1 müssen Portlets von WPS 2.1 in WPS
4.1 migriert werden. Hier ein paar Punkte, worauf man dabei achten muss:
• Umbenennung von PAR Datei in WAR Datei
• Neue Klassenpfade einbinden
• Neben der portlet.xml existiert eine web.xml Datei
• Verzeichnisspfade in der WAR Datei ändern
8 FAZIT
8
39
Fazit
Der IBM WebSphere Portalserver 2.1 sollte unserer Meinung nach überall
dort zum Einsatz kommen, wo 2 Dinge wichtig sind:
• Einheitliches Layout
• Trennung von Layout und Funktion
Das einheitliche Layout, ein typisches Merkmal eines Portals, wird so strikt
durchgehalten, dass überall dort, wo das Design in der Hintergrund tritt und
Funktionalität im Vordergrund steht der Portalserver zur Anwendung kommen könnte.
Die vorgegebene Trennung von Ausgabe und Programmlogik gibt Entwicklerteams eine Aufgabentrennung vor, die bei anderen Technologien erst erarbeitet werden muss.
Die Installation des IBM WebSphere Portalserver 2.1 war nicht ausgereift
und hinterließ bei uns den Eindruck eines unfertigen Produkts. Wir würden
auf jeden Fall empfehlen, sich sofort mit dem WebSphere Portalserver 4.1 zu
beschäftigen, da ein Upgrade von WPS 2.1 auf WPS 4.1 nicht ohne Migration
möglich ist. Zudem ist ein potenter Rechner mit viel Hauptspeicher (mindestens 1 GB) unabdingbar, um in einem Entwicklerumfeld mit dem WPS 2.1
zu arbeiten. Es war uns leider nicht möglich, das Verhalten des WPS unter
Produktionsbedigungen zu testen.
LITERATUR
i
Literatur
[1] WebSphere
Portal
Enable
Solution
Version
2.1.
[http://www.ibm.com/software/webservers/portal/library/InfoCenter/wpf/wpfenable.pdf],
Verfügbarkeitsdatum: 13.02.2003
[2] Stephan
Hesmer,
Peter
Fischer,
Ted
Buckner,
Pervasive
Computing
Development
(2002):
Portlet
Development Guide. Introduction to the Portlet API. Edition 1.1.
[www.ibm.com/software/webservers/portal/library/PortletDevelopmentGuide.doc],
Verfügbarkeitsdatum: 13.02.2003
[3] David
B.
Lection
(2002):
WebShpehere
Portal
Version
4.1
Portlet
Migration
Guide,
2nd
Edition.
[www.ibm.com/software/webservers/portal/library/V41PortletMigrationGuide.pdf],
Verfügbarkeitsdatum: 19.02.2003
[4] Sun Microsystems (2002): Java 2 SDK, Standard Edition Documentation. [http://java.sun.com/j2se/1.4/docs],
Verfügbarkeitsdatum: 19.02.2003
[5] Sun Microsystems (2002): Java BluePrints: Model-View-Controller.
[http://java.sun.com/blueprints/patterns/MVC-detailed.html],
Verfügbarkeitsdatum: 19.02.2003
Abbildungsverzeichnis
1
Beispiel einer unpersonalisierten Portalseite von my.Yahoo.com
1
2
Beispiel einer personalisierten Portalseite von my.Yahoo.com .
2
3
Beispiel einer Portalseite mit einheitlicher Oberfläche . . . . .
3
4
Zusammenspiel anderer Komponenten mit IBM WPS Portalserver 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
Portalserver Architektur . . . . . . . . . . . . . . . . . . . . .
7
6
Der Portalserver ohne Portlets . . . . . . . . . . . . . . . . . .
9
7
Beispiel eines Portlets . . . . . . . . . . . . . . . . . . . . . . . 11
LISTINGS
ii
8
Portal Window Style . . . . . . . . . . . . . . . . . . . . . . . 17
9
Portlet Frame Style . . . . . . . . . . . . . . . . . . . . . . . . 17
10
Beispiel eines Portlets . . . . . . . . . . . . . . . . . . . . . . . 20
11
Kommunikation erfolgt mit unterschiedlichen APIs . . . . . . 21
12
Portlet API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13
Servlet API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14
Portalserver APIs . . . . . . . . . . . . . . . . . . . . . . . . . 23
15
Zuordnen der Portlets zu einer Seite . . . . . . . . . . . . . . . 29
16
Verschiedene Ansichten auf die Daten . . . . . . . . . . . . . . 34
17
Verschiedene Ansichten auf die Daten . . . . . . . . . . . . . . 34
18
Verschiedene Ansichten auf die Daten . . . . . . . . . . . . . . 35
Listings
1
Batch Datei zum compilieren der PAR Datei . . . . . . . . . . 25
2
PORTLET-INF/portlet.xml . . . . . . . . . . . . . . . . . . . 26
3
PORTLET-INF/classes/statPortlet.java . . . . . . . . . . . . 27
4
PORTLET-INF/html/statPortletView.jsp . . . . . . . . . . . 28
5
PORTLET-INF/classes/dynPortlet/dynPortletBean.java . . . 29
6
PORTLET-INF/classes/dynPortlet/dynPortlet.java . . . . . . 31
7
PORTLET-INF/classes/dynPortlet/dynPortletView.jsp . . . . 33