Eberhard-Karls-Universit˜at Tubingen˜ · Abbildung 4: Zusammenspiel anderer Komponenten mit IBM...

Eberhard-Karls-UniversitatTubingen

Fakultat fur Informations- und

Kognitionswissenschaften

Studienarbeit im Rahmen des

Universitat-Praxis-Projekt von Herr Prof. Dr. Klaeren

im WS 2001/02

Der IBM WebSpherePortalserver 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 Zustandigkeiten 9

3.1 Portalserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Anderung 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 Universitats-Praxis-Projekts im Win-tersemester 2001/2002.Das Projekt war eine Zusammenarbeit der Universitat Tubingen und derWurttembergischen und Wustenrot Versicherung.Teilnehmer auf Universitatsseite waren Il-Hyun Kim, Clemens Oertel, HorstRechner und als Betreuer Markus Leypold.

Basierend auf einer Prasentation von I.-H. Kim, C. Oertel und H. Rechnerwurden 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 Appli-kationen einheitlich aufzubereiten und im Browser darzustellen.Portale findet man im Internet, z.B. bei Yahoo, AOL, Compuserve oder T-Online. Die ursprungliche Idee zur Entwicklung eines Portals war eine Ent-sprechung der Gelbe Seiten fur das Internet. Diese Idee wurde weiterent-wickelt und die Information, auf die ursprunglich gelinkt wurde, wird jetztdirekt auf der Portalseite angezeigt. Z.B. konnen bei MyYahoo1 die Nach-richten, Aktienkurse und das Wetter angezeigt werden.

Abbildung 1: Beispiel einer unpersonalisierten Portalseite von my.Yahoo.com

1my.yahoo.com

1 EINLEITUNG 2

Sie bieten ihren Kunden u.a. eine Personalisierung, d.h. eine individuelleAnpassung 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 (singlesign-on login) durch den Benutzer ermoglicht diesem, alle im Por-tal enthaltenen Dienste mit einem Passwort zu benutzen.• Eine Personalisierung basierend auf Profilen bzw. dem Ver-halten des Benutzers, d.h. passend zu Benutzerdaten, wie z.B.Geschlecht und Geburtstag, konnen das Verhalten des Portalsbeeinflussen.• Navigation- und Layouteinstellungen der Seiten wird durcheine Administrationsseite ermoglicht. Der Benutzer kann damitdie Anzahl der angebotenen Dienste und das Aussehen bestim-men.• Suchfunktion

Dabei werden die aufsteckbaren Portalkomponenten Portlets genannt. Ein

1 EINLEITUNG 3

Beispiel fur ein Portlet ware das Wetter oder die Nachrichten auf einer Por-talseite.

Abbildung 3: Beispiel einer Portalseite mit einheitlicher Oberflache

2 DER IBM WEBSPHERE PORTALSERVER 2.1 4

2 Der IBM WebSphere Portalserver 2.1

In diesem Kapitel werden kurz die Voraussetzungen fur die Installation einesIBM WebSphere Portalserver 2.1 geklart2.

2.1 Voraussetzungen

Abbildung 4: Zusammenspiel anderer Komponenten mit IBM WPS Portal-server 2.1

Um den IBM WebSphere Portalserver (WPS) installieren zu konnen, brauchtman entweder einen Intel basierten Computer, eine RS/6000 SP oder eineSolaris.Nach IBM benotigt man 60 MB oder mehr freien Festplattenspeicher, 512MB oder mehr Arbeitsspeicher und ein CD-ROM Laufwerk.Ein Intel basierter PC benotigt eines der folgenden Betriebssysteme:

2WebSphere Portal Enable Solution Version 2.1


• Windows NT Server 4.0 mit SP4 oder SP6a• Windows 2000 Advanced Server• Windows 2000 Server Edition• Windows 2000 Database Server

Eine RS/6000 SP benotigt den AIX V4.3.3.02.Unter Solaris benotigt man fur eine Standard- oder Development-Installationdas Sun Solaris V7 oder eine Solaris V8. Fur die Advanced-Installationbenotigt man die Sun OS 2.7 fur einen Sun Server.Wie die Abbildung 4 verdeutlicht, benotigt der IBM WebSphere Portalserverfolgende Softwares, die bereits installiert sein mussen:

• 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)

Fur unsere WebSphere Portalserver Installation benotigten wir keine LDAPDirectory, da wir eine Entwickler-Installation benutzten. Mit dieser Installa-tionsart 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 Anforde-rungen Mindestanforderungen sind.Es ist empfehlenswert mehr als 512 MB Arbeitsspeicher zu besitzen, da derIBM WebShpere Portalserver sonst zu langsam arbeitet. Auch reichen nichtdie angegebenen 60 MB fur den Portalserver. Zwar braucht der Portalser-ver allein nur 60 MB Festplattenspeicher, jedoch benotigt der Portalserverzusatzliche Software, die insgesamt mehr als 500 MB Festplattenspeicherbenotigen.Inklusive Betriebssystem benotigte 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 Produktezu installieren. Es ist also eine Installation von bestimmten Fixpacks not-wendig. Falls man zum Beispiel nicht die IBM DB2 7.1 mit dem Fixpack 2ainstalliert hat, funktioniert der Portalserver nicht.Im Falle der Datenbank kann man auch den IBM DB2 Universal Database(DB2), Version 7.2 installieren. Somit entfallt die Installation des Fixpacks.Bei dem WebSphere Application Server, Advanced Edition (WAS) ist dabei


zu beachten, dass die Version 3.5.4 benotigt wird. Der WPS lauft NICHTunter WAS 4.


Unsere Versuchsplattform war ein Windowsbetriebssystem.Fur unsere Installation benutzten wir folgende Software:

• 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

2.2 Die IBM WebSphere Portalserver 2.1 Architektur

Wir wissen jetzt, welche Programme der Portalserver benotigt, damit er kor-rekt arbeiten kann.Jetzt wollen wir die Frage klaren, wie nun diese Komponenten mit dem Por-talserver zusammenarbeiten.

Abbildung 5: Portalserver Architektur


Als erstes meldet sich der Benutzer uber einen Internet Brow-ser, mobiles Telefon oder einem PDA an einem Webserver an,indem er eine URL Adresse benutzt.

Der Webserver hat dabei die Aufgabe die URL Adresse anden WAS weiterzuleiten. Wird nun die URL des Portalserversaufgerufen, ruft der WAS den WPS, der als Servlet unter demWAS eingebunden ist, auf. Die gultigen URL Adressen fur denPortalserver sind im WAS gespeichert.

Ruft der Benutzer jetzt den Portalserver auf, so muss er sichzuerst authentifizieren. Der Portalserver schaut dabei in derLDAP Directory nur nach, ob der Benutzer existiert. DasLeightweight Directory Access Protocol ist dabei ein offenerStandard fur globale oder lokale Verzeichnisdienste und/oderim Internet. Das LDAP Verzeichnis wird dabei wie ein Tele-fonbuch betrachtet, in der Namen mit Telefonnummern undE-Mail Adressen verknupft sind3. In unserem Fall wird nurnach dem Namen des Benutzers geschaut.

Hat sich der Benutzer nun authentisiert, werden seine Portletsvom Portalserver geladen. Die Benutzerdaten, sowie Daten,die die Portlets benotigen, werden in der DB2 gespeichert.Zudem liegen Daten vom LDAP Server, WAS und WPS inder DB2.

Benotigen Portlets Daten aus dem Internet, wie z.B. die aktu-ellen Wetterdaten, so haben sie die Moglichkeit, diese direktaus dem Internet zu besorgen. Dafur wird also nicht der Por-talserver benotigt.

3http://linuxline.epfl.ch/Doc/rhl-rg-de-7.0/ch-ldap.html

3 ZUSTANDIGKEITEN 9

3 Zustandigkeiten

Hat man nun den Portalserver installiert, stellt sich die Frage, welche Aufga-ben vom Portalserver und welche vom Portlet ubernommen werden. Andersgefragt: Welche Funktionen stellt IBM bereit, und was muss man selber pro-grammieren?

3.1 Portalserver

Abbildung 6: Der Portalserver ohne Portlets

3 ZUSTANDIGKEITEN 10

Die Abbildung 6 deutet an, fur was der Portalserver zustandig ist:

• Authentifizierung

Der Portalserver wickelt die Verwaltung der Authentifizierungsabfragen, wiez.B. mit dem LDAP Server, ab. Das Layout der Login und Passwortabfragenkonnen hier verandert werden.

• Corporate Identity

Das Layout der HTML Seiten wird vom Portalserver festgelegt. Dabei ver-wendet der Portalserver Stylesheets. Stylesheets sind ein Zusatz zu HTML,die es ermoglicht, die Formatierung von Webseiten fur den Programmiererubersichtlicher und eindeutiger zu gestalten, so dass das Ergebnis nicht aufunterschiedlichen Plattformen unterschiedlich aussieht. Viele Darstellungs-fehler konnen mit Stylesheets verhindert werden. Durch Veranderungen derStylesheets usw. kann man das Aussehen verandern und sie somit dem einerFirma anpassen. Man kann also Farbe und Buttons oder Bilder verandernbzw. reinstellen.

• Positionierung von Portlets, Tabs, Anzahl Spalte

Die Positionierungen gehoren auch zum Layout und werden im Portalserververwaltet und konnen auch dort verandert werden.

• Portlet Management

Der Portalserver ist durch den Administrationsportlet in der Lage zu bestim-men, welche Seiten und welche Portlets fur welchen Benutzer gezeigt werdensollen.

Die Funktionen der Authentifizierung, Positionierung von Portlets usw. unddas Portlet Management werden vom IBM geliefert. So ist eigene Program-mierung, außer zur Veranderung des Aussehens, nicht notwendig.

3 ZUSTANDIGKEITEN 11

3.2 Portlets

Abbildung 7: Beispiel eines Portlets

Am Beispiel der Abbildung 7 wird verdeutlicht, fur was das Portlet zustandigist.

• InhaltFur den Inhalt sind Daten zustandig, die abgefragt bzw. abgear-beitet. Die ganze Datenverarbeitung lauft uber also das Portletab.

• LogikFur die Logik verwendet das Portlet Beans.

• AnsichtIm 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 programmierenmuss. In unserem Fall W&W. Der Rest ubernimmt der Portalserver, d.h.also IBM.

4 PORTALENTWICKLUNG 12

4 Portalentwicklung

Im vorherigen Kapitel haben wir nun gelernt, fur was der Portalserver zustandigist.In diesem Kapitel wird nun gezeigt, was und wo man am Portalserver pro-grammieren kann4.

4.1 Portalmodifikation

Der Portalserver dient als Prasentationsframework. Die internen Ablaufe wiedie Authentifizierung werden vom IBM geliefert und mussen nicht program-miert werden. Das einzige, was man verandern kann, ist das Aussehen desPortals.Hier wird nun kurz erklart, wie man den Portalserver den optischen An-spruchen einer Firma anpassen kann. In unserem Beispiel W&W.Das schließt das Hinzufugen, Entfernen oder Andern von Texten, Farben,Bildern, Links, Portletsgrenzen, und sogar das Layout der Portalseite mitein. Viele Anderungen erfordern das Loschen des Portal Server Caches, dersich im Application Servers /temp/default host Verzeichnis befindet und denNeustart des Portalservers.

4.1.1 Company Information

Der Text das im Banner angezeigt wird ist in der Dateiengine\_lang.properties definiert und befindet sich im Verzeichniswps\_root/app/web/WEB-INF/classes/nls/. Dabei ist lang der Sprachco-de, entsprechend den Lokalen Einstellungen des Clients. Als Beispiel ist dieengine\_es.properties die Datei, in der das Banner Text fur spanischeClients definiert ist. Falls der WebSphere Portal Server die Sprache des Cli-ents nicht bestimmen kann, so ist der Banner Text in engine.properties

definiert. Um nun den Banner Text fur jede unterstutzte Sprache zu andern,befolge diese Schritte:

1. Editiere die engine\_lang.properties Datei.2. Andere die title Parameter in den Namen der im Portalban-ner angezeigt werden soll.

4WebSphere Portal Enable Solution Version 2.1


3. Speichere und schließe die engine\_lang.properties Da-tei.4. Starte den Application Server fur den WebSphere Portal Ser-ver neu.

4.1.2 Look and Feel (Themes und Skins)

Das Aussehen der Portal Server Seiten werden durch Themes und Skins be-stimmt. Themes reprasentieren das allgemeine ,,Look and Feel“ des Portals.Das schließt die Schriftart und Farbe mit ein. Skins reprasentieren das Rah-men Rendering um ein einzelnes Portlet. Skins benutzen den Theme Namenum die passenden Grafiken auszusuchen.

Der WebSphere Portalserver liefert schon eine Reihe von vorgefertigten The-mes und Skins. Nach der Installation benutzt WebSphere Portalserver denDefaultTheme. Um die vorgefertigten Themes und Skins zu benutzen be-folgen Sie folgende Schritte:

1. Bearbeite die Datei TurbineResources.properties im Ver-zeichnis wps\_root/app/web/WEB-INF/conf.2. Andere die skin.default Parameter in eine der folgende Wer-te:

• Album• Hint• Outline• ShadowBeachte: Falls Sie die Werte leer lassen, werden dieStandardwerte genommen.

3. Andere die theme.default in eine der folgende Werte:

• GreyTheme• KhakiTheme• LilacTheme• TealThemeBeachte: Sie konnen die Werte als DefaultThemebelassen. Jedoch im Gegensatz zu skin.default konnenSie den Wert nicht leer lassen.

4. Speichern und schließen Sie die TurbineResources.propertiesDatei.


5. Starten Sie den WebSphere Application Server fur den Web-Sphere Portalserver neu.

Man kann naturlich auch eigene Themes definieren. Dies setzt voraus, dassman eigene Bilder und ein passendes Stylesheet erstellt. Die folgende Schrittesetzt voraus, dass man keinen Skin fur den Portal benannt hat (d.h. derskin.default Parameter ist leer).

1. Gehe in das wps\_root/app/web/images/theme Verzeich-nis.2. Erstelle ein Unterverzeichnis mit dem Namen des neuen The-mes, z.B. WWTheme.3. Kopiere die Dateien vom Verzeichniswps\_root/app/web/images/themes/DefaultTheme in das Ver-zeichnis /WWTheme.4. Andere die neuen Bilder damit sie mit dem neuen Themeubereinstimmen. Alle Veranderungen sollten mit den Anderungendes Stylesheets ubereinstimmen.

a. Portal Bannerb. Navigation Icons

i. Nav\_create\_account.gif

ii. Nav\_customize.gif

iii. Nav\_forget\_password.gif

iv. Nav\_help.gif

v. Nav\_login.gif

vi. Nav\_logoff.gif

vii. Nav\_profile.gif

c. Tab Ecken

i. Tab\_left.gif

ii. Tag\_right.gif

d. Icons fur 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


5. Wechseln in das wps\_root/app/web/css Verzeichnis.6. Erstelle Kopien von den Dateien DefaultTheme.css undDefaultTheme\_ie.css mit dem neuen Theme Namen,z.B. WWTheme.css und WWTheme\_ie.css.7. Bearbeite die beiden Stylesheets und passe die Anderungendes neuen Themes an. Die WWTheme\_ie.css Stylesheet is speziellfur den Internet Explorer. Alle Anderungen der Style Definitio-nen zwischen den beiden Dateien sind gleich mit Ausnahme derSchriftgroße, welche je nach verwendeten Browser unterschiedlichsein konnen. Wie man die Portal Style Klassen andert wird imnachsten Kapitel (Portal Stylesheet Klasse) erlautert.8. Speichere und schließe die Dateien.9. Bearbeite die Datei TurbineResources.properties in demVerzeichnis wps\_root/app/web/Web-Inf/conf.10. Andere den theme.default Parameter in den neuen The-me Namen, z.B. WWTheme.11. Speichere und schließe die TurbineResources.propertiesDatei.12. Starte den WebSphere Application Server fur den WebSphe-re Portalserver neu.

Nun haben wir einen eigenen Theme erstellt und mussen jetzt die Skinserstellen:

1. Wechseln in das Verzeichnis wps\_root/app/web/images/skins.2. Erstelle ein neues Unterverzeichnis mit dem Namen der neu-en Skins, z.B. WWSkin.3. Kopiere die Dateien vom Verzeichniswps\_root/app/web/\\images/skins/Album in /WWSkin.4. Andere 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 fur jedes Theme das dem Port-let zu Verfugung steht, einschließlich den angepasstenThemes.

5. Wechseln zum Verzeichniswps\_root/app/web/temp\-lates/skins/html.

6. Erstelle ein neues Unterverzeichnis mit dem Namen des neu-en Skins, z.B. WWSkin.7. Kopiere die Datei TitleBarControl.jsp vom Verzeichniswps\_root/app/web/templates/skins/html/Album in das /WWSkinVerzeichnis.8. Bearbeite die TitleBarControl.jsp Datei.9. Suche die Datei fur die Bilder der Ecken der Rahmen. DieseBilder sind mit dem <img> Tag definiert. Die Quelle der Bildersieht so aus:Src=’<wps:url type=“base“/>images/skins/Album/Border<wps:theme/> TopLeft.gif ’. Andere 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 fur alle wei-teren Eckbilder.10. Speichere und schließe TitleBarControl.jsp.11. Bearbeite die Datei TurbinResources.properties im Ver-zeichnis wps\_root/app/web/WEB-INF/conf.12. Andere den Wert von skin.default in den Namen des neu-en Skins.13. Speichere und schließe die TurbinResources.properties

Datei.14. Starte den WebSphere Application Server fur den WebSphe-re Portalserver neu.


4.1.3 Portal Stylesheet Klasse

Die im vorherigen Kapitel (Look and Feel) erwahnten Stylesheets besitzenKlassen, die sich im Verzeichnis wps\_root/app/web/css befinden und vomPortal benutzt werden.

1. Portalfenster

Abbildung 8: Portal Window Style

Stylesheet Klasse BeschreibungA wpsPortalBanner Definiert Farbe und Schriftart in dem Gebiet

in dem der Firmenname erscheintB wpsPortalText Gleiches Style wie wpsPortalBanner mit

Ausnahme das das Hintergrundbild fehlt. Be-nutze dies fur Gebiete des Banners in der keinHintergrundbild benutzt wird.

C wpsMainNav, wps-MainNavTabs

wpsMainNav wird fur die rechte Seite desNavigationsgebietes, wpsMainNavTabs wirdfur die linke Seite des Navigationsgebietesum die Seitentabs benutzt.

D wpsTabs, wpsSelec-tedTabs

Benutze diese Klassen fur die Eigenschaftender Navigationstabs

2. Portletrahmen

Abbildung 9: Portlet Frame Style


Stylesheet Klasse BeschreibungE wpsPortletTitle Fur Portlet Titel Eigenschaften, einschließ-

lich Hintergrund- und Vordergrundfarbe,Padding und Schriftart

F wpsPortletBody Fur das Gebiet in der das Portlet sei-nen Inhalt anzeigt, einschließlich der Sei-tenrandhohe und Breite (margin width undheight).

Weitere Portlet Stylesheet Klassen sind Text und Hintergrund Style undTable Style5.

4.1.4 Anderung der Portal Hilfe Seiten

Der WebSphere Portalserver stellt eine Hilfe Seite zur Verfugung. Man kanndie Hilfe Seite den eigenen Bedurfnissen anpassen und z.B. Informationender eigenen Firma hineinstellen. Die Portal Hilfe ist eine Ansammlung vonHTML Dateien und GIFs. Sie befinden sich im Verzeichniswps\_root/app/web/html/lang, wobei wps\_root das Hauptverzeichnis vomWebSphere Portalserver ist und lang der Sprachcode.Die Hauptdatei des Portals ist phelp\_index.html. Diese Datei enthaltLinks zu allen anderen Hilfe Dateien.Die Original Hilfe Dateien gibt es in mehreren Sprachen. Falls man mehrereSprachen unterstutzen will, muss man die neuen Dateien ubersetzen.ˆBevor man mit Anderungen anfangt, sollte man einen Satz Kopien der Ori-ginal Hilfe Dateien als Backup machen

4.2 Portal Layout

Die folgenden Punkte beinhalten Informationen, die das Bearbeiten des HTMLLayouts erleichtern sollen.Beachte: Falls Anderungen von Portalseiten beim Testen nicht auftreten,sollte man den WebSphere Application Server Cache loschen, der sich inwas\_root/temp/default\_host/wps befindet.

• Elemente von PortalseitenDas Layout der Portalseiten beginnt mit dem Markup in Default.jsp

5WebSphere Portal Enable Solution Version 2.1, S. 215f

im Verzeichniswps\_root/app/web/templates/layout/html. Default.jsp teiltdie Portalseite in drei Gebiete ein:

1. HeadDie Datei ./elements/Head.jsp fragt die Titelseitenab und ruft Style Sheets fur verschiedene Browser auf.Head ist nicht Teil des Portal Layout.

• Andern der Titelseite haben wir schon inI. kennengelernt.• Um neue Style Sheets zu benutzen, erstelleneue und setze ein Link zu den Stylesheets vonHead.jsp. Benutze den <wps:url> Tag um denStandort der Stylesheets anzuzeigen.

2. BannerDie elements/Banner.jsp definiert das Layout des Kopf-es der Portalseite.3. ScreenDas <wps:screen/> Element definiert das Gebiet furdie Portlets, das angezeigt wird. Administratoren undBenutzer definieren das Layout der Portlets, indem sieden Customizer benutzen.

• Tags, die von dem Portal JSPs benutzt werden:Vom Portal Engine verfugbare Tags beginnen mit <wps:...>. Dieentsprechende Taglib Datei ist engine.tld und befindet sich imwps\_root/app/web/WEB-INF/tld Verzeichnis. Diese Tags konnenbenutzt werden, um das Layout der Portalseite zu modifizieren.Einige Tags sind:<wps:date> Schreibt die aktuelle Zeit.<wps:if> Damit konnen Bedingungen abgefragt werden.<wps:theme\texttt> Fragt den Wert des default.theme Para-meter in Turbine.properties ab. Abhangig vom Wert wird dasentsprechende Theme gesetzt.

Es gibt noch viel mehr Tags6, die wir aber hier nicht alle vorstellenwerden.

6WebSphere Portal Enable Solution Version 2.1, S.221f

5 PORTLET 20

5 Portlet

Nun kennen wir den Portalserver. Was ist nun mit den Portlets?In diesem Kapitel werden kurz die Portlets erklart. Deren Programmierungwird im nachsten Kapitel gezeigt. Hier werden kurz die Funktionen und Zu-sammenhange 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 Portalserverlauft. Sie fuhren eine vordefinierte Rolle aus. Ein Portlet ist eineFunktion.• spezialisierte Servlets.Sie benutzen neben der Servlet API auch eine Portlet API. Da-durch ist der Zugriff auf Informationen von Benutzerprofilen, diein einer Datenbank gespeichert sind, moglich.Sie verbinden sich also mit Datenbanken und verarbeiten die In-formationen, die sie erhalten. Die Daten werden pro Portlet In-stanz durch das Portal gespeichert, d.h. die Ausgabe verlauft uberdas Portal.

5 PORTLET 21

Mit der Portlet API lassen sich auch verschiedene Ansichten desPortlets definieren.

5.2 API (Application Program Interface)

Der Portalserver unterstutzt verschiedene Schnittstellen und Methoden, ge-nannt API, um verschiedene Dienste zu erhalten. Die APIs definieren dieSchnittstellen die Kompatibilitat zwischen Portal und Portlets. Dabei ba-sieren die APIs auf die Java Servlet API. Die verschiedenen APIs, die derPortalserver verwendet, werden nun im folgenden beschrieben7.

Abbildung 11: Kommunikation erfolgt mit unterschiedlichen APIs

7Portlet Development Guide. Introduction to the Portlet API. Edition 1.1

5 PORTLET 22

5.2.1 Portlet API

Die Portlets befinden sich innerhalb des Portalservers in einem Portlet Con-tainer. Mit der Portlet API kommunizieren die Portlets mit dem PortletContainer des Portalservers. Die Klassen fur die Portlet API wird vom IBMmitgeliefert.

Abbildung 12: Portlet API

5.2.2 Servlet API

Der Portalserver wird als Servlet in den WAS eingehangt. Um nun mit demWAS zu kommunizieren, verwendet der Portalserver die Servlet API.

Abbildung 13: Servlet API

5 PORTLET 23

5.2.3 J2EE API

Portlets und Portalserver unterstutzen auch die J2EE API (Java 2 Platform,Enterprise Edition). Diese wird benotigt, um z.B. mit Java Enterprise Beanskommunizieren zu konnen. U.a. auch mit Web Services.

Abbildung 14: Portalserver APIs

Portlets benutzen also nicht nur eine API (Application Programmer Inter-face). Sie benutzt neben der Portlet API auch die Servlet API, um z.B. mitdem WAS zu kommunizieren. Der Portalserver wird als Servlet in den WASeingehangt. Es unterstutzt auch die J2EE (Java 2 Enterprise Edition) API,um z.B. mit den Java Enterprise Beans kommunizieren zu konnen.Beispiele von API Aufrufen werden im Rahmen des nachsten Kapitels, Le-benszyklus eines Portlets, gezeigt.

5.3 Lebenszyklus eines Portlets (API Aufrufe)

Im Laufe des Lebens eines Portlets werden darin entprechende Methodenaufgerufen. Dabei ist der Lebenszyklus eines Portlets dem eines Servlets sehrahnlich. Zu den schon bekannten Methoden eines Servlets besitzt der Le-benszyklus eines Portlets noch zwei zusatzliche Methoden8 9.

• init();

Das Portlet wird nach der Portalinizialisierung aufgebaut und dann mit derinit Methode initialisiert. Das Portal instanziiert immer nur eine Instanzvom Portlet, und diese Instanz wird von allen Benutzern geteilt. Ahnlich wiedas Servlet, das mit allen Benutzern eines Applikationsservers geteilt wird.

8Portlet Development Guide. Introduction to the Portlet API. Edition 1.19WebSphere Portal Enable Solution Version 2.1

5 PORTLET 24

• login();

Nachdem ein Benutzer sich in das Portal eingeloggt hat, erstellt jedes Portleteine Session fur den Benutzer. Die Kombination der physikalischen PortletInstanz 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 dieInitialisierung der Benutzer Session Instanz des Portlets, um z.B. Attributein die Session zu speichern.

• service();

Das Portal ruft die service Methode auf, wenn es fur das Portlet erforderlichwird, seinen Inhalt zu rendern. Wahrend das Lebenszyklus eines Portlets wirdtypischerweise die service Methode oft aufgerufen.

• logout();

Wenn der Benutzer die Verbindung (Sitzung) mit dem Portal beendet (sichvom Portal abmeldet), ruft der Portalserver die logout Methode auf, umden Portlet zu informieren, dass die Session Instanz des Benutzers beendetwird. Das Portlet sollte nun alle Ressourcen der virtuellen Instanz loschen.

• taken out of service:

destroy();

Werden Portlets einmal geladen und initialisiert, dann laufen, wie bei denServlets, immer. Der Systemadministrator kann aber das Portlet zerstoren,z.B. durch das Runterfahren des Portalservers. Dabei wird die destroy Me-thode aufgerufen. Sie gleicht dem des Servlets. Diese Methode wird nur ein-mal aufgerufen, bis der Portalserver wieder die init Methode aufruft, umdas Portlet wieder zu laden und zu initialisieren. Typischerweise beim Startendes Portalservers.

6 PORTLETPROGRAMMIERUNG 25

6 Portletprogrammierung

6.1 Spannbreite

Fur die Implementierung eines Portlets gibt es eine große Spannbreite. Zumeinen kann man ein Portlet lediglich dazu benutzen eine statische HTMLDatei zu generieren. Auf der anderen Seite steht eine Kombination aus JavaBeans, Java Server Pages und XML, die dynamisch die verschiedenen An-sichten des Portlets mit Inhalten aus einer Datenbank fullt.Im folgenden werden beide Varianten in ihrer einfachsten Auspragung mitCodebeispielen behandelt.

6.2 Portlet Archiv Datei

Fur statische und dynamische Portlets gelten die selben Richtlinien fur dieIntegration in den Websphere Portalserver.Die Portlets werden dem Server in einer gepackten Datei ubergeben, die beimStart dann in das Arbeitsverzeichnis entpackt, und von dort aus ausgefuhrtwird. Die grundlegende Verzeichnisstruktur fur die einzelnen Dateien ist da-bei folgende (siehe auch [3]):

/ - Root Directory/PORTLET-INF/portlet.xml - Der Portlet Descriptor, der grundlegende In-formationen uber das Portlet enthalt./PORTLET-INF/classes/ - In diesem Verzeichnis befinden sich die Java Klas-sen./PORTLET-INF/html/ - Die Java Server Pages befinden sich in diesem Ver-zeichnis.

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 Ubersetzung der Java Klassen und das anschließende Komprimie-ren automatisiert. Eine typische Batch Datei hat folgende Gestalt:

1 set root=C:/ Portlets/statPortlet2 javac -d %root%/PORTLET -INF/classes %root%/PORTLET -INF/

classes/statPortlet/statPortlet *.java3 jar cvf0 statPortlet.jar PORTLET -INF4 erase statPortlet.par5 rename statPortlet.jar statPortlet.par

Listing 1: Batch Datei zum compilieren der PAR Datei

Der Befehl jar erzeugt die PAR Datei, die schlußendlich in den Portalservereingebunden wird, und um Grunde genommen nichts anderes als eine JavaArchiv Datei mit anderer Endung ist.

6.3 Statisches Portlet

Fur ein statisches Portlet sind drei Dateien notwendig, die in die PAR Dateieingebunden werden.

6.3.1 Portlet Deployment Descriptor

Der Portlet Deployment Descriptor (PDD)enthalt Metainformationen uber dasPortlet, wie die unterstutzten Sprachen(<language locale="en"> und den damitverbundenen Titel), sowie die unterstutztenAnzeigearten (<markup name="html"> und diedamit verbundenen Ansichten).Diese Datei ist die erste, die der Portalserver beimEinbinden liest. Danach wird die Java Klasse, dieunter <portlet-class> definiert ist ausgefuhrt.

1 <?xml version="1.0"?>2 <!DOCTYPE portlet -app PUBLIC " -//IBM//DTD Portlet Application

1.0// EN" "portlet.dtd">3 <portlet -app >4 <portlet -app -name >statPortlet </portlet -app -name >5 <context -param >6 <param -name >Portlet Master </param -name >7 <param -value >[email protected] </param -value >8 </context -param >9 <portlet >

10 <portlet -name >statPortlet </portlet -name >11 <portlet -class >statPortlet.statPortlet </portlet -class >12 <portlet -type >instance </portlet -type >13 <allows >14 <maximized />15 </allows >16 <language locale="en">

17 <title >statPortlet </title >18 <title -short >statPortlet </title -short >19 <description >statPortlet macht folgendes </ description >20 <keywords >statPortlet , MeinErstesPortlet </keywords >21 </language >22 <supports >23 <markup name="html">24 <view />25 </markup >26 </supports >27 </portlet >28 </portlet -app >

Listing 2: PORTLET-INF/portlet.xml

6.3.2 Java Portlet Klasse

1 package statPortlet;2

3 import org.apache.jetspeed.portlet .*;4 import org.apache.jetspeed.portlets .*;5 import java.io.*;6

7 public class statPortlet extends AbstractPortlet {8 protected static final String jspNormalView = "/PORTLET -

INF/html/statPortletView.jsp";9

10 public void service ( PortletRequest request ,PortletResponse response)

11 throws PortletException , IOException {12 String jsp = jspNormalView ;;13 (getPortletConfig ().getContext ()).include ( jsp , request ,

response );14 }15 }

Listing 3: PORTLET-INF/classes/statPortlet.java

Die Minimalanforderung an diese Klasse ist die Selektion einer Java ServerPage (JSP), die beim Aufruf des Portlets angezeigt wird. In diesem Beispielgibt es nur die Normalansicht, die in der JSP Datei statPortletView.jspdefiniert wird.Alle Ansichten, die im PDD in der <supports> Sektion definiert sind, mussenin der Java Klasse selektiert werden und umgekehrt, d.h. der PDD teilt demPortalserver nur die Existenz der verschiedenen Ansichten mit.

6.3.3 Java Server Page

Eine Java Server Page verhalt sich ahnlich zu Skriptseiten, die in PHP oderASP programmiert werden. Es wird HTML mit Praprozessoranweisungenvermischt, die vor der Anzeige der Seite in statischen HTML Code umge-wandelt werden. In diesem Beispiel haben wir auf solchen dynamischen Co-de außer dem setzen des Typs des Content Typs vollkommen verzichtet. DieAusgabe des Portlets ist lediglich: statPortlet Ausgabe.

1 <%@ page contentType="text/html" errorPage="" %>2

3 statPortlet Ausgabe 

Listing 4: PORTLET-INF/html/statPortletView.jsp

6.4 Einbinden in den Portalserver

Nach dem Erstellen des Portlet-Archivs statPortlet.jar mittels der BatchDatei enthalt 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 hinzugefugt,und enthalt Meta-Informationen uber das PAR, die in unserem Fall nichtrelevant sind. Weitere Informationen zum Manifest unter [4].Diese PAR Datei wird dann uber das Administrationsinterface des Websphe-re Portal Servers installiert, und einer Portalserver Seite zugeordnet (sieheAbbildung 15).

6.5 Dynamisches Portlet

Naturlich macht es wenig Sinn, JSP und Java zu verwenden, nur um statischeInformation in einem Portlet anzuzeigen, deshalb erweitern wir in diesemAbschnitt das Portlet, um folgende Punkte zu ermoglichen:


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 Kom-ponenten des Portlets besser erklaren zu konnenbedienen wir uns des Model-View-Controller(MVC) Patterns (siehe auch [5]), das eine Eintei-lung der physikalischen Komponenten des Portletsin logische Einheiten erlaubt.

6.5.1 Model

Das Modell bildet eine oder mehrere externe Datenquellen in eine interneStruktur ab. Dieses Modell wird durch Java-Beans reprasentiert, die eineZwischenschicht zwischen Datenbank und Portlet-Logik bilden. Folgendes Li-sting enthalt einen einfachen Code fur ein Java-Bean.

1 package dynPortlet;


2

3 import java.util .*;4 import java.text .*;5

6 public class dynPortletBean7 {8 private String userid;9 private Integer custno;

10

11 public void setUserid(String i) {12 userid = i;13 }14

15 public void setCustno(Integer i) {16 custno = i;17 }18

19 public String getUserid () {20 return ( userid);21 }22

23 public Integer getCustno () {24 return ( custno);25 }26 }

Listing 5: PORTLET-INF/classes/dynPortlet/dynPortletBean.java

Fur alle Variablen existiert jeweils eine set- undeine get-Methode. Der Zugriff auf die Variablenerfolgt immer indirekt uber diese Selektoren. DerVorteil dieser Vorgehensweise ist, dass die Datender jeweiligen Felder an dieser Stelle auf Kon-sistenz uberpruft (z.B. ist die Custno immer 3-stellig?) und vor der Ausgabe formatiert werdenkonnen. In unserem Beispiel werden die Werte nurgespeichert.


6.5.2 Controller

Der Controller agiert als Schaltzentrale zwischenden anderen Komponenten. Er erneuert bei Be-nutzereingaben sowohl die Ausgabe fur den Be-nutzer (View) als auch das Datenmodell (Mo-del). In unserem Beispiel fungiert die Java-KlassedynPortlet.java als Controller. Beim statischenPortlet hatte sie lediglich die Aufgabe, den Viewzu selektieren, wenn das Portlet angezeigt werden.

Die Anderungen im Vergleich zum statischen Portlet sind folgende:

• Es gibt nun 2 Ansichten fur das Portlet (Zeilen 9 und 10), die je nachAnzeigetyp selektiert werden.

• In Zeile 17 wird das Java Bean instanziiert, in das die Userid (LoginName des Benutzers) und die Custno aus der Datenbank geschriebenwird.

1 package dynPortlet;2

3 import org.apache.jetspeed.portlet .*;4 import org.apache.jetspeed.portlets .*;5 import java.io.*;6 import java.sql .*;7

8 public class dynPortlet extends AbstractPortlet {9 protected static final String jspNormalView = "/PORTLET -

INF/html/dynPortletView.jsp";10 protected static final String jspMaxView = "/PORTLET -

INF/html/dynPortletMaxView.jsp";11

12 public void service ( PortletRequest request ,PortletResponse response)

13 throws PortletException , IOException {14 String jsp = null;15

16 if( request.getMode () == Portlet.Mode.VIEW ) {17 dynPortletBean dPB = new dynPortletBean ();18

19 Integer custno = new Integer (0);20 PortletSession session = request.getSession ();21 User user = session.getUser ();22

23 PrintWriter writer = response.getWriter ();


24

25 response.getWriter ().println("Href=’" + url);26

27 try {28 ResultSet result;29 Connection con = DriverManager.getConnection("jdbc:

db2:WW" , "db2name" , "db2pass");30 Statement select = con.createStatement ();31 result = select.executeQuery("select dP.custno from

administrator.dynPortlet dP where dP.userid=’" +user.getUserID () + "’");

32

33 if ( result.next()) {34 custno = new Integer(result.getInt (1));35 }36 else {37 writer.println("Keinen Eintrag fur UserID gefunden.

");38 return;39 }40 }41 catch ( Exception e) {42 writer.println("Datenbankverbindung schlug fehl.");43 return;44 }45

46 PortletData pData = request.getData ();47

48 dPB.setUserid(user.getUserID ());49 dPB.setCustno(custno);50

51 request.setAttribute ( "dynPortletBean" , dPB );52

53 if( ( request.getWindow ()).isMaximized () == true ) {54 jsp = jspMaxView;55 }56 else {57 jsp = jspNormalView;58 }59 }60

61 (getPortletConfig ().getContext ()).include ( jsp , request ,response );

62 }63 }

Listing 6: PORTLET-INF/classes/dynPortlet/dynPortlet.java

Im try-catch-Block des Controllers wird die Information zur Ubergabe an

das Bean aus der Datenbank entnommen. An dieser Stelle konnte man sichuberlegen, ob die Datenbankabfrage innerhalb des Controllers oder inner-halb des Beans gemacht werden soll. Welche Moglichkeit sinnvoller ist, mussvon Fall zu Fall entschieden werden. Bei mehreren Beans und einer Daten-bank ist es sinnvoller die Verbindungsdaten zentral zu halten, sei dies nunim Controller, in einer Bean-Superklasse oder dem Session Objekt. Bei meh-reren Beans, die jeweils fur sich eine Verbindung zu einer unterschiedlichenDatenbank offnen kann eine dezentrale Speicherung der Verbindungsdatensinnvoller sein. Da wir hier lediglich mit einer Datenbank und einem Beanarbeiten haben wir uns fur die zentrale Speicherung entschieden.

6.5.3 View

Grundsatzlich wird ein View im MVC-Patterndazu verwendet, die Daten aus dem Model anzu-zeigen. Diese Aufgabe ubernehmen bei Portletsdie Java Server Pages. Die statische JSP Dateiwurde erweitert, um die Felder Userid undCustno mittels der Selektoren aus dem Bean zuholen (Zeilen 8 und 10).

1 <%@ page contentType="text/html" errorPage="" %>2

3 <jsp:useBean id="dynPortletBean" class="dynPortlet.dynPortletBean" scope="request" />

4

5 dynPortletView.jsp:6

7 8 myPortletBean.getUserid (): <%= myPortletBean.getUserid ()%>9 

10 myPortletBean.getCustno (): <%= myPortletBean.getCustno ()%>11 

Listing 7: PORTLET-INF/classes/dynPortlet/dynPortletView.jsp

Diese Sicht auf die Daten definiert die normale Ansicht auf das Portlet, wennes im Portalserver aufgerufen wird. Da die Java Klasse eine weitere Sicht vor-sieht (maximierte Sicht), wird entsprechend eine weitere JSP Datei angelegt,die die Daten fur diese Ansicht entsprechend aufbereitet. Da unsere Datenba-sis im Beispiel sehr klein ist, verzichten wir hier auf das Listing. Im folgendensind 3 Screenshots von moglichen verschiedenen Sichten auf die Datenbasiseines Versicherungsportfolio abgebildet, die jeweils nach einer Benutzeraktion


(Klick auf einen Link) eine andere Ansicht der Daten bieten.

Abbildung 16: 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.1des WebSphere Portalservers. Im Jahre 2002 wurde die Version 4.1 veroffentlicht,und wir wollen kurz auf die Unterschiede dieser beiden aufeinanderfolgendenReleases aufmerksam machen.10.

7.1 Merkmale von WPS 4.1

Ein Hauptmerkmal von WPS 4.1 ist der Versuch der Standardisierung. IBMarbeitet im Java Community Process mit anderen Firmen zusammen um denPortlet Container und die dazugehorende Portlet API zu standardisieren.Der Portlet Container ist das interne Portal Framework, das Host-Portletim Portalserver. Der Grund ist einfach: Eine Standardisierung ermoglichtdem Entwickler das Schreiben eines Portlets, welches dann auf verschiedenenPortalplattformen laufen kann.Die Portlet API in WPS 4.1 wurde an den Java Community Process geschicktund ist ein moglicher erster Schritt zur Portlet API Standardisierung.Weitere WPS 4.1 Features:

• Einverstandnis mit der J2EE Spezifikation

• Engere Integration mit dem Application Server.

• Erneuerte und verbesserte Portlet API:

10WebShpehere Portal Version 4.1 - Portlet Migration Guide, 2nd Edition


– Portlets erben von der Servlet Klasse.

– Portlets benutzen Dienste, die der Application Server zur Verfugungstellt.

– Neue Portal Funktionen:

∗ Portlet dynamic configurations

∗ Portlet page contributions

Durch die Unterstutzung neuer Funktionen in der API wurden Anderungeneingebracht, die die die Abwartskompatibilitat beeintrachtigen, und das Andernexistierender Portlets notwendig machen. Diese Anderungen sind meist mi-nimal, doch sie erfordern das erneute kompilieren und komprimieren jedesPortlets.

7.2 Unterschiede zwischen WPS 2.1 und WPS 4.1

Zusatzliche Designanderungen das existierende Portlets beeinflussen:

• Portlet Interface wurde mit der Abstract Portlet Klasse in WPS 4.1ersetzt. Portlets konnen direkt von der Portlet Klasse erben. Jedoch istes zu empfehlen das Portlets Hilfsklassen benutzen, wie MVCPortlet

oder PortletAdapter, da diese Methoden und Signaturen dieser Klas-sen entlang den Portalversionen beibehalten wurden.

• Portlet Messaging wurde erweitert. Portlets konnen jetzt Nachrichtenzu anderen Portlet Anwendungen senden, indem man dieDefautlPortletMessage Klasse benutzt. Das Nachrichten sendendePortlet und das Nachrichten empfangende Portlet mussen auf der glei-chen Portlalseite sein.

• Portlets konnen nur Werte im PortletData Objekt speichern, wenn derPortlet im Edit Modus ist. Vorher war diese Funktion im Portlet ViewModus moglich und wahrend allen Portlet Event Handlings. Falls einPortlet versucht Werte zu aktualisieren, wenn es nicht im Edit Modusist, dann wird eine Exception geworfen.

• Erhaltung von JAAS (Java Authentication and Authorization Service)Benutzer wurde geandert.


• Eine Portlet Anwendung ist definiert in zwei XML Dokumenten. Derportlet.xml bleibt das Dokument um Portlet Anwendungenspezifi-sche Informationen zu speichern. Das web.xml Dokument definiert diePortlet Anwendung Klassen und initialisiert Daten zum Portal und demApplikation Server.

• Die SaxPortlet Klasse wurde entfernt und wird nicht mehr unterstutzt.


Anderung der Pakete:

• Portlets werden nun in WAR (WebARchiv) Dateien zusammengefasst.Als Minimum muss man die Portlets neu kompilieren und wieder neupacken.

• Die Verzeichnisstruktur in einer Portlet Anwendung WAR Datei stimmtmit der Verzeichnisstruktur einer J2EE Web Anwendung uberein. Ge-nauer gesagt, gechutzte Ressourcen, Java Klassen, JAR Dateien, usw.werden in WEB-INF Verzeichnis gespeichert. In vorherigen Versionenwurden Portlet Assets in der PORTLET-INF Verzeichnis der PAR Dateigespeichert.

• MVCPortlet oder AbstractPortlet bleiben unverandert.

• JSP: Vorherige Versionen benutzen PortletRequest, PortletResponseund andere Objekte um Informationen und Werte zu erhalten um inder JSP zu benutzen. Einige Methoden haben sich geandert. Um dieseAnderungen des Portlets zu isolieren, sollte man anstatt die request

oder response Objekte in den JSP aufzurufen, diese in dem Portletausrufen und die Information zum JSP weiterleiten in einem requestbean. So wird die Anderungen der JSPs fur WPS 4.1 minimiert.

• Benutze static class Variablen nur fur endgultige, konstante Werte.

• Implementiere event handlers direkt in die Portlet Klasse.

Durch die Neuerungen von WPS 4.1 mussen Portlets von WPS 2.1 in WPS4.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 andern

8 FAZIT 39

8 Fazit

Der IBM WebSphere Portalserver 2.1 sollte unserer Meinung nach uberalldort 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 striktdurchgehalten, dass uberall dort, wo das Design in der Hintergrund tritt undFunktionalitat im Vordergrund steht der Portalserver zur Anwendung kom-men konnte.Die vorgegebene Trennung von Ausgabe und Programmlogik gibt Entwick-lerteams eine Aufgabentrennung vor, die bei anderen Technologien erst erar-beitet werden muss.

Die Installation des IBM WebSphere Portalserver 2.1 war nicht ausgereiftund hinterließ bei uns den Eindruck eines unfertigen Produkts. Wir wurdenauf jeden Fall empfehlen, sich sofort mit dem WebSphere Portalserver 4.1 zubeschaftigen, da ein Upgrade von WPS 2.1 auf WPS 4.1 nicht ohne Migrationmoglich ist. Zudem ist ein potenter Rechner mit viel Hauptspeicher (minde-stens 1 GB) unabdingbar, um in einem Entwicklerumfeld mit dem WPS 2.1zu arbeiten. Es war uns leider nicht moglich, das Verhalten des WPS unterProduktionsbedigungen zu testen.

LITERATUR i

Literatur

[1] WebSphere Portal Enable Solution Version 2.1.[http://www.ibm.com/software/webservers/portal/library/InfoCenter/wpf/wpf-enable.pdf],Verfugbarkeitsdatum: 13.02.2003

[2] Stephan Hesmer, Peter Fischer, Ted Buckner, Perva-sive Computing Development (2002): Portlet Develop-ment Guide. Introduction to the Portlet API. Edition 1.1.[www.ibm.com/software/webservers/portal/library/PortletDevelopmentGuide.doc],Verfugbarkeitsdatum: 13.02.2003

[3] David B. Lection (2002): WebShpehere Portal Ver-sion 4.1 - Portlet Migration Guide, 2nd Edition.[www.ibm.com/software/webservers/portal/library/V41PortletMigrationGuide.pdf],Verfugbarkeitsdatum: 19.02.2003

[4] Sun Microsystems (2002): Java 2 SDK, Standard Edition Documentati-on. [http://java.sun.com/j2se/1.4/docs],Verfugbarkeitsdatum: 19.02.2003

[5] Sun Microsystems (2002): Java BluePrints: Model-View-Controller.[http://java.sun.com/blueprints/patterns/MVC-detailed.html],Verfugbarkeitsdatum: 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 Oberflache . . . . . 3

4 Zusammenspiel anderer Komponenten mit IBM WPS Portal-server 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



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

Eberhard-Karls-Universit˜at Tubingen˜ · Abbildung 4: Zusammenspiel anderer Komponenten mit IBM...

Documents

Transcript of Eberhard-Karls-Universit˜at Tubingen˜ · Abbildung 4: Zusammenspiel anderer Komponenten mit IBM...