Hawlitzek GmbH/ Veröffentlichungen/ Servlets in WebSphere/ Servlet-Debugging/ Deployment in WebSphere/

Hawlitzek IT-Consulting GmbH ©Foto Kirsten Literski-Hawlitzek

Deployment in WebSphere

Dieser Artikel ist im JavaMagazin 7/01 erschienen. Vielen Dank an den Software & Support Verlag für die Genehmigung zur Veröffentlichung auf dieser Webseite!

An den Start

Serveranwendungen in VisualAge for Java, Teil 3: Deployment von Servlets und JSPs im WebSphere Application Server

Nachdem wir im ersten Teil in VisualAge eine Servlet- und JSP-Anwendung entwickelt und im zweiten diese im WebSphere Test Environment getestet haben, ist es nun an der Zeit, sie im WebSphere Application Server zu deployen. Wir werden dabei die Erstellung und Konfiguration einer Web-Applikation in WebSphere 3.5 vorstellen.

IBMs WebSphere Application Server steht in seiner neuesten, J2EE-kompatiblen Version 4.0 bislang leider nur auf der Host-Plattform zur Verfügung, so dass wir die vom Deployment noch etwas anders zu behandelnde Version 3.5.x verwenden. In der aktuellen Windows- und UNIX-Variante 3.5.3 stellt der Applikationsserver aber trotzdem die aktuellen APIs für Servlets (2.2) und JavaServer Pages (1.1) zur Verfügung. Für unsere Zwecke reicht die kleinste Ausbaustufe, die Standard Edition. Die größeren Serverversionen, Advanced und Enterprise, bringen zusätzlich noch EJB- und CORBA-Unterstützung mit, besitzen aber die gleiche Servlet Engine.

Export und Packaging

Zunächst müssen wir unsere Anwendung aus VisualAge exportieren. Sie besteht aus einem Java-Servlet, mehreren Klassen, einem statischen HTML-Formular und zwei JSPs. Für Enterprise JavaBeans bietet VisualAge eine gute Exportfunktion an und auch WebSphere Studio bietet ein Deployment Werkzeug; aber für Servlet-basierte Anwendungen lässt uns VisualAge hier etwas im Stich. Man kann zwar das Projekt als Ganzes exportieren, jedoch legt VisualAge entweder nur ein jar-File mit allen Klassen und Ressourcen an, das man bei Deployment wieder mühsam zerlegen muss, oder packt alles in ein Verzeichnis ohne die übliche Trennung in ein Verzeichnis WEB-INF für Klassen und Konfiguration, sowie andere Verzeichnisse für JSPs und weitere Ressourcen. Und auch JSPs und Dateien, die man für den Test im Document Root <IBMVJava>\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\web platziert hat, übersieht man so leicht.
Für die Suche nach referenzierten Klassen, die von unserem Servlet benötigt werden, gibt es beim Export-Wizard eine Funktion "Select referenced classes". Bei der Benutzung ist jedoch Vorsicht angebracht, denn erstens findet Sie auch alle benutzten Klassen, die ohnehin im WebSphere Application Server enthalten sind (Projekte "Servlet API Classes" und "IBM WebSphere Test Enviroment") und zweitens löst sie nur direkte Referenzen im Code auf (import, Vererbung etc.), aber keine dynamisch geladenen Klassen (Class.forName).
Für den Export der Servlet-Konfigrationsdaten (init-Parameter, symbolische Namen etc.) gibt es leider überhaupt keine Möglichkeit, so dass man diese Informationen nur manuell an den Deployer weitergeben kann. Hier sollte IBM in der nächsten VisualAge-Version unbedingt nachbessern.

Web-Applikationen

Der WebSphere Applikationsserver bietet für die Verwaltung von einzelnen Projekten so genannte Web-Applikationen an. Jede wird aus Clientsicht über einen eigenen Teilpfad in der URL oder sogar einen eigenen virtuellen Hostnamen angesprochen. Intern besitzt jede Web-Applikationen eine eigene Unterverzeichnisstruktur, spezifische CLASSPATH-Werte, sowie Einstellungen für Welcome- und Fehlerseiten, Tag-Libraries und vieles mehr. Später werden wir für unsere Anwendung eine eigene Web-Applikation anlegen, aber zunächst deployen wir unser Servlet in die Default-Applikation.

Deployment

Angenommen wir haben die Klassen unseres Beispiels in Java-Archiv gepackt. Dann kopieren wir dieses in das Code-Verzeichnis der Default-Applikation, z. B. <WebSphere>\appserver\hosts\default_host\default_app\servlets. Sie können das Jar-File hier entpacken oder in der Konfiguration in der Administrationsoberfläche eintragen. Anschließend müssen Sie das Servlet registrieren. Starten Sie dazu die Administrationskonsole von WebSphere. Wählen Sie die Default-Applikation im Default-Server und starten Sie den Create-Servlet-Wizard. Wählen Sie als Typ "User-Defined Servlet". Auf der nächsten Seite (Abbildung 1) können Sie nun einen symbolischen Namen und einen Pfad vergeben, so dass Sie unser einfaches Servlet zukünftig statt über http://www.hawlitzek.de/servlet/de.hawlitzek.jm.test.SimpleServlet beispielsweise mit der URL http://www.hawlitzek.de/examples/SimpleService ansprechen könnten. Sie können auch mehrere Pfade angeben. Wichtig ist, dass Sie hier den vollqualifizierten Klassennamen korrekt angeben, damit der Server das Servlet auch laden kann. Alle Stellen, an denen Ihr Servlet aus der Anwendung heraus aufgerufen wird, müssen das Servlet natürlich auch unter diesen Namen ansprechen, wobei Sie natürlich auch relative Pfadangaben verwenden dürfen. Unter Umständen müssen Sie also HTML-Seiten, JavaServer Pages und andere Servlets deshalb ändern.


Abbildung 1: Konfiguration eines Servlets

Schließlich können Sie im letzten Schritt Init-Parameter angeben und definieren, ob das Servlet gleich beim Start der Servlet Engine geladen wird oder erst bei der ersten Nutzung. Sind alle Einstellungen korrekt, sehen Sie das Servlet nun unterhalb der Web-Applikation.
  Im nächsten Schritt müssen Sie nun die Web-Ressourcen kopieren. Sie können entweder nur die JSP-Dateien auf <WebSphere>\appserver\hosts\default_host\default_app\web kopieren oder sämtliche Dateien, also auch statische HTML-Seiten, Bilder und so weiter. Letzteres Verfahren ist für das Deployment einfacher, setzt aber voraus, dass statt dem Webserver die Servlet Engine die Dateien zum Browser liefert. Dazu muss der "File Serving Enabler" als Dienst der Servlet Engine aktiviert sein.
Sie können jetzt den Server starten und die Anwendung im Browser aufrufen.

Definition einer Web-Applikation

Bislang haben wir die Default-Applikation benutzt. Bei einer richtigen Anwendung sollte man aber zur besseren Trennung und leichteren Verwaltung eigene Web-Applikationen pro Projekt anlegen.

Abbildung 2: WebSphere Administrationskonsole

Die oberste Gliederungsstufe in WebSphere ist der Server (siehe Abbildung 2). Dieser kann nun Servlet Engines oder EJB-Container enthalten. Hat man nun eine Servlet Engine in einem Server ausgewählt oder neu angelegt, kann man darin eine Web-Applikation anlegen. Auf der ersten Seite des Wizards können Sie einen Namen vergeben, einen zugehörigen virtuellen Host auswählen und einen relativen Pfad für alle zugehörigen Inhalte definieren (Abbildung 3). Auf der Seite "Advanced" legen Sie das Dokument-Root-Verzeichnis für die Web-Ressourcen fest. Hier können Sie auch Einträge in den CLASSPATH der Web-Applikation definieren. Weitere Einstellungsmöglichkeiten sind Fehler- und Welcome-Seiten, Sitzungs-Timeouts, Tag-Libraries und MIME-Typzuordnungen (Abbildung 4).


Abbildung 3: Erzeugung einer Web-Applikation


Abbildung 4: Konfiguration einer Web-Applikation

Die Web-Applikation ist von sich aus jedoch noch nicht als JSP-Compiler oder File-Server konfiguriert. Sie können zu diesem Zweck WebSphere-Standard-Servlets hinzufügen. Das erledigen Sie ebenfalls mit dem "Create Servlet"-Wizard (Abbildung 5). Wählen Sie jedoch nicht als Typ "User Defined Servlet", sondern zum Beispiel "File-Serving Servlet", wenn Sie Resourcen wie HTML-Dateien via Servlet Engine laden möchten oder "Enable Serving Servlets by Classname", wenn Sie die Servlets auch ohne den symbolischen Namen ansprechen möchten. Zur Benutzung von JavaServer Pages können Sie hier einen JSP-Enabler installieren, wobei Sie die Auswahl zwischen den API-Versionen 1.1, 1.0 oder 0.91 haben.


Abbildung 5: Auswahl eines Servlet-Typs

Die Web-Applikationen sind zur Administration sehr praktisch, allerdings wäre es schön, wenn man diese zur Entwicklungszeit schon benutzen könnte, damit man beim Deplyoment nicht alle URLs umstellen muss. VisualAge bietet ebenfalls die Nutzung von Web-Appliaktionen an, aber leider nicht die grafischen Administrationsmöglichkeiten von WebSphere. Im letzten Heft haben wir jedoch kurz beschrieben, wie Sie die notwendigen Einstellungen zur Einrichtung in der Datei default.servlet_engine vornehmen. Für jede Web-Applikation müssen Sie dann eine eigene Konfigurationsdatei für die Servlets und Ressourcen anlegen. Der Aufbau ist in der Online-Hilfe etwas knapp beschrieben und es ist Vorsicht geboten, denn eine falsch konfigurierte Servlet Engine verhindert den Start der kompletten Testumgebung. Die Nutzung ist also erfahrenen Entwicklern vorbehalten.

Fazit

Mit VisualAge und WebSphere steht eine ausgereifte Entwicklungs- und Laufzeitumgebung für Servlet- und JSP-Anwendungen zur Verfügung. Für fast alle Tätigkeiten stehen Wizards zur Verfügung. Das einzige Manko ist das Packaging beim Export von VisualAge zur Vorbereitung des Deployments.

Literatur

 

[FH1] Servlets in VisualAge und WebSphere - Teil 1, Florian Hawlitzek, Java Magazin 5/01

 

[FH2] Servlets in VisualAge und WebSphere - Teil 2, Florian Hawlitzek, Java Magazin 6/01

 

© 2006 Hawlitzek IT-Consulting GmbH,
Marketing&Design Kirsten Literski-Hawlitzek

Seitenanfang

Hawlitzek GmbH
Die Gründer
Dienstleistungen
Java Downloads
Vorträge
Veröffentlichungen
Kontakt
International
Sitemap