Version 1.2 - Wirtschaftsuniversität Wien

Transcription

Version 1.2
Danksagung
Der meiste Dank im Rahmen dieser Arbeit gilt ao. Univ-Prof. Dr. Rony Flatscher.
Zuerst wurde durch das von ihm abgehaltene WebEngineering-Proseminar das
Interesse für diese Thematik bei mir geweckt. Durch dieses Interesse entstand bei
mir der Wunsch zu dem vorliegenden Thema eine Diplomarbeit zu verfassen.
Da es an der WU Wien keine Selbstverständlichkeit ist die Möglichkeit zu haben, zu
einem eigenen Thema zu schreiben, gebührt Prof. Flatscher auch in dieser Hinsicht
Dank. Schlussendlich sei Prof. Flatscher auch für seine aktive Unterstützung
während der Erstellung dieser Arbeit gedankt.
An dieser Stelle sollen auch die Herren Georg Haschek und Rupert Mandl von IBM
Österreich
erwähnt
sein,
die
mir
äusserst
unbürokratisch
und
sehr
entgegenkommend, den Zugang zu der notwendigen Software verschafft haben.
Ebenfalls Dank hat meine Verlobte verdient, die mich viele Stunden, Tage und
Nächte mit dem Computer teilen musste.
Zu guter Letzt möchte ich mich auch bei meiner Familie bedanken, die mir das
Studium ermöglicht hat und mich beständig unterstützt.
Inhaltsverzeichnis
1
EINLEITUNG
18
1.1
Problemstellung und Ziele
20
1.2
Aufbau der Arbeit
21
2
GRUNDLAGEN ZUM THEMA APPLICATION SERVER
22
2.1
Application Server
22
2.2
Komponenten eines Application Servers
27
2.3
Der Markt der Application Server
29
3
IBM WEBSPHERE APPLICATION SERVER
3.1
Aufbau der WebSphere Software Plattform
3.1.1
Foundation
33
33
35
3.1.1.1
WebSphere Application Server Standard Edition
36
3.1.1.2
WebSphere Application Server Advanced Edition
37
3.1.1.3
WebSphere Application Server Enterprise Edition
39
3.1.1.4
Neue Funktionen in Version 4.0
40
3.1.2
Foundation Extensions
41
3.1.2.1
Development
42
3.1.2.2
Presentation
42
3.1.2.3
Deployment
43
3.1.3
Application Accelerators
43
3.1.4
Customer and Partner Applications
44
3.2
Websphere Application Server Architektur
3.2.1
J2EE Überblick
45
46
3.2.1.1
Definition
46
3.2.1.2
Die J2EE-Plattform
47
3.2.2
Bean Scripting Framework (BSF)
49
3.2.3
WebSphere Administrationsmodell
53
3.2.4
Administrationstools
54
3.2.5
Websphere Application Server
55
3.2.5.1
Web-Container
57
3.2.5.2
Enterprise Java Beans - Container
57
3.2.6
XML
59
3.2.6.1
XML Grundlagen
59
3.2.6.2
XSL
60
3.2.6.3
XSLT
62
3.2.6.4
Weitere XML-Technologien
63
3.2.6.5
WebSphere und XML
64
3.2.7
WebServices
66
3.2.7.1
Definition
66
3.2.7.2
Architektur
66
3.2.7.3
WebServices Implementierung
67
3.2.8
Servlet
69
3.2.8.1
Überblick
69
3.2.8.2
Der Servlet-Lebenszyklus
70
3.2.9
JSP
72
3.2.10
JavaBean
75
3.2.11
Enterprise Java Bean
76
3.2.11.1
Rollen
77
3.2.11.2
Arten von Beans
78
3.2.11.3
EJB-Architektur
79
3.2.11.4
Transaktionen
81
3.2.11.5
Datenbankzugriffe
81
3.2.11.6
Sicherheit/Authentifizierung
81
3.2.12
3.3
J2EE - Applikationen
Systemvoraussetzungen
82
86
4
INSTALLATION DES WEBSPHERE-SERVERS
90
4.1
Voraussetzungen und wichtige Hinweise
92
4.2
Anlegen eines Windows 2000 Benutzers
97
4.3
Benutzerrechte für den Benutzer vergeben
101
4.4
Dienste starten bzw. stoppen
104
4.5
Installationsschritte
105
4.5.1
IBM HTTP Server
105
4.5.1.1
Vorarbeiten
105
4.5.1.2
Installation
105
4.5.1.3
Konfiguration
108
4.5.1.4
Verifizierung
109
4.5.2
IBM DB2 Universal Database Enterprise Edition 7.2
111
4.5.2.1
Vorarbeiten
111
4.5.2.2
Installation
111
4.5.2.3
Verifizierung
114
4.5.2.4
Konfiguration
116
4.5.3
IBM DB2 Database Client
4.5.3.1
4.5.4
Installation
IBM WebSphere Application Server
123
123
125
4.5.4.1
Vorarbeiten
125
4.5.4.2
Installation
125
4.5.4.3
Verifizierung
129
4.5.5
IBM Visual Age for Java 4.0 Entry Edition
138
4.5.6
IBM WebSphere Studio 4.0 Entry Edition
140
4.5.7
XML-Tools
141
4.5.7.1
XEENA
141
4.5.7.2
XML-Viewer
143
4.5.7.3
XSLerator
143
4.5.7.4
LotusXSL
143
5
BEISPIELE
144
5.1
Installation und Konfiguration
144
5.2
Beschreibung
158
5.2.1
YourCo
160
5.2.2
Bean Scripting
163
5.2.3
StockQuote
163
5.2.4
XML
164
5.2.5
HelloEJB
164
5.2.6
Increment EJB
164
5.2.7
Account EJB und Transfer EJB
165
5.2.8
Application Client
165
5.2.9
Pet Store
166
5.3
Verpacken und Installieren einer Webapplikation an Hand eines
Beispieles
167
5.3.1
Projekterstellung
168
5.3.2
Verpacken der Applikation
174
5.3.3
Installation
175
5.3.4
Test der Applikation
177
6
ZUSAMMENFASSUNG UND AUSBLICK
179
7
LITERATURVERZEICHNIS
183
8
VERZEICHNIS DER SONSTIGEN QUELLEN UND HILFSMITTEL
187
Abbildungsverzeichnis
Abbildung 1: Problemkreis........................................................................................ 20
Abbildung 2: Drei-Schichten-Modell ......................................................................... 23
Abbildung 3: Die 4 Bereiche einer Application Server Produktfamilie
[nach WUVO01]................................................................................... 26
Abbildung 4: Aufbau eines java-basierten Application Server .................................. 27
Abbildung 5: Application Server Markt...................................................................... 29
Abbildung 6: Marktanteilsverteilung Application Server 2001 [nach SPCW01]......... 31
Abbildung 7: Markt Segmentierung [nach GiZe01] ................................................... 31
Abbildung 8: Plattform-Aufbau [nach WSPO01] ....................................................... 33
Abbildung 9: WebSphere Plattform - Produktübersicht [angelehnt an WSPO01] .... 34
Abbildung 10: J2EE-Plattform [nach EnClu01,74] .................................................... 47
Abbildung 11: BSF-Architektur (siehe KaPe01)........................................................ 50
Abbildung 12: Beispiel-Sourcecode für BSF............................................................. 51
Abbildung 13: WebSphere Administrationsmodell [nach EnClu01] .......................... 53
Abbildung 14: Administrationsdienste [nach ArIy01]................................................. 54
Abbildung 15: Application Server Aufbau ................................................................ 55
Abbildung 16: DTD-Beispiel...................................................................................... 60
Abbildung 17: XML-Beispiel [nach EnCh01] ............................................................. 60
Abbildung 18: XSLT-Beispiel [nach EnCh01] ........................................................... 61
Abbildung 19: Beispiel für XSL-Konvertierung [nach EnCh01] ................................. 63
Abbildung 20: Beispiel für Namespaces ................................................................... 64
Abbildung 21: Web Service Komponenten und Vorgangsweise [nach EnClu01] ..... 66
Abbildung 22: Client-Servlet-Kommunikation [nach ArIy01] ..................................... 69
Abbildung 23: Client-Servlet Kommunikation............................................................ 70
Abbildung 24: Servlet Lebenszyklus [nach ArIy01]................................................... 71
Abbildung 25: JSP-Einsatz ....................................................................................... 73
Abbildung 26: JSP-Lebenszyklus [nach ArIy01] ....................................................... 74
Abbildung 27: Java-Source-Code-File-Generierung [nach ArIy01]........................... 74
Abbildung 28: EJB Funktionsprinzip [angelehnt an HrNo01] .................................... 76
Abbildung 29: Session Beans vs. Entity Beans [angelehnt an HrNo01] ................... 79
Abbildung 30: Komponenten der EJB-Architektur .................................................... 80
Abbildung 31: Deployment-Descriptor [nach EnCl201]............................................. 83
Abbildung 32: Aufbau einer J2EE Applikation .......................................................... 83
Abbildung 33: J2EE Rollen im Entwicklungsprozess................................................ 85
Abbildung 34: Beispiel für Port-Überprüfung ............................................................ 95
Abbildung 35: Control Panel ..................................................................................... 97
Abbildung 36: Users and Passwords........................................................................ 97
Abbildung 37: Einen neuen Benutzer hinzufügen..................................................... 98
Abbildung 38: Passwort festlegen ............................................................................ 98
Abbildung 39: Gruppenzugehörigkeit festlegen ........................................................ 98
Abbildung 40: „Advanced“-Dialog in „Users and Passwords“ ................................... 99
Abbildung 41: "Local Users and Groups"-Dialog ...................................................... 99
Abbildung 42: „Benutzer Eigenschaften“-Dialog ......................................................100
Abbildung 43: Local Security Settings .....................................................................101
Abbildung 44: Local Security Policy Setting.............................................................102
Abbildung 45: Benutzer auswählen .........................................................................102
Abbildung 46: Abschliessen der Local Security Policy Settings...............................103
Abbildung 47: Übersicht über die Local Security Settings .......................................103
Abbildung 48: Starten eines Dienstes......................................................................104
Abbildung 49: Stoppen eines Dienstes ....................................................................104
Abbildung 50: Sprachauswahldialog........................................................................105
Abbildung 51: Installationspfadangabe ....................................................................106
Abbildung 52: Setupart auswählen ..........................................................................106
Abbildung 53: Benutzerangaben für den Start des Services ...................................107
Abbildung 54: Anlegen eines Administrationsbenutzers..........................................108
Abbildung 55: Ausschnitt aus der httpd.conf............................................................109
Abbildung 56: Ausschnitt aus den Services.............................................................109
Abbildung 57: Startseite des IBM HTTP-Servers.....................................................110
Abbildung 58: DB2 Installationsdialog .....................................................................111
Abbildung 59: Auswahl der DB2 Enterprise Extended Edition.................................112
Abbildung 60: Auswahl der Installationsart ..............................................................112
Abbildung 61: Auswahl des Installationspfades.......................................................112
Abbildung 62: Benutzerangaben für die Steuerzentrale ..........................................113
Abbildung 63: OLAP Starter Kit ...............................................................................113
Abbildung 64: Überprüfen der Datenbank-Konfiguration 1 ......................................115
Abbildung 65: Überprüfen der Datenbank-Konfiguration 2 ......................................115
Abbildung 66: Java-Version aktualisieren................................................................116
Abbildung 67: Kommunikationsmodus einstellen ....................................................117
Abbildung 68: Erstellen der WAS Administrationsdatenbank ..................................118
Abbildung 69: Datenbank-Überprüfung ...................................................................118
Abbildung 70: DB2 Knoten erstellen........................................................................119
Abbildung 71: Aliasnamen eintragen .......................................................................119
Abbildung 72: Überprüfung des Aliasnamen ...........................................................119
Abbildung 73: Verbindungsaufbau zur Administrationsdatenbank...........................120
Abbildung 74: Verbindungsaufbau zur Administrationsdatenbank...........................121
Abbildung 75: DB2 Administrationsclient installieren...............................................123
Abbildung 76: Installationsart auswählen ................................................................124
Abbildung 77: Installationspfad auswählen..............................................................124
Abbildung 78: Auswahl der Installations Optionen...................................................125
Abbildung 79: Komponenten-Auswahl.....................................................................126
Abbildung 80: Plugin-Auswahl .................................................................................126
Abbildung 81: Benutzerangaben für das IBM HTTP Server Service .......................126
Abbildung 82: Installationspfad auswählen..............................................................127
Abbildung 83: Datenbankoptionen angeben............................................................127
Abbildung 84: Installationsoptionen .........................................................................128
Abbildung 85: Ausschnitt aus den Services.............................................................129
Abbildung 86: admin.config Einstellungen ...............................................................130
Abbildung 87: Starten des Default-Servers..............................................................132
Abbildung 88: Überprüfung des Startvorganges......................................................133
Abbildung 90: Neugenerierung des Plugins.............................................................136
Abbildung 91 : Plugin-cfg.xml ..................................................................................137
Abbildung 93: Installation VisualAge ......................................................................138
Abbildung 94: Lizenzabkommen..............................................................................138
Abbildung 95: Installationsumfang wählen ..............................................................139
Abbildung 96: Installation starten.............................................................................139
Abbildung 97: Auswahl der zu installierenden Komponenten ..................................140
Abbildung 98: Auswahl der Java Umgebung ...........................................................141
Abbildung 99: Java-Installationspfad auswählen .....................................................142
Abbildung 100: Proxy-Host ......................................................................................142
Abbildung 101: Umgebungsvariable erstellen .........................................................143
Abbildung 102: Datenbank-Einstellungen für die Beispiele .....................................145
Abbildung 103: Anlegen der Samples-Datenbank ...................................................146
Abbildung 104: Starten des Default Servers............................................................146
Abbildung 105: Kontrolle der Installation .................................................................147
Abbildung 106: Einrichten des Onlineshops ............................................................148
Abbildung 107: Anpassen der Applikation ...............................................................149
Abbildung 108: Anpassen der Umgebungseinträge ................................................149
Abbildung 109: Datenbank anlegen.........................................................................150
Abbildung 110: Datenquelle anlegen.......................................................................151
Abbildung 111: Eigenschaften der Datenquelle.......................................................152
Abbildung 112: Eigenschaften der Mail-Session .....................................................153
Abbildung 113: Modulsichtbarkeit ändern................................................................154
Abbildung 114: Enterprise-Anwendung installieren .................................................154
Abbildung 115: Anwendung installieren...................................................................155
Abbildung 116: Verteilung der Applikation ...............................................................155
Abbildung 117: Bestätigung der Installation............................................................155
Abbildung 118: Starten der Anwendung ..................................................................156
Abbildung 119: Verifizierung der Installation............................................................157
Abbildung 120: Starten der J2EE Client Applikation................................................165
Abbildung 121: Neues Projekt erstellen...................................................................168
Abbildung 122: Publikationsstufe auswählen...........................................................169
Abbildung 123: Ordner anlegen...............................................................................169
Abbildung 124: VisualAge for Java Optionenen ......................................................170
Abbildung 125: Remote Access to Tool API starten ................................................170
Abbildung 126: Servlet-Mapping..............................................................................171
Abbildung 127: Deskriptordatei erstellen .................................................................174
Abbildung 128: Enterprise Anwendung installieren .................................................175
Abbildung 129: Installation des WebModuls ............................................................176
Abbildung 130: Bestätigung der Installation.............................................................177
Tabellenverzeichnis
Tabelle 1: Marktanteil Application Server [nach GiZe01] .......................................... 30
Tabelle 2: Funktionsvergleich [nach EnClu01].......................................................... 37
Tabelle 3: BSF Zugriffsarten..................................................................................... 50
Tabelle 4: Von BSF unterstützte Sprachen............................................................... 52
Tabelle 5: Systemanforderungen „Application Server Standard Edition 3.5“
(Stand: Ende 2001) ................................................................................. 86
Tabelle 6: Systemanforderungen „Application Server Advanced Edition 4.0“
(Stand: Ende 2001) ................................................................................. 87
Tabelle 7: Systemanforderungen „Application Server Enterprise Edition 3.6“
(Stand: Ende 2001) ................................................................................. 88
Tabelle 8: Systemanforderungen „IBM HTTP Server“ (Stand: Ende 2001) .............. 88
Tabelle 9: Betriebssystemunterstützung für WebSphere Produkte
(Stand: Ende 2001) ................................................................................. 89
Tabelle 10: Übersicht über die installierten Produkte ............................................... 90
Tabelle 11: Hardwareanforderungen ........................................................................ 92
Tabelle 12: Softwareanforderungen ......................................................................... 92
Tabelle 13: Installationspfade ................................................................................... 93
Tabelle 14: Notwendige Benutzer............................................................................. 93
Tabelle 15: Weitere wichtige Namen ........................................................................ 94
Tabelle 16: Port-Belegungen .................................................................................... 95
Tabelle 17: Auflistung der installierten Beispiele .....................................................158
Tabelle 18: Inhalt der installierten Beispiele ............................................................159
Tabelle 19: Beschreibung der Funktionen des YourCo Beispieles ..........................163
Tabelle 20: Funktionen des "Pet Store" ...................................................................166
Abkürzungsverzeichnis
Begriff/Abkürzung Definition
Apache
Vereinigung,
die
Open-Source-Projekte
betreut.
Eine
gebräuchliche Abkürzung für den HTTP-Server der Apache
Organisation.
API
„Application Programming Interface“.
Deutsch: Programmier- und Anwendungsschnittstelle.
Application
Server für Anwendungsprogramme (Applications). Damit kann ein
Server
Server im LAN gemeint sein, der (statt reinen File-ServerDiensten) von vielen Clients benutzte Anwendungen (z.B.
Groupware) bereithält. Alternativ kann er auch als
Transaktionsserver oder als Middleware in einer Three-TierArchitektur (Drei-Schichten-Modell) dienen.
Der Begriff umfasst auch einen Web Application Server für WebAnwendungen oder Application Service Providing, der für eine
Internet- oder Intranet-Anbindung dynamisch HTML-Seiten
erzeugt und die Anwendungslogik/Geschäftslogik zwischen den
Web-Browsern und (meistens) einer Datenbank ausführt. Übliche
Schnittstellen bzw. Programmierstandards sind CGI, MS-ASP,
PHP, JSP, Servlet und CFML.
Als Programmier-Framework wird J2EE zunehmend beliebter.
Große Systeme beinhalten auch Transaktions-Management,
Sicherheitsmechanismen,
Load
Balancing
und
Failover-
Mechanismen. Beispiele für bekannte komplette Web-ApplicationServer-Systeme: BEA WebLogic, ColdFusion , IBM WebSphere,
Inprise, Oracle Application Server und SilverStream.
Im Rahmen dieser Arbeit wird unter Application Server ein Web
Application Server verstanden.
ASP (Microsoft)
„Active Server Pages“.
Microsofts Konzept für Web-Server-seitiges Skripting, einfache
Einbindung
eigener
Datenbankanbindung.
B2B
„Business to Business”.
Server-Applikationen
und
BMP
„Bean Managed Persistence”.
CFML
„ColdFusion Markup Language“.
Konkurriert mit ASP, JSP und PHP.
CGI
„Common Gateway Interface“.
Programmierschnittstelle auf Web-Servern. Parameter vom Client
z.B. aus HTML-Formularen können über Umgebungsvariablen
oder über das Stdin-Interface an ein Programm oder Skript auf
dem Server übergeben werden, welches dann auf dem Server
ausgeführt wird.
CMP
„Container Managed Persistence”.
CRM
„Customer Relationship Management“ z.B.: Clarify, SAP, Siebel,
etc.
CORBA
„Common Object Request Broker Architecture“
CORBA ist eine Spezifikation, die die Definition der Schnittstellen
in verteilten Systemen sowie die Kommunikation zwischen diesen
Schnittstellen ermöglicht. Damit ist CORBA der Standard, der die
Kommunikation zwischen Objekten und Programmen regelt.
CORBA ist systemunabhängig und auch nicht an eine bestimmte
Programmiersprache gebunden.
DOM
„Document Object Model“.
DOM ist ein Objektmodell, daß die in einem Dokument
enthaltenen Elemente in einer Baumstruktur als Objekte darstellt.
Über diese Objekte ist der Zugriff auf die Elemente möglich.
DTD
„Document Type Definition“.
Jedes dem SGML-Standard entsprechende Dokument gehört
einem bestimmtem Typ an. Ein Dokumenttyp definiert eine
eindeutige hierarchische Struktur und einen festgelegten Satz an
zur Verfügung stehenden Tags. Die Deklaration von Struktur und
Tags wird in der DTD vorgenommen. Mit der DTD wird also die
Syntax und Semantik der Auszeichnungssprache für diesen
Dokumenttyp festgelegt. Dadurch entfällt die Notwendigkeit, für
jede
neue
Auszeichnungssprache
schreiben zu müssen.
einen
neuen
Interpreter
EAI
„Enterprise Application Integration“.
Middleware z.B. zur Kopplung von E-Commerce-Software mit
ERP, SCM und CRM.
EIS
„Enterprise Information System“.
EJB
„Enterprise JavaBeans“.
Teil von J2EE. In Java programmierte Komponenten, wie auch
JavaBeans. Aber anders als JavaBeans benötigen EJBs einen
EJB-Server und sind besonders für grosse (z.B. per TransaktionsServer koordinierte) verteilte Enterprise-Anwendungen geeignet.
EJB Extension
Die Enterprise JavaBeans Specification 1.1, herausgegeben von
Sun
Microsystems,
Inc.,
definiert
eine
Standard-DTD
zur
Beschreibung von EJB Deployment-Informationen.
ERP
“Enterprise Resource Planning”.
Betriebswirtschaftliche Standardanwendung, z.B. SAP R/3 oder
von SAGE KHK.
Geschäftsregeln
Die Gesetze, Verordnungen, Richtlinien und Verfahren, die in
einem Computersystem codiert sind und die Kernaktivitäten eines
Unternehmens beschreiben. Auch als Geschäftslogik bekannt.
IIOP
„Internet Inter-ORB Protocol“.
IT
„Informationstechnologie“.
J2EE
„Java 2 Enterprise Edition“.
JDK mit zusätzlichen Packages, wie EJB, JSP, Servlets, JavaMail
und Web Application Server.
JDK
“Java Development Kit”.
Java Mail
Ein plattform und protokollunabhängiges Framework um Java
basierte Mail und Messaging Applikation zu erstellen.
JINI
„Java Intelligent Network Infrastructure“.
Jini regelt, wie Computer und andere Geräte untereinander im
Netzwerk kommunizieren.
JNDI
“Java Naming and Directory Interface”.
JMS
„Java Message Service“.
JSP
„Java Server Pages“.
Erzeugt auf der Web-Server-Seite dynamische HTML-Dokumente
auf Template-Basis (Server-seitiges Skripting), ähnlich wie ASP.
LAMP
Bezeichnung für ein Web-Entwicklungssystem auf der Basis Linux
- Apache - MySQL - PHP3.
Load Balancing
Das Verteilen der Aufgabenlast auf mehrere Computer, um eine
möglichst
gleichmäßige
und
effiziente
Lastverteilung
zu
gewährleisten.
LDAP
“Lightweight Directory Access Protocol”.
Dieses Protokoll bietet einen Standard für die Kommunikation mit
Datenbanken im Internet. Per LDAP können beispielsweise EMail-Verzeichnisse wie Bigfoot und Four 11 nach E-Mail-Adressen
oder Personennamen durchsucht werden.
Das Lightweight Directory Access Protocol ist eine vereinfachte
Form des Directory Access Protocol (DAP) von X.500. Es soll die
Nutzung von Directory Services für `schmale´ Internet-Clients
erleichtern, da X.500 als zu komplex und ressourcenfressend für
Web-Browser und Mail-Clients (E-Mail-Programme) angesehen
wird. Einträge in einem LDAP- oder X.500-Directory erlauben die
system- und ortsunabhängige Auffindung und Nutzung aller
Objekte in einem Netzwerk, ob es nun Rechner, Verzeichnisse,
Dateien, Dienste oder Personen sind.
Middleware
Anpassung, Umsetzung oder Verarbeitung von Informationen
zwischen zwei anderen Schichten. Meistens eine ApplikationsSchicht zwischen dem Präsentations-Client und dem DatenbankServer, etwa bei einer Three-Tier-Architektur (Drei-SchichtenModell) oder bei EAI. Häufig in Application Servern realisiert.
MySQL
Frei erhältliche relationale Datenbank.
PHP
„PHP
Hypertext
Preprocessor“
(früher
auch
Professionell
Homepage Construction Kit). Dynamische Web-Seiten durch WebServer-seitiges Skripting (Code erinnert an ASP und C) und
Datenbankanbindung (z.B. MySQL, ODBC). Besonders häufig
unter Linux verwendet (LAMP), aber auch für Windows erhältlich
(WAMP). Siehe auch CGI, ASP, JSP, Servlet, CFML, Application
Server.
RMI
„Remote Method Invocation“.
SAX
„Simple API for XML“.
SAX ist eine Programm-Schnittstelle für die Verarbeitung von
XML-Dokumenten
mit
Programmiersprache
wie
Hilfe
z.B.
einer
Java.
objektorientierten
Über
SAX
kann
die
Anwendung auf die einzelnen Elemente eines Dokumentes
zugreifen.
SCM
„Supply Chain Management“.
Servlet
Server Applet. Java-Programm, das, anders als normale JavaApplets, nicht im Web-Browser beim Client, sondern auf dem
Web-Server läuft.
SGML
„Standard Generalized Markup Language“.
SGML erlaubt es, Auszeichnungssprachen zu entwerfen.
Eine der bekanntesten Anwendungen von SGML ist HTML.
SOAP
„Simple Object Access Protocol“.
Ein Verfahren für den einfachen und verteilten Funktionsaufruf
zwischen Softwareobjekten unter Java.
Three-Tier-
Auch
Drei-Schichten-Modell
Architektur
Aufgabenbereiche
genannt.
Trennung
Client-Rechner/Präsentation,
der
drei
Applikations-
Server und Datenbank-Server.
UDDI
„Universal Description Discovery and Integration“.
Ein Standardvorschlag für den elektronischen Handel im Internet,
der von Ariba, IBM und Microsoft entwickelt wurde. Technisch
basiert er auf XML und SOAP.
URC
„Uniform Resource Names“.
URI
„Uniform Resource Identifiers“.
URI ist eine generische Menge von allen Ressource Benennungsund Adressierungsarten. Kurz gesagt umfassen URIs bisher:
Uniform Resource Names (URN): Identifikation von Ressourcen
(Was)
Uniform Resource Locators (URL): Wo sind Resourcen zu finden
Uniform Resource Characteristics (URC): Wie kann auf die
Ressourcen zugegriffen werden und andere Metadaten .
Das Acronym URI wird in der „Umgangssprache“ häufig synonym
zu URL verwendet.
URL
„Uniform Resource Locator“.
Eine URL ist eine eindeutige Identifikation einer Ressource (z.B.
einer Datei oder Web-Seite) durch die Zugriffsmechanismen (z.B.
HTTP oder FTP) und den Standort (Server).
Die allgemeine Form lautet:
Protokoll://Rechner.Domain[:Port]/Pfad/Datei[#Anker][?Parameter].
URN
„Uniform Resource Names“.
WAMP
Bezeichnung für ein Web-Entwicklungssystem auf der Basis
Windows - Apache - MySQL - PHP3.
WAS
„WebSphere Application Server“.
WSDL
„Web Services Description Language“.
XML-Beschreibung eines Web-Dienstes-APIs, das über UDDI
recherchiert und dann über SOAP benutzt werden kann.
WYSIWYG
„What You See Is What You Get“.
Wird meistens im Zusammenhang mit (HTML-) Editoren bzw.
Textverarbeitungsprogrammen verwendet
WWW
„World Wide Web“.
XML
„Extended Markup Language“.
XML soll es den Web-Site-Programmierern erleichtern, SGMLAnwendungen zu schreiben und dabei eigene Dokumententypen
(DTD) festzulegen. Die eXtensible Markup Language bietet
nämlich viele Mechanismen, die u.a. die Datenverwaltung im Netz
erleichtern sollen. Außerdem lassen sich somit strukturierte Daten
über Plattform-/ Betriebssystemgrenzen hinweg austauschen.
XSL
„eXtensible Style Language“.
XSL dient der Formatierung und Transformierung von XMLDokumenten.
XSLT
„XSL Transformations“.
Eine Sprache für die Umwandlung von XML-Dokumenten in
andere (XML-)Dokumente. XSLT wurde als Teil von XSL, einer
Stylesheet-Sprache für XML, entwickelt. XSL verfügt über den
Umfang von XSLT hinaus über ein XML-Vokabular für die Angabe
von Formatierungsinformationen.
Seite: 18
1 Einleitung
„Ein Anfang ist kein Meisterstück, doch guter Anfang halbes Glück.“
Anastasius Grün (1806-1876)
Wenn man sich das Abkürzungsverzeichnis auf den vorigen Seiten durchliest,
bekommt man einen ersten Eindruck mit welchem technologischen Themenumfang
ein Neuling im Gebiet Application Server konfroniert ist. Mit Bedachtnahme auf die
Tatsache, daß dieses Abkürzungsverzeichnis nur den absolut notwendigen Teil der
relevanten Technologie abdeckt, gelangt man schnell zu dem Schluß, daß diese
Fülle von einer Person alleine nicht abzudecken ist.
Studenten der Betriebswirtschaft, die Interesse haben im IT-Sektor als Manager tätig
zu werden, stehen vor mehreren bemerkenswerten Problemen. Erstens haben Sie
nicht die Ausbildung und das Wissen, um einen schnellen Zugang zu den
technischen Themen zu finden. Zweitens wird von Ihnen verlangt, nach Abschluß
ihres Studiums, eben diese Technologien einschätzen zu können und daraus
abgeleitet,
betriebswirschaftliche
Entscheidungen
treffen
zu
können.
D.h.
Absolventen der BWL müssen einen Weg finden mit den Handicaps der schlechteren
technischen Ausbildung und dem Umstand mit einem riesigen Themenkomplex
konfrontiert zu sein, fertig zu werden. Das Proseminar „WebEngineering“ von
Professor Flatscher zeigt einen Ansatz, wie man dieser Problematik begegnen kann.
Als Fokuspunkt der Veranstaltung wurden Application Server gewählt, da sie einen
ausgezeichneten
Anknüpfungspunkt
darstellen,
um
sich
mit
den
neuesten
Technologien zu beschäftigen. Die wichtigsten Ziele der Veranstaltung sind:
•
einen Überblick über die relevanten Technologien zu bekommen,
•
die Methodik des selbständigen Recherchierens und Erarbeitens von neuen
technischen Themen praktisch zu üben,
•
das objektive und kritische Einschätzen der Technologien und der damit
verbundenen Organisationen und
•
durch praktische Übungen das theoretisch erworbenen Wissen zu vertiefen.
Anknüpfend an das Proseminar soll die vorliegende Arbeit den Studenten an Hand
des IBM „WebSphere Application Servers“ beim Einstieg in die Materie helfen.
Seite: 19
Dazu wird den Studierenden vermittelt,
•
was ein Application Server ist und welche Vorteile er bietet,
•
welche Probleme mit dem Thema „Application Server“ verbunden sind,
•
welchen Aufbau die „WebSphere“ Produktplattform hat und welche Produkte von
IBM für diese Plattform relevant sind,
•
welche Technologien von einem Java-basierten Application Server verwendet
werden wie z.B. J2EE, JSP, Servlets, XML, EJB, etc. und wie diese grundsätzlich
funktionieren,
•
wie ein Referenzsystem aufgebaut wird und welche Tätigkeiten dazu notwendig
sind und
•
wie man eine WebApplikation anlegt, verpackt und installiert.
Seite: 20
1.1 Problemstellung und Ziele
Die Problemstellung, die zu dieser Arbeit geführt hat, kann am besten mit Hilfe eines
Schichtenmodells erklärt werden, das Abbildung 1 dargestellt.
Abbildung 1: Problemkreis
Am Beginn des WebEngineering- Proseminares stand das Problem innerhalb sehr
kurzer Zeit, ohne die Hilfe eines Referenzservers, einen Application Server
aufzusetzen und konfigurieren zu müssen.
Nachdem sich diese Prozedur als sehr langwierig und kompliziert herausstellte, lag
es nahe, eine ausführlich dokumentierte Referenzinstallation zu erstellen, um
nachfolgenden Teilnehmern die Arbeit und damit den Einstieg in die Thematik
wesentlich zu erleichtern.
Dieses Problem stellt den inneren Problemkreis dar. Die Installationsanleitung und
die Vorstellung des WAS sollen dazu beitragen, beim Leser Produktkompetenz für
den WebSphere Application Server aufzubauen. Diese Produktkompetenz soll dem
Leser die Möglichkeit geben den inneren Problemkreis zu überwinden.
Der äussere Problemkreis betrifft die Technologien, die den Einsatz eines Application
Servers erst sinnvoll machen und im WebSphere Application Server integriert sind.
Jeder BWL-Student, der sich für IT interessiert, sollte in der Lage sein, aktuelle
Technologien
grundsätzlich
verstehen
und
aufgrund
dieses
Wissens
Seite: 21
Einsatzentscheidungen treffen zu können. Die in dieser Arbeit enthaltenen Beispiele
sollen den Leser in die Lage versetzen, zu verstehen, welche Technologien im
WebSphere Application Server eingesetzt werden und welche Interdependenzen
zwischen ihnen bestehen. Dabei besteht der Anspruch des vorliegenden Werkes
nicht darin, jede einzelne Technologie im Detail in ihrer Funktionsweise zu erläutern,
da dies den Rahmen dieser Arbeit deutlich sprengen würde.
Der Fokus liegt vielmehr auf dem grundsätzlichen Verständnis wie Webtechnologien
wie z.B. Servlets, JSP, EJBs, u.v.a funktionieren und wie sie in einem Application
Server zusammenspielen.
Dieser
Weg
soll
dazu
beitragen,
den
Leser
dabei
zu
unterstützen,
Technologiekompetenz aufzubauen.
1.2 Aufbau der Arbeit
Die vorliegende Arbeit besteht aus mehreren Teilen.
Kapitel 2 beschreibt den grundsätzlichen, allgemeinen Aufbau eines Application
Servers, die beteiligten Komponenten und die Idee, die hinter der Verwendung von
Application Servern steht. In Kapitel 3 wird der Aufbau der WebSphere-Plattform, die
Architektur des Application Servers und die notwendigen Systemvoraussetzungen
beschrieben. Kapitel 4 enthält eine ausführliche Installationsanleitung für den
Application Server und alle notwendigen Entwicklungstools. Um das Verständnis für
die verwendeten Technologien zu erhöhen, werden im Kapitel 5 einige Beispiele zu
den wichtigsten WebTechnologien gegeben.
Seite: 22
2 Grundlagen zum Thema Application
Server
Dieses Kapitel widmet sich der Darstellung des grundsätzlichen Aufbaues eines
Application Servers und seiner Funktionen. Der Leser soll dadurch in die Lage
versetzt werden, die Grundprinzipien, die als Basis für einen Application Server
dienen, zu verstehen.
2.1 Application Server
Der Typus von Application Servern, die in dieser Arbeit besprochen werden, ist
webbasiert, d.h. er stellt seine Dienste im Inter- bzw. Intranet zur Verfügung.
Klassische Client/Server-Applikationen basieren auf dem 2-Schichten-Modell.
Dieser Begriff beschreibt ein System, in dem die Darstellung, Verarbeitung und
Verwaltung der Daten auf zwei Systeme aufgeteilt wird. Meistens übernimmt der
Client die Darstellung und Verarbeitung der Daten und der Server ist für die DatenVerwaltung zuständig. Der Vorteil dieses Modells liegt in der zentralen Datenhaltung
und der Aufteilung der Last auf zwei Systeme.
Doch dieses Modell hat auch Nachteile:
•
Wartungsprobleme
Wenn sich die gesamte Geschäftslogik in den Clients befindet, erschwert dieser
Umstand die Wartung, Pflege und Adaption der Applikationen.
•
Sicherheitsprobleme
Sensible Daten können auf wenigen, zentralen Systemen besser geschützt
werden,
als
auf
vielen,
dezentralen
Systemen.
Der Zugriff auf unternehmensinterne Informationssysteme wird durch dieses
Modell auch besser geschützt, da die direkt auf die Daten zugreifende
Komponente nicht mehr der Client ist, der sich in vielen Fällen ausserhalb der
eigenen Firma befindet. Diese Aufgabe wird im Drei-Schichten-Modell von
Komponenten in der 2. Schicht übernommen.
Seite: 23
•
Ressourcennutzung
Derzeit stellen Server wesentlich leistungsfähigere Systeme dar als Clients. Man
versucht daher, die ressourcenintensive Arbeit auf die besser dafür geeigneteren
Server zu verlagern.
Application Server folgen typischerweise dem Drei-Schichten-Modell und trennen die
Präsentationsaufgaben (ClientTier) von der Geschäftslogik (MiddleTier) und den
dazugehörigen Ressourcen (ResourceTier). Diese Trennung ist grundsätzlich nur
eine logische. Es kann durchaus vorkommen, dass zwei oder mehrere Komponenten
physisch auf einem Rechner vorhanden sind.
Abbildung 2: Drei-Schichten-Modell
Die Präsentationsschicht (Client Tier) hat die Aufgabe die Ergebnisse, die von der
Geschäftslogikschicht (MiddleTier) geschickt werden, aufzubereiten und darzustellen.
Clients, die die Daten darstellen, können von unterschiedlicher Machart sein:
•
Webbrowser,
•
Java-Applets,
•
Programme in C++, Visual Basic, Perl, Java, etc.
Seite: 24
Die Geschäftslogikschicht (Middle Tier) enthält Regeln, Verfahrensanleitungen
und Prozessdefinitionen, die speziell auf das jeweilige Unternehmen abgestimmt
sind. Diese sogenannten Business Rules werden in Komponenten verpackt, die dann
in weiterer Folge für die Modifizierung der Daten zuständig sind.
Die Ressourcenschicht (Resource Tier) stellt für die Geschäftslogikschicht die
Daten zur Verfügung.
Die häufigsten Repräsentanten dieser Schicht sind relationale Datenbanksysteme
(RDBMS) von Herstellern wie IBM, Informix, Microsoft, Oracle, SyBase, u.a.
Weitere Daten können aus Enterprise Information Systemen (EIS) bzw. aus
Systemen für Enterprise Resource Planning (ERP) kommen.
In diesem Bereich können z.B. die Produkte folgender Hersteller eingeordnet
werden: Baan, Peoplesoft, SAP, etc.
Application Server befinden sich in Schicht 2 (MiddleTier) dieses Modells.
Die Aufgaben eines Application Servers fokussieren sich deswegen auf der
Implementierung der Geschäftslogik und auf die Aufgabe als Vermittlungsschnittstelle zwischen den interessierenden Daten und den abfragenden Clients zu
fungieren.
Nachfolgend sind einige der wichtigsten Aufgaben von Application Servern
aufgelistet [vgl. ReHo01]:
•
Einbindung von Programmierumgebungen
Um die Wartbarkeit der Komponenten, die die Geschäftslogik enthalten, zu
gewährleisten und den Entwicklern eine möglichst effiziente Integration der
notwendigen Entwicklungswerkzeuge zur Verfügung zu stellen, ist es
unerlässlich, die Programmierumgebung an die Spezifika des Application Servers
anzupassen und einzubinden. Da die Entwicklung von Programmen auf
Application Servern häufig einen beträchtlichten Umfang erreicht, werden auch an
die organisatorischen Eigenschaften der Programmierumgebung gesteigerte
Anforderungen gestellt.
•
Ressourcenmanagement
Wenn Applikationen für das WWW geschrieben werden, ist der Bedarf an
Ressourcen (Prozessorleistung, Durchsatz, Speicherbedarf, usw.) nur schwer zu
eruieren. Eine weitere Erschwernis ist das kaum vorhersehbare Surfverhalten der
Seite: 25
Benutzer, das dazu führt, dass der Bedarf an Resourcen in relativ kurzer Zeit den
vorher festgelegten Rahmen sprengt. Deswegen gehören Funktionen wie Load
Balancing und Skalierbarkeit zu den wichtigsten Funktionen eines Application
Servers. Load Balancing ist das, nach unterschiedlichen Verfahren (round
robin,etc.), durchgeführte Verteilen der anfallenden Last auf alle zur Verfügung
stehenden Rechner. Unter Skalierbarkeit versteht man einerseits die Möglichkeit
die verwendete Hardware zu erweitern um die Performance zu steigern, wenn die
Resourcenanforderungen steigen. Andererseits wird darunter verstanden, daß die
betreffende Applikation ebenfalls Möglichkeiten zur Erweiterung vorsieht, um sich
den gestiegenen Resourcenanforderungen anpassen zu können.
•
Ausführungsumgebung
Die Geschäftslogik wird oft in Komponenten realisiert, die eine spezielle
Umgebung benötigen, um ausführbar zu sein. Diese sogenannten Container
bilden das Bindeglied zwischen dem Application Server und den einzelnen
Komponenten, wobei der Container die Komponenten steuert und überwacht.
•
Sicherheit
Unter diesem Punkt ist zu verstehen, dass der Application Server unberechtige
Zugriffe abwehrt und Benutzerrechte verwaltet.
•
Transaktionsmanagement
Transaktionen bestehen aus mehreren logisch zusammenhängenden Aktionen,
die allerdings nur ausgeführt werden sollen, wenn alle Aktionen durchgeführt
wurden. Sollte eine Aktion nicht durchführbar sein, so wird die ganze Transaktion
nicht durchgeführt. Eine wichtige Aufgabe eines Application Servers ist die zur
Verfügungstellung eines Transaktionssystem, das, je nach Anforderung der
Applikation, einen ausreichenden Grad an Sicherheit bietet.
•
Datenanbindung
Ohne Versorgung mit Daten sind selbst die besten Komponenten nur begrenzt
wertvoll. Deswegen verfügen Application Server über ausgefeilte Mechanismen,
um
den
Komponenten
Zugriff
auf
verschiedenste
Datenbanksysteme, ERP, EIS, etc. zu ermöglichen.
Ressourcen
z.B.
Seite: 26
Die eben dargestellten Aufgaben eines Application Servers stellen die zum Zeitpunkt
Ende 2001 maximal verfügbare Bandbreite von unterstützten Funktionen dar.
Pakete die alle genannten Funktionen unterstützen, sind meistens in sogenannten
Produktfamilien organisiert, in der jedes teilnehmende Produkt unterschiedliche
Aufgaben übernimmt. Die Produkte innerhalb einer Produktfamilie weisen häufig eine
starke gegenseitige Integration auf. Einige Application-Server unterstützen manche
Teile wie z.B. die Einbindung von Programmierumgebungen nicht und beschränken
sich auf die wesentlichsten Funktionen eines Application Servers.
Aus welchen einzelnen Komponenten ein Application Server Paket besteht, wird in
Kapitel 2.2 dargelegt.
Aus den obigen Aufgaben ergibt sich eine Gruppierung der Aufgaben in vier
Bereiche, die eine moderne Application Server Produktfamilie unterstützen sollte:
Abbildung 3: Die 4 Bereiche einer Application Server Produktfamilie [nach WUVO01]
Seite: 27
2.2 Komponenten eines Application Servers
Ein komplettes Application Server Paket besteht aus mehreren Einzelteilen, die
entweder alle als Produktfamilie von einem Hersteller angeboten werden (z.B.: IBM)
oder von unterschiedlichen Herstellern stammen.
Da der IBM WebSphere Application Server ein Java-basierter Application Server ist
und auch der überwiegende Anteil an Application Servern auf Java als Grundlage
setzt, konzentriert sich die Darstellung des Aufbaus von Application Servern
ausschliesslich auf diese Gruppe.
Die einzelnen Komponenten eines Application Server Paketes werden in Abbildung 4
dargestellt.
Abbildung 4: Aufbau eines java-basierten Application Server
Als Clients stehen grundsätzlich zwei Typen zur Auswahl:
1. Eine Applikation, die direkt auf den Application Server und die dort ausgeführten
Enterprise Java Beans (EJB) zugreift.
2. Ein Webbrowser, der entweder auf HTML-Seiten, Java Server Pages (JSP) oder
auf Servlets zugreift.
Seite: 28
Der Bereich des Middle Tier besteht aus zwei Applikationen, dem WebContainer und
dem Application Server, die beide stark miteinander verwoben sind. Der
WebContainer besteht aus dem eigentlichen WebServer, auch als HTTP-Server
bezeichnet und einem Container für JSPs und Servlets. Dem WebServer kommt
dabei die Aufgabe zu, statische bzw. dynamische, mit JSP generierten, HTML-Seiten
zur Verfügung zu stellen.
Der Application Server stellt einen EJB-Container, eine JSP- und Servlet-Engine zur
Verfügung. Der EJB-Container stellt die Umgebung dar, in dem die EJBs ausgeführt
werden können. Die JSP- und Servlet-Engine dienen zur Compilierung und
Ausführung von JSPs und Servlets. Die Komponenten der Geschäftslogikschicht
stellen den Kernbereich der Produktfamilie eines Application Servers dar.
Die Ressourcenschicht wird meistens von einem relationalen Datenbanksystem
repräsentiert.
Bei Komplettpaketen sind in der Regel weitere Teile im Lieferumfang enthalten:
•
Java-Entwicklungsumgebung,
•
Administrationsprogramme,
•
Datenbanksysteme (Oracle,IBM),
•
WebDesign-Tools,
•
Version-Verwaltungstools.
Grundsätzlich ist es möglich, alle notwendigen Teile für einen Application Server aus
Einzelkomponenten zusammenzusetzen. Das hat den Vorteil, dass man Open
Source Produkte verwenden kann, für die keine Lizenzkosten zu zahlen sind.
Komplettpakete haben den Vorteil, dass alle Komponenten gut aufeinander
abgestimmt sind und integrierte Entwicklungsumgebungen zur Verfügung stehen.
Seite: 29
2.3 Der Markt der Application Server
Der Markt der Application Server unterliegt einem ganz eindeutigen Trend bezüglich
der Basistechnologie in Richtung J2EE.
Grundsätzlich lässt sich der Markt in drei Fraktionen einteilen [siehe CiJe01]:
•
J2EE-basierte Lösungen,
•
Nicht J2EE-basierte Lösungen,
•
Microsoft-Technologie basierte Lösungen.
Abbildung 5: Application Server Markt
Im Teilmarkt der J2EE-orientierten Lösungen ist eine weitere Einteilung nach
Hardware-, Datenbank- und unabhängigen Herstellern möglich.
Bei den Hardware-Herstellern sind IBM mit der WebSphere-Plattform, Sun mit dem
Produkt iPlanet und HP mit dem Produkt Bluestone Total-e-Server vertreten.
Allen ist gemeinsam, dass
•
J2EE als Basis verwendet wird und
•
Unix als Betriebssystem der Wahl dominiert
Im Bereich der Datenbank-Hersteller finden sich Oracle mit 9iAS, SyBase mit
EAServer und wieder IBM mit der WebSphere Plattform. IBM qualifiziert sich
aufgrund der hauseigenen Datenbank DB2 auch für diese Kategorie.
Der
Teilbereich
der
sonstigen
Hersteller
ist
äußerst
vielschichtig
und
unübersichtlich. Eindeutig ist allerdings, dass BEA mit dem Produkt WebLogic im
Moment den grössten Marktanteil hat, noch vor dem „Riesen“ IBM.
Seite: 30
Ein nicht unwesentlicher Teil dieses Marktes wird von sogenannten Open-SourceProdukte wie Tomcat, Jboss, Jonas, u.s.w. gestellt.
Bei den Nicht-J2EE-Lösungen sind z.B. Macromedia Coldfusion und PHP zu
erwähnen, aber der Anteil solcher Lösungen am gesamten Markt ist ständig am
Abnehmen.
Microsoft ist in vielen Bereichen der Marktleader, aber die rasante Entwicklung im
Application Server Markt wurde vom Redmonder Softwarehersteller nicht früh genug
vorhergesehen. Aus diesem Grund spielt Microsoft in diesem Markt zum Zeitpunkt
Ende 2001 keine wesentliche Rolle und versucht über die neue .Net-Technologie,
verlorenes Terrain wieder gut zu machen. Ein weiterer Grund für die schlechte
Position Microsofts ist die augenblickliche Dominanz der J2EE-Plattform in diesem
Markt. Den Marktanteilszahlen von 1999 folgend (siehe Tabelle 1: Marktanteil
Application Server [nach GiZe01]) wird der Markt der Java-fähigen Application Server
von BEA und IBM dominiert. Die Vorhersagen für das Jahr 2000 ließen auf eine
weitere Festigung der Dominanz von IBM und BEA schließen.
Marktanteil in %
Hersteller
Vorhersage % 2000 Geschätzt % 1999
BEA
24%
32%
IBM
24%
16%
ATG
10%
5%
iPlanet
9%
6%
Allaire
8%
6%
Sybase
7%
15%
SilverStream
5%
4%
Bluestone
3%
3%
Oracle
3%
5%
Gemstone
2%
3%
Inprise
1%
2%
Iona
1%
0%
ObjectSpace
1%
1%
Persistence
1%
2%
Secant
0%
1%
Tabelle 1: Marktanteil Application Server [nach GiZe01]
Seite: 31
Abbildung 6 stellt die Marktanteilsverteilung am Application Server Markt im Jahr
2001 laut einer Erhebung von Gartner dar. Es ist deutlich zu erkennen, daß sich
auch im Jahr 2001 nichts an der Dominanz der Hersteller BEA und IBM geändert hat,
die zusammen 72% des Marktes für Application Server beherrschen.
Abbildung 6: Marktanteilsverteilung Application Server 2001 [nach SPCW01]
Neben der Veränderung der Marktanteile und einer starken Marktbereinigung ist
auch eine technologische Veränderung zu beobachten, die eine Verschiebung der
Positionierung der einzelnen Produkte zur Folge hat:
Abbildung 7: Markt Segmentierung [nach GiZe01]
Seite: 32
Abbildung 7 zeigt die Marktsegmentierung anhand der Kriterien Existenzdauer des
Produktes (neue Lösung – etablierte Lösung) und Unterstützung von einfachen bzw.
komplexen Applikationen. Anhand der Pfeile wird die vorauszusehende Entwicklung
der Produkte deutlich gemacht.
Seite: 33
3 IBM WebSphere Application Server
Dieses Kapitel soll dem Leser einen Überblick über die WebSphere Software
Plattform geben. Dazu wird zuerst der Aufbau der Plattform beschrieben, wobei auch
konkrete Produkte erwähnt werden, die in den einzelnen Bereichen zur Anwendung
kommen. Kapitel 3.1 beschäftigt sich mit den Komponenten der WebSphere
Plattform. Im Kapitel 3.2 wird die Architektur des WebSphere Application Servers und
die Funktionweise der wichtigsten Web-Technologien im Rahmen des Application
Servers übersichtsweise erklärt. Das Kapitel 3.3 gibt eine Übersicht über die
Systemvoraussetzungen,die notwendig sind, um die WebSphere-Plattform einsetzen
zu können. Die angeführten Web-Technologien finden auch als Beispiele Eingang in
die Referenzinstallation.
3.1 Aufbau der WebSphere Software Plattform
Der Aufbau der WebSphere Software Plattform [siehe WSPO01] besteht aus 4
Schichten,
wobei
jede
einzelne
Schicht
aus
unterschiedlichen
Produkten
zusammengesetzt ist (vgl. Abbildung 8).
Hierbei wird sowohl von IBM als auch von Drittherstellern entwickelte Software
eingesetzt.
Abbildung 8: Plattform-Aufbau [nach WSPO01]
Seite: 34
Wie sich die einzelnen Produkte in diese Umgebung eingliedern zeigt Abbildung 9.
Abbildung 9: WebSphere Plattform - Produktübersicht [angelehnt an WSPO01]
Abbildung 9 unterteilt sich, analog zu dem in Abbildung 8 dargestellten PlattformAufbau, in die drei Bereiche Foundation, Foundation Extensions und Application
Accelerators. Der Bereich, der die Customer und Partner Applications betrifft, wurde
absichtlich ausgelassen, da hier eine Fülle von verschiedensten Applikationen
einzuordnen wäre und eine Auflistung einiger Anwendungen das Verständnis der
Plattformstruktur nicht verbessert hätte.
Seite: 35
3.1.1
Foundation
Die Foundation-Schicht besteht aus dem WebSphere Application Server und
Produkten aus der MQSerie.
Die MQSerie dient zur Erleichterung der Integration von Applikationen und
Geschäftsprozessen aus heterogenen Systemen.
Als Basis des Application Servers wird J2EE verwendet und die Implementierung von
W3C-Standards wie:
•
Simple Object Access Protocol (SOAP),
•
Universal Description,Discovery and Integration (UDDI),
•
Extended Markup Language (XML) und
•
Web Servies Description Language (WSDL).
unterstützt unter anderem die Realisierung von WebServices.
Der WebSphere Application Server wird derzeit (September 2001) in drei Versionen
zur Verfügung gestellt, die sich an unterschiedlichen Benutzergruppen wenden und
einen unterschiedlichen Funktionsumfang haben. Die Advanced Edition, die im
Mittelpunkt dieser Arbeit steht, enthält den Funktionsumfang der Standard Edition
und erweitert sie um folgende Eigenschaften [siehe EsBe01, IBM101]:
•
Unterstützung von Enterprise Java Beans (EJB)
•
Klonen von EJB-Servern über mehrere Knoten um die Erreichbarkeit zu
gewährleisten und zu erhöhen
•
Unterstützung einer Mehr-Maschinen-Umgebung für Server und Servlets.
•
Workloadmanagement
Ab Sommer 2001 soll die Advanced Edition des Application Server die Standard
Edition ersetzen [vgl. AdZo01], wobei Letztere im Moment (September 2001) in
Version 3.5 erhältlich ist. Mit der Einführung des J2EE-Frameworks, das unter
anderem das API für EJBs enthält, als Basis für alle Editionen der Application Server,
konnte die Trennung zwischen Standard Edition und Advanced Edition nur mehr
schwer aufrecht erhalten werden. Diese Änderung wurde offenbar von IBM zum
Anlass genommen, die Produktpalette etwas zu straffen und neu auszurichten.
Nachfolgend wird der Funktionsumfang der einzelnen Editionen beschrieben, wobei
zum Zeitpunkt der Erstellung dieser Arbeit (Sommer 2001) nur die Advanced Edition
in der Version 4.0 vorlag. Die Enterprise Edition wird erst gegen Ende 2001 auf
Version 4.0 angehoben und hat derzeit (September 2001) die Version 3.6.
Seite: 36
3.1.1.1
Die Standard Edition des WebSphere Application Servers in Version 3.5 unterstützt
folgende Funktionen [siehe WSPS01]:
•
“Usability enhancements throughout, including a Quick Installation that eliminates
guesswork
•
Enhanced Java, leveraging Java 2 Software Development Kit V1.2.2 across all
supported operating systems
•
Support for JavaServer™ Pages, including:
o Support for specifications .91 and 1.0
o Extended tagging support for queries and connection management
o An XML-compliant DTD for JSPs
•
Support for the Java™ servlet 2.1 specification including a graphical interface,
automatic user session management and user state management
•
High speed pooled database access using JDBC for DB2® Universal Database™
and Oracle
•
XML server tools, including a parser and data transformation tools
•
XSL support
•
V3.5 supports Windows NT, Windows 2000, Solaris, AIX, AS/400, HP-UX, Red
Hat Linux, Caldera Linux, OS/390 and Novell Netware
•
IBM HTTP server, based on Apache Web Server, including:
o An administration GUI
o Support for LDAP and SNMP connectivity
•
Integration with IBM VisualAge® for Java to help reduce development time by
allowing developers to remotely test and debug Web-based applications
•
Tivoli Ready Modules
•
Fixpack 2: new functionality for Servlet 2.2 and JSP™ 1.1”.
Die Standard Edition kann nur auf einem einzelnen Server laufen, der gleichzeitige
Zugriff mehrerer Clients ist allerdings möglich.
Seite: 37
3.1.1.2
Die Advanced Edition ist in Version 4.0 erhältlich und unterteilt sich in drei
unterschiedliche Konfigurationen [siehe WSPA01]:
1. Single Server Configuration
Diese Konfiguration ist für Stand-Alone-Lösungen gedacht, für die die
Notwendigkeit von erhöhter Verfügbarkeit, Lastausgleich und Fernadministration
nicht vorhanden ist.
2. Full Configuration
Die Full Configuration bietet den vollen Funktionsumfang der Advanced Edition
und ist für Lösungen gedacht, die auf vielen Servern laufen müssen und
Hilfsmittel wie Caching, Clustering, Directory Services u.ä. benötigen.
3. Developer License
Diese Konfiguration ist für Entwickler gedacht, die eine einfach zu benutzende
Entwicklungsumgebung brauchen, um E-Business Lösungen zu entwerfen und zu
testen.
Die Unterschiede zwischen den drei Versionen sind in Tabelle 2 dargestellt:
Single
Server
Full J2EE
Yes
Web Services support
Yes
Connection Management & Yes
Pooling
XML Parsing
Yes
Expanded DB support
Yes
Built-in Web Server
Yes
Web-based Admin Console Yes
Firewall Support
Yes
Application Server
One
Machine configuration
Single
Security
Local OS
Directory Services
No
Application-level WLM
No
Clustering & Cloning
No
Additional Caching
No
Distributed Security
No
IIOP-based admin console No
Multi-Node administration No
IBM DB2 included
No
J2C supported
No
Developer
License
Yes
Yes
Yes
Full
Configuration
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
One
Single
Local OS
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Multiple
Multiple
OS,LDAP,Custom
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Tabelle 2: Funktionsvergleich [nach EnClu01]
Seite: 38
Der Funktionsumfang dieser Edition bietet folgende Funktionen [siehe WSPA01]:
•
“Integration with IBM e-business application development environments provided
by WebSphere Studio packages and VisualAge for Java Enterprise Edition, while
maintaining support of open Java technology standards and other third-party
Integrated Development Environments (IDEs)
•
Consistent, cross-platform support for Windows (NT and 2000), Sun Solaris, HPUX, AIX/6000, OS/400, Linux (Red Hat, SuSE, and Turbo) and Linux/390.
•
Deepest and broadest, leading-edge implementations of the most up-to-date
Java-based technologies and Application Programming Interfaces (APIs)
•
Comprehensive connectivity support for interacting with relational databases,
object databases, transaction processing systems, MQ-enabled applications, and
hierarchical databases
•
A migration path to a more scalable and transactional environment from
WebSphere Application Server Standard Edition with a superset of capabilities for
a complete production-level, J2EE-based Web application platform
•
A focus on medium- to high-level transactional environments used in conjunction
with dynamic Web content generation and Web-initiated transactions
•
Inclusion of an Apache-based HTTP Server with enhancements for security and
control as well as support for other major Web servers
•
Performance and scaling attributes that support bean-managed and containermanaged persistence for entity beans and session beans with transaction
management and monitoring
•
An easy-to-use XML-based administrator client and friendly server environment
for easy setup right out of the box
•
Container management and persistent storage within a transactional environment
for Java servlets and Enterprise Java Beans™ components
•
A rich eXtensible Markup Language (XML) parsing and configuration environment
•
Extensive interoperability with other elements of WebSphere software platform,
including:
•
e-commerce: WebSphere Commerce Suite
•
e-collaboration: Lotus Domino
•
Business
process
management:
MQSeries,
MQSeries
Integrator,
MQSeries Everyplace
•
Business-to-business communications: WebSphere Business Integrator
Seite: 39
•
Pervasive computing: WebSphere Everyplace Access, WebSphere User
Experience“.
Die zusätzlichen Funktionen, die in Version 4.0 zu dieser Edition dazugekommen
sind, werden im Detail in Kapitel 3.1.1.4 beschrieben.
3.1.1.3
Die Enterprise Edition ist momentan (Sommer 2001) in Version 3.6 verfügbar und
wird in Ende 2001 auf Version 4.0 angehoben.
Grundsätzlich besteht die Enterprise Edition aus dem Application Server in der
Advanced Edition und folgenden zusätzlichen Produkten:
•
Component Broker,
•
IBM TX Series,
•
IBM CICS Transaction Gateway,
•
IBM CICS Universal Clients,
•
IBM MQSeries und
•
IBM DCE.
Die Enterprise Edition stellt alle Funktionalitäten der Advanced Edition zur Verfügung
plus [siehe WSPE01]:
•
“Full distributed object and business process integration capabilities
•
IBM's world-class transactional application environment integration (from
TXSeries™)
•
Complete object distribution and persistence (from Component Broker)
•
Support for MQSeries®
•
Complete component backup and restore support
•
XML-based team development functions
•
Integrated Encina application development kit
•
Version 3.5 supports Windows NT, Solaris, AIX, and OS/390”
Seite: 40
3.1.1.4
Neue Funktionen in Version 4.0
Die Änderungen die in Version 4.0 der Advanced Edition eingebaut wurden sind im
folgenden aufgelistet [siehe WASO01]:
•
“Full Web services — SOAP, UDDI, WSDL, XML, and J2EE™ 1.2 (Java 2
Enterprise Edition platform) certification — including robust integration &
transaction technology
•
Unparalleled connectivity CORBA and Activex interoperability; and expanded
database support
•
Enterprise Java Beans™ (EJB) extensions
•
Internationalization allows for intelligent adjustments in business logic to
accomodate client locales for time zones, currencies, and languages.
•
Business rules beans enable dynamic updates without coding when business
practices change
•
Business Process Beans Technology Preview
•
Performance enhancements including dynamic reload of EJBs, dynamic caching
(muti-tier), JNDI caching, and more!
•
A new single-server configuration featuring browser-based administration and
new versions of our award-winning Visual Age for Java and WebSphere Studio.
Rapid installation is also available for development use at no charge.“
Auf die einzelnen Features der neuen Advanced Edition bezogen, sind folgende
Änderungen durchgeführt geworden [siehe EnClu01]:
•
Das J2EE-Framework wurde komplett als Basis übernommen. D.h. dass auch
das Container-Modell von J2EE übernommen wurde. Servlets und JSP, die bis
Version 3.5, in einer Servlet-Engine gelaufen sind, haben jetzt als Umgebung
einen Web-Container bekommen. Applets laufen jetzt in Applet-Containern und
Applikationen in Application-Containern.
•
Im Rahmen der neuen WebSphere-Version wurden die neuen Editionen
eingeführt. Die Unterschiede zwischen den drei Konfigurationen in der Advanced
Edition kann man Tabelle 2 auf Seite 37 entnehmen.
•
Die Implementierung von Java Connector Architecture, J2C, ermöglicht Zugang
zu ERP-Systemen und Grossrechnersystemen wie IBM CICS und IMS
ausgehend von der Java Plattform.
Seite: 41
•
Einige neue WebServices wurden integriert, um die Verbindung zu anderen
Marktplätzen und Applikationen zu ermöglichen
o WSDL
o UDDI
o SOAP
o XML
•
Hinzugefügt wurde ein verändertes Web-Plugin, das das HTTP-Protokoll zur
Kommunikation zwischen HTTP-Server und Application Server verwendet.
•
Hinzugefügt wurde ein integrierter HTTP-Server (Embedded Webserver), der die
Testarbeit erleichtert.
•
Performance-Verbesserungen.
•
Verbesserte und neue Administrationstools.
•
Unterstützung weiterer Betriebssystemplattformen und Datenbanksysteme.
3.1.2
Foundation Extensions
Die Bestandteile der Foundation Extensions-Schicht baut auf den Komponenten der
Foundation auf und teilt sich in die Untergruppen Entwicklung (Development),
Präsentation (Presentation) und Verteilung (Deployment).
Der Sinn dieser Schicht ist es Tools anzubieten, mit deren Hilfe man möglichst
einfach E-Business Lösungen erstellen, warten und optimieren kann. Dazu gehört
auch die Integration von Back-End Systemen in die Web-Applikation.
In den Kapiteln 3.1.2.1,3.1.2.2 und 3.1.2.3 werden die einzelnen Tools, die den
jeweiligen Untergruppen zugeordnet sind, kurz erklärt.
Seite: 42
3.1.2.1
Development
Diese Gruppe enthält alle Tools die die Entwicklung von Web-Applikationen
ermöglichen.
•
VisualAge for Java: Grafische Java-Entwicklungsumgebung inklusive Compiler.
•
WebSphere Studio: vollständiges Werkzeug für Web-Site-Entwickler die Web
Applikation in einer Teamumgebung entwickeln.
•
WebSphere Homepage Builder: vollständiges Werkzeug für Einzel-Web-SiteEntwickler die über keine HTML- oder Programmierkenntnisse verfügen.
•
WebSphere Business Components: Diese Komponenten ermöglichen die
Erstellung und Verwaltung von E-Business Aplikationen.
•
VisualAge Generator: Tool für die effiziente Entwicklung von skalierbaren, multitier Applikationen.
•
VisualAge Application Rules: ermöglicht Entwicklern schnell und basierend auf
Geschäftsregeln E-Business Applikationen zu erstellen und zu verteilen.
3.1.2.2
Presentation
Diese Gruppe beschäftigt sich mit der Verbesserung des Zuganges zu den WebApplikationen und der maßgeschneiderten Präsentation des Webangebotes.
•
WebSphere Personalization: ermöglicht regelbasierende Personalisierung, um
den Inhalt von Web-Seiten genauer auf den Benutzer abstimmen zu können.
•
WebSphere Portal Server: ist ein Programmpaket, dessen Einzelteile die
Erstellung eines Portales ermöglicht, das den Benutzerzugang zu Informationen
und Applikationen kanalisiert und die Kommunikation und Zusammenarbeit
erleichtert. Dieses Paket besteht aus WebSphere Personalization, Tivoli
SecureWay LDAP Directory, WebSphere Application Server, Advanced Edition
und Portlets.
•
WebSphere Voice Server: basierend auf dem VoiceXML Standard, ermöglicht
dieser Server die Zustellung von Sprach-Applikationen über das Web.
•
WebSphere EveryPlace Suite: ermöglicht den Benutzern einfachen Zugang zu
Web und Unternehmensdaten über eine grosse Bandbreite an Nicht-PC Geräten
wie z.B.: Handys, PDAs und anderen internetfähigen Geräten.
Seite: 43
•
WebSphere Everyplace Suite Embedded Edition: stellt eine integrierte
Middleware zur Verfügung, die Inhaltsentwicklungstools, Anpassungsdienste und
Server Integration für eine große Anzahl von Geräten enthält.
•
WebSphere Transcoding Publisher: Serverseitige Software die Daten anpasst,
umformatiert und filtert, um sie an unterschiedliche Umgebungen zu liefern.
3.1.2.3
Deployment
Diese Gruppe von Applikationen ermöglicht die Integration von EAI-Systemen, die
Erhöhung der Stabilität und Verfügbarkeit der Applikationen und der Analyse des
Zugriffverhaltens.
•
WebSphere Edge Server: addressiert das Problem der Stabilisierung von
Antwortzeiten, der Zuverlässigkeit und der Möglichkeit, abhängig von der
Nachfrage die Last der Applikation auf
Dies
wird
durch
Load-Balancing,
Caching
mehrere Server zu verteilen.
und
Inhalt-basiertes
Routing
bewerkstelligt.
•
WebSphere Site Analyzer: misst den WebSite Traffic und stellt unterschiedliche
Reportfunktionen zur Verfügung.
•
WebSphere Host Integration: ermöglicht die Anbindung von GroßrechnerSystemen.
•
MQSeries Integrator: ermöglicht den Transfer von Informationen zwischen
verschiedenen, heterogenen Applikationen aufgrund von Geschäftsregeln.
•
Tivoli Policy Director: ermöglicht zentralisierte Zugangskontrolle und Sicherheit
für Web Applikationen.
3.1.3
Application Accelerators
Application Accelerators helfen dem Entwickler modulare und an Kundenwünsche
angepasste Applikationen für B2B Integration, Workflow, Groupwork, E-Marktplätze
und Auktionen zu erstellen.
•
Lotus Domino: ist eine Software die Gruppenarbeit unterstützt und auch als
Plattform für die Integration von E-Business-Strategien fungiert.
•
WebSphere Commerce Suite: stellt eine integrierte E-Commerce Lösung, die
auf offenen Industriestandardarchitekturen und Standardprotokollen basiert, dar.
Seite: 44
•
WebSphere Business-to-Business Integrator: ermöglicht Unternehmen die
Integration zwischen den eigenen heterogenen Computersystemen und denen
ihrer Handelspartner.
•
MQSeries
Workflow:
ermöglicht
die
Erstellung
von
automatisierten
Geschäftsprozessen, die eine hohe Integration in bestehende EIS aufweisen
ohne die Notwendigkeit die Programmierlogik anzupassen, sobald sich die
Geschäftsprozesse ändern.
3.1.4
Customer and Partner Applications
Die letzte Schicht umfasst Applikationen die von Dritt-Herstellern produziert werden.
Mit Hilfe dieser Programme können Kundenwünsche implementiert werden, die
durch die vorhandenen Produkte in der WebSphere Produktfamilie nicht abgedeckt
sind.
Seite: 45
3.2 Websphere Application Server Architektur
Um das Zusammenspiel der einzelnen Web-Technologien zu verstehen, muss zuerst
erklärt werden, wie sich die Architektur des WebSphere Application Servers
zusammensetzt. Die Grundlage bildet wieder die Advanced Edition des Application
Servers, da diese Edition auch bei der Referenzinstallation verwendet wird.
J2EE stellt die Basis, auf die die wichtigsten Web-Technologien im WebSphere
Application Server aufsetzen. Aus diesem Grund ist das Kapitel 3.2.1 einem
Überblick über J2EE gewidmet. In direkter Verbindung mit der Sprache Java steht
das Bean Scripting Framework (BSF), dem das Kapitel 3.2.2 gewidmet ist.
Das Kapitel 3.2.3 befasst sich mit dem Administrationsmodell des WebSphere
Application Servers. Im Kapitel 3.2.4 wird ein kurzer Überblick über die wichtigsten
Administrationstools gegeben. Auf den Kapiteln 3.2.3 und 3.2.4 aufbauend erklärt
Kapitel 3.2.5 anschliessend die Komponenten des Application Servers.
Da XML in allen Bereichen von Relevanz ist, wird im Kapitel 3.2.6 ein Überblick über
diese Technologie gegeben. Eine weitere wichtige Erweiterung des Application
Servers sind die WebServices, die im Kapitel 3.2.7 kurz erläutert werden.
In den Kapiteln 3.2.8, 3.2.9, 3.2.10 und 3.2.11 werden die wichtigsten WebTechnologien und ihre Integration in den Application Server vorgestellt.
Das letzte Kapitel 3.2.12 gibt dem Leser einen Überblick wie EnterpriseApplikationen verpackt und im Application Server installiert werden können.
Seite: 46
3.2.1
J2EE Überblick
Der Begriff J2EE begegnet dem Leser in vielen Bereichen der IT-Landschaft.
Sun hat mit J2EE ein Framework definiert, das die weitere Zukunft der Javabasierten
Applikationsentwicklung
stark
prägen
wird.
Da
viele
notwendige
Webtechnologien (JSP,EJB,etc.) Teil der J2EE-Spezifikation sind bzw. auf sie
aufbauen, ist für die aktuellsten Vertreter der Java-basierten Application Server
J2EE-Konformität ein Muss-Kriterium. Dieses Kapitel soll dem Leser einen Überblick
über die J2EE-Plattform geben. Dabei soll geklärt werden, was J2EE ist, aus
welchen Komponenten das Framework besteht und welche Aufgaben diese erfüllen.
Das Ziel dieser Ausführungen ist nicht eine detaillierte Beschreibung der Plattform
oder der API’s zu geben, sondern den Leser mit den „Buzzwords“ vertraut zu
machen, die zum Verständnis von Web-Applikationen unerlässlich sind.
3.2.1.1
Definition
Java 2 Platform, Enterprise Edition (J2EE), ist eine Sammlung von Klassen, die
zusammen einen Standard für die Entwicklung von Java Applikationen definieren.
Dabei setzt J2EE auf der Java 2 Platform, Standard Edition (J2SE) auf und fügt alle
notwendigen Features zur Entwicklung von Server-side-Applikationen hinzu. Obwohl
die J2EE-Spezifikation Javasoft gehört und grundsätzlich von ihr entwickelt wurde,
gibt es viele unterschiedliche Firmen die zu diesem Standard beitragen. Die aktuell
gültige Version der J2EE Spezifikation ist 1.3 (Oktober 2001), Version 1.4 befindet
sich im Moment (Sommer 2001) im Review-Prozess und soll gegen Ende 2001
fertiggestellt sein. Die J2EE Spezifikation definiert:
•
Ein
Programmier-Modell
zum
Entwickeln
von
Server-side
Enterprise
Applikationen.
•
Ein Kompatibilitätstest-Verfahren, das die Deckung der Applikation mit dem
Referenz-Modell sicherstellen soll.
•
Eine Referenzimplementierung, die Entwicklern als Vergleich dienen soll.
•
Eine Runtime-Plattform, die als Standard-Plattform dient, um J2EE-Applikation
laufen zu lassen.
Seite: 47
3.2.1.2
Die J2EE-Plattform
Die J2EE-Plattform setzt sich aus drei Gruppen zusammen:
1. Komponenten wie JSPs, Servlets, EJBs, Applets und Java-Client-Applikationen,
2. Services und
3. Kommunikation
Abbildung 10: J2EE-Plattform [nach EnClu01,74]
Die J2EE-Komponenten Servlet, JSP und EJB werden in den Kapiteln 3.2.8, 3.2.9,
3.2.11 vorgestellt.
Die J2EE-Services und Kommunikationsfeatures umfassen folgende Dienste:
•
Java
Naming
and
Directory
Interface
(JNDI):
JNDI
stellt
eine
implementierungsunabhängige Schnittstelle zum Zugriff auf beliebige Namensbzw. Verzeichnisdienste dar. Unter einem Namensdienst versteht man die
Verknüpfung eines Namens mit einem bestimmten Objekt. Unter einem
Verzeichnisdienst versteht man eine Spezialform eines Namensdienstes. Der
Verzeichnisdienst bildet einen Namen auf Verzeichniseinträge ab.
•
Interface Definition Language (IDL).
Von der Object Management Group
entwickelte Spezifikation mit deren Hilfe im Rahmen von CORBA Schnittstellen zu
anderen Sprachen (Ada, C, C++, COBOL, Java, etc.) definiert und beschrieben
werden können.
•
J2EE-Connectors: J2EE-Connectors erlauben die Anbindung von heterogenen
EIS an die J2EE-Plattform über eine definierte Schnittstelle.
•
Java DataBase Connectivity (JDBC): JDBC bietet die Möglichkeit über eine
gemeinsame Schnittstelle auf „beliebige“ Datenbanksysteme zugreifen zu
können.Der Ausdruck „beliebige“ ist deswegen unter Hochkomma gesetzt, da ein
Seite: 48
Zugriff auf ein Datenbanksystem nur möglich ist, wenn für dieses System auch
ein passender JDBC-Treiber existiert. Zum aktuellen Zeitpunkt (Oktober 2001)
werden über die Java Homepage von Sun 154 Treiber zur Verfügung gestellt.
Unterstützt werden u.a. folgende Systeme: MS Access, MS SQL Server, MySQL,
Oracle, Progress, Sybase, usw.
•
Java Message Service (JMS): JMS ermöglicht die systemübergreifende
Kommunikation, die entweder als Punkt-zu-Punkt –Verbindung oder als PublizistAbonnent-System ausgestaltet sein kann.
•
Java
Transaction
API
(JTA):
Das
JTA
erlaubt
den
Aufbau
eines
Transaktionssystem zwischen den beteiligten Parteien wie Resource Manager,
Application Server, etc.
•
Java Transaction Service (JTS): JTS spezifiziert die Implementierung eines
Transaction Managers, der das JTA unterstützt.
•
JavaMail: Dieses API ermöglicht die Erstellung eines Plattform- und Protokollunabhängigen Mail- bzw. Nachrichtensystems.
•
Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP): dieses
Feature
basiert
auf
zwei
Technologien.
RMI
ermöglicht
die
verteilte,
objektorientierte Erstellung von Java-Applikationen. Den zweiten wichtigen Teil
liefert der offene, sprachunabhängige Standard Common Object Request Broker
Architecture (CORBA), der die Kommunikation zwischen verteilten Objekten und
Applikationen regelt. In einem CORBA Netzwerk übernehmen sogenannte Object
Request Broker (ORB) die Steuerung der Requests zwischen Clients und
Servern. Dabei verwenden die ORBs das IIO-Protokoll zur Kommunikation, das
wiederum auf TCP/IP basiert.
•
eXtended Markup Language (XML)
•
Lightweight Directory Access Protocol (LDAP)
Seite: 49
3.2.2
Bean Scripting Framework (BSF)
Ursprünglich wurde BSF von IBM entwickelt und über die Alphaworks-Website frei
zugänglich gemacht. Per Jänner 2001 wurde der Status des BSF geändert und in ein
Open Source Projekt umgewandelt.
Im Moment (Sommer 2001) wird das Projekt an die Apache Foundation übertragen.
Das Bean Scripting Framework (BSF) ist eine Architektur zur Integration von
Skriptsprachen in Java Applikationen und Applets. Das BSF besitzt eine einheitliche
Schnittstelle, die die Einbindung und Verwendung unterschiedlicher Skriptsprachen
ermöglichen soll. Dabei ist es möglich, von Java-Klassen auf Funktionen in der
Skriptsprache zuzugreifen und vice versa.
D.h. wenn Sie eine bestimmte Funktion, z.B. eine Datumsüberprüfungsroutine die in
VBScript geschrieben ist, benötigen, können Sie mit Hilfe des BSF aus einer JavaKlasse auf diese Funktion in VBScript zugreifen.
Ebenso ist der umgekehrte Weg möglich, von einer Skriptsprache aus auf JavaObjekte zuzugreifen.Das BSF Paket ist in Java geschrieben und gestattet Java
Programmen den Aufruf von Codezeilen in der betreffenden Ziel-Skript-Sprache.
Das zentrale Element in der BSF Architektur ist das BSF Manager Java Bean.
Dieses Bean stellt alle notwendigen Dienste zur Verfügung um Skriptsprachen in
Java zu integrieren. Das Bean hat ein Verzeichnis aller Skriptsprachen, die das BSF
verwenden kann (für eine Liste der zum jetzigen Zeitpunkt (Sommer 2001)
unterstützten Sprache siehe Tabelle 4). Der BSF Manager verwaltet auch eine Liste
von Java Beans die, sobald Sie im Manager registriert sind, von den Skriptengine
manipuliert werden können. Die BSF Engine ist das zweite, wichtige Element in der
BSF Architektur. Die BSF Engine ist die Schnittstelle, die den BSF Manager mit den
Skriptengines verbindet. In den meisten Fällen ist sie in Java implementiert, aber
manche BSF Engines sind auch in anderen Sprachen geschrieben und verbinden
sich zu Java über JNI. Die BSF Enginen ermöglicht Skripts den Zugriff auf vorher im
BSF Manager registrierte Java Beans, die Registrierung von neuen Java Beans, die
Veränderung bestehender Java Beans, die Registrierung von Ereignissen und den
Aufruf von Java Bean Funktionen.
Seite: 50
Abbildung 11 beschreibt die BSF Architektur.
Abbildung 11: BSF-Architektur (siehe KaPe01)
Der Aufruf kann mit Übergabeparametern und ohne Übergabeparameter erfolgen.
Tabelle 3 gibt eine Übersicht welche Arten des Zugriffs unterschieden werden [siehe
FlRo01, Seite 3]:
Zugriffsart Aktion
Exec
Übergibt den Skriptcode ohne Übergabeparameter an die Skript-Engine,
und bekommt nach Ausführung des übergebenen Scriptcodes keinen
Rückgabewerte zurück.
Eval
Übergibt einen, meist einzeiligen Skriptcode, ohne Übergabeparameter
an die Scriptengine und bekommt einen Rückgabewert von der
auswertenden Scriptengine zurück.
Apply
Übergibt einen mehrzeilige Skriptcode, der eine anonyme Funktion
repräsentiert, optionale Parameter und erwartet einen Rückgabewert
von der Script-Engine die den übergebenen Scriptcode ausführt.
Call
Übergibt das Zielobjekt, die aufzurufende Methode bzw. Funktion und
optional vorhandene Parameter.
Von der auswertenden Skript-Engine wird ein Rückgabewert geliefert.
Tabelle 3: BSF Zugriffsarten
Seite: 51
Einige Vorteile die sich durch die Verwendung des BSF ergeben, sind:
•
Keine Monokultur an Programmiersprachen notwendig,
•
erhöhte Wiederverwendbarkeit von bestehenden Softwarekomponenten,
•
Ausnutzen der spezifischen Stärken der jeweiligen Sprache,
•
erhöhte Flexibilität.
Zur Demonstration zeigt das folgende Java-Script-Programm die Verwendung von
Java-Elemente mit Hilfe des BSF.
Das Skript öffnet ein neues Fenster und erstellt einen Button mit dem Text „Hello
World“. Sobald man auf den Button drückt, schliesst sich das Fenster und gibt den
Text „JavaScript says goodbye“ aus.
f = new java.awt.Frame("JavaScript running in BSF");
bsf.addEventListener (f, "window", "windowClosing",
"java.lang.System.exit (0);");
b1 = new java.awt.Button("Hello World!");
bsf.addEventListener(b1, "action", null, "quit('JavaScript says
goodbye')");
f.add(b1);
f.pack();
f.show();
f.toFront();
function quit( s ) {
java.lang.System.out.println( s );
java.lang.System.exit(0);
}
Abbildung 12: Beispiel-Sourcecode für BSF
Folgende Sprache werden im Moment von BSF unterstützt:
Seite: 52
Sprache
Beschreibung
Nur Windows
BML
IBM's Bean Markup Language
Jscript
Microsofts Implementierung von JavaScript
X
Mozilla Rhino Netscapes Javascript.
NetRexx
Eine Java-Implementierung in einer einfacheren
Syntax.
ObjectRexx
Scriptsprache
Rexx
Scriptsprache
PerlScript
Activestate’s Perl Scripting Umgebung.
X
VBScript
Visual Basic Scripting Umgebung
X
Jacl
Java Implementierung eines grossen Subsets von
Tcl
JPython
Java Implementierung von Python
LotusXSL
IBM/Lotus Implementierung der XSL-Sprache
Tcl
Scriptsprache
Tabelle 4: Von BSF unterstützte Sprachen
Dabei ist zu beachten, dass die Integration weiterer Sprachen kontinuierlich forciert
wird und diese Angaben nur eine Momentaufnahme darstellen.
Das BSF findet in z.B. in folgenden Bereichen Anwendung:
•
Die Bean Markup Language (BML) verwendet das BSF, um Java Beans
einzubinden und zu manipulieren.
•
WebSphere
verwendet
BSF,
um
Skriptsprachen
in
die
JSP-Erstellung
einzubinden.
•
LotusXSL
(XSLT-Prozessor)
verwendet
BSF,
um
XML-Dokumente
zu
transformieren und formatieren. Dabei ermöglicht BSF das Einbinden anderer
XML-Parser, die zumindestens das Java API for XML Processing (JAXP)
Interface implementiert haben.
In den Beispielen, die bei der Installation des WebSphere Application Servers mit
installiert werden, ist auch eine Demonstration der Funktionsweise des BSF
enthalten.
Seite: 53
3.2.3
WebSphere Administrationsmodell
Der grundlegende Aufbau einer WebSphere Plattform beginnt mit dem WebSphere
Administrationsmodell. Das WebSphere Administrationsmodell besteht aus mehreren
Komponenten. Zu jeder Administrationsdomäne gehören ein oder mehrere Knoten,
sogenannte Nodes, und eine gemeinsame Datenbank auf die alle Knoten Zugriff
haben. Ein Knoten repräsentiert einen physischen Rechner auf dem zumindestens
das Administrationsserver-Service läuft. Auf jedem Knoten können auch ein oder
mehrere Application Server laufen.
Jeder Administrationsserver speichert seine Verwaltungsdaten in die gemeinsame
Administrations-Datenbank, in das sogenannte Repository.
Abbildung 13: WebSphere Administrationsmodell [nach EnClu01]
Jede WebSphere Ressource wie z.B. ein Servlet wird als Administrations Ressource
im
Administrationsserver
abgebildet.
Die
Administrationsressource
speichert
Konfigurationsinformationen über die WebSphere Ressource und stellt Methoden zur
Verfügung, um die WebRessource zu starten, zu stoppen und zu konfigurieren.
Seite: 54
Die Administrationsserver stellen Dienste zur Kontrolle der Ressourcen und für die
Einträge in das Repository zur Verfügung. Neben den oben genannten Diensten wie
Starten, Stoppen und Konfigurieren der Ressourcen bietet der Administrationsserver
auch noch folgende Dienste an:
•
Naming, um Objekt Referenzierungen zu ermöglichen.
•
Transaction monitoring, um den Ablauf von Transaktionen zu überwachen.
•
Security, zur Authentifizierung und Autorisierung.
3.2.4
Administrationstools
Der Application Server wird mit Hilfe von unterschiedlichen Tools administriert:
•
WebSphere Administrative Console (Admin Console),
•
Java Administrative Console,
•
WebSphere Control Program,
•
XMLConfig Tool.
Die ersten beiden genannten Tools besitzen ein grafisches Interface, die letzten
beiden können nur über die Command-Line bedient werden (siehe Abbildung 14:
Administrationsdienste).
Abbildung 14: Administrationsdienste [nach ArIy01]
Ein weiteres in Problemsituationen wichtiges Tool, ist „DrAdmin“. Dieses Tool
unterstützt den Administrator bei der Diagnose von Problemen.
Seite: 55
3.2.5
Websphere Application Server
In diesem Kapitel werden die wesentlichen Bestandteile des Application Servers
beschrieben.
Abbildung 15: Application Server Aufbau
Der Application Server enthält in der Advanced Edition folgende Komponenten:
•
Web-Container: In diesem Container können JSPs und Servlets ausgeführt
werden
•
EJB-Container: In diesem Container werden die EJBs ausgeführt (in der
Standard Edition nicht enthalten)
Eine weitere Komponente im Zusammenspiel mit dem Application Server ist der
HTTP-Server und das dazugehörige Plugin. Der HTTP-Server kommuniziert über
das Plugin mit dem Application Server.
Das Plugin benutzt ein XML-Konfigurationsfile um festzustellen,
ob ein
hereinkommender Request vom WebServer oder vom Application-Server behandelt
werden soll. Die Kommunikation läuft je nach Konfiguration über das HTTP- oder das
HTTPS-Protokoll. Als HTTP-Server kommt entweder der hauseigene IBM-HTTPServer zur Verwendung oder ein Fremdprodukt z.B. Apache für das ein Plugin
Seite: 56
existiert.
Der
im
Application
Server
eingebaute
HTTP-Server
sollte
aus
Performance- und Sicherheitsgründen nur für Testzwecke verwendet werden.
Der Application Server bietet auch die Möglichkeit an, mehrere, sogenannte Virtual
Hosts, zu definieren, die auf einer physischen Maschine laufen. Das erlaubt die
Konfiguration mehrerer unabhängig laufender und administrierbarer Applikationen,
ohne die Notwendigkeit, jeweils einen eigenen Server zur Verfügung stellen zu
müssen.
Server Groups ermöglichen die Erstellung von Vorlagen, um mehrere, gleichartige
Application Server inklusive ihres Inhaltes aufsetzen zu können.
Eine Server Group hat dieselbe Struktur und dieselben Attribute wie der Application
Server der als Vorbild benutzt wurde.
Diese Server Group kann JSPs, Servlets, EJBs und andere Ressourcen enthalten,
deren Attribute über die Administrationstools verändert werden können.
Es ist wichtig festzustellen, dass eine Server Group nicht mit einem bestimmten
Knoten oder physischen Maschine verbunden ist. Sobald der Administrator eine
Server Group angelegt hatte, können von dieser Klone abgeleitet werden. Server
Groups werden auch dazu verwendet, um die abgeleiteten Klone zu verwalten.
Klonen wird der Prozess des Ableitens von den Server Groups genannt. Dabei
entstehen sogenannte Klone, die, im Unterschied zu den Server Groups, mit real
existierenden Application Server Prozessen, die auf real existierenden Knoten
laufen, verbunden sind.
Klone können mehrmals oder einmal auf einer einzelnen Maschine laufen (vertical
scaling) oder über mehrere Maschinen (horizontal scaling) verteilt werden. Da die
Klone alle ident mit ihrer Vorlage sind, können die Anfragen an die Applikation je
nach Auslastung auf mehrere Maschinen verteilt werden. Diese Vorgangsweise
erlaubt Load Balancing.
Sobald ein Attribut der den Klonen zugrunde liegenden Server Group verändert wird,
verändert sich dasselbe Attribut bei den abgeleiteten Klonen. Die Änderung wird
allerdings erst nach einem Restart der Klone aktiv.
Seite: 57
3.2.5.1
Web-Container
Der Web-Container dient zur Verarbeitung von Servlets und JSPs. Der Ablauf bei der
Verarbeitung dieser Komponenten wird im Kapitel 3.2.8 und 3.2.9 erklärt.
Über die Administrationstools können einige Attribute des Web-Containers wie der
Name des Application Servers in dem der Web-Container sich befindet, Art und
Anzahl der Verbindungen zwischen dem Application Server und dem Web-Container
und der Port auf den der Web-Container hört, konfiguriert werden.
Jeder Application Server hat genau einen Web-Container, der zwar verändert, aber
nicht gelöscht werden kann.
Als Web Module wird eine Web Applikation bezeichnet, die sich aus Servlets, JSPs
und statischen HTML-Seiten zusammensetzt. Diese Kollektion aus Dateien wird in
einer einzelnen Web-Archiv-Datei (.war) gespeichert, die eine Java-StandardArchivdatei ist.
Zusätzlich zu dem Archiv wird eine XML-Datei namens web.xml angelegt, die
Informationen über den Inhalt der WAR-Datei enthält. Diese Informationen betreffen
die Struktur der enthaltenen Dateien, die Abhängigkeiten von externen Ressourcen
und die Anleitung, wie die einzelnen Teile zur Run-Time verwendet werden sollen.
Ein Web Modul kann entweder als Stand-Alone-Applikation verwendet werden oder
in Kombination mit anderen Modulen (Web, EJB oder anderen) als J2EE-Applikation.
3.2.5.2
Enterprise Java Beans - Container
Der EJB-Container stellt die Runtime-Umgebung zur Verfügung, um EJB zu
installieren und zu betreiben. Der Container ist ein Service, das sowohl Session
Beans als auch Entity Beans unterstützt.
Die EJBs kommunizieren nicht direkt mit dem Application Server, sondern nutzen
den Container als Schnittstelle. Zusammen mit dem Application Server bildet der
Container die Runtime-Umgebung für EJBs. Der Container kümmert sich um
Datenspeicherung und –abruf, indem er low-level services wie Threading und
Transaction support zur Verfügung stellt.
Ein EJB-Modul besteht aus einem oder mehreren Enterprise Beans und wird in
einem Java-Standard-Archiv namens JAR abgelegt. Analog zum Web-Modul wird
zusätzlich zu der JAR-Datei eine XML-Datei angelegt, die ebenfalls Informationen
über die Struktur des EJB-Moduls, die externen Abhängigkeiten und die Anleitung,
wie die einzelnen EJBs zu verwenden sind, enthält.
Seite: 58
Genauso, wie ein Web-Modul stand-alone laufen oder mit anderen kombiniert
werden kann, ist es möglich, ein EJB-Modul ohne andere Module oder in
Kombination mit anderen Modulen laufen zu lassen.
Seite: 59
3.2.6
XML
Dieser Abschnitt gibt dem Leser einen Überblick über XML und damit zusammenhängenden Technologien wie z.B. XSL.
3.2.6.1
XML Grundlagen
XML steht für „eXtensible Markup Language“, ist eine Auszeichnungssprache und ist
eine Teilmenge von SGML.
XML wurde hauptsächlich für die Strukturierung und Beschreibung von Daten
entwickelt. XML selbst kennt, im Unterschied zu HTML, keine Marken (wie z.B. H1),
die die Darstellung der Elemente z.B. im Browser beeinflussen.
Wie SGML ist XML eine Auszeichnungssprache, die dem Autor die Möglichkeit gibt
selbstdefinierte Marken mit Daten zu verknüpfen. Der Zweck von Marken ist
Information über die Daten zu Verfügung zu stellen, mit denen sie verknüpft sind.
Demzufolge besteht eine XML-Dokument üblicherweise aus Marken und aus den
dazugehörigen Daten. Im folgenden Beispiel gibt die „<autor>“ Marke an, dass
„Michael Jeschko“ den Name eines Autors beschreibt:
„<autor>Michael Jeschko</autor>“
Die Syntax von XML ist ähnlich der von HTML. Sie ist allerdings wesentlich strikter in
der Auslegung:
•
Öffnende Marken müssen auch ein schliessende Marke haben.
•
Die Marken sind case-sensitiv und ineinander verschachtelt.
•
Verschachtelte Marken müssen korrekt geschlossen werden.
•
Jedes Dokument muss eine Root-Marke haben.
•
Attribut-Werte müssen immer unter Hochkomma gestellt werden.
XML-Dokumente, die alle für XML definierten Bedingungen erfüllen, werden well
formed genannt. Der Ausdruck der Gültigkeit eines Dokumentes bezieht sich auf den
Umstand ob ein XML-Dokument, dass sich auf eine bestimmte Document Type
Definition (DTD) bezieht, sich an die von der DTD definierte logische Struktur hält.
Wenn das Dokument sich an die in der DTD definierten Struktur hält, wird es als
gültig bezeichnet. Die Document Type Definition enthält u.a. die logische Struktur
(Hierarchie) der dazugehörigen Dokumente, die Elemente die im XML-Dokument
vorkommen dürfen, die Definition welche Art von Daten (numerisch, alphabetisch,
etc.) durch eine Marke beschrieben werden usw.
Seite: 60
Mit Hilfe einer DTD wird ein XML-Parser in die Lage versetzt zu überprüfen ob ein
vorliegendes XML-Dokument gültig ist. Ohne eine DTD kann ein Parser nur
feststellen ob ein XML-Dokument well-formed ist, d.h. ob es sich an die XMLSpezifikationen hält.
Abbildung 16 zeigt ein Beispiel für eine DTD.
<?xml version = “1.0”?>
<!DOCTYPE authors [
<!ELEMENT authors(author)+>
<!ELEMENT author(firstname, lastname, title)>
<!ELEMENT firstname(#PCDATA)>
<!ELEMENT lastname(#PCDATA)>
<!ELEMENT title(#PCDATA)>
...
Abbildung 16: DTD-Beispiel
Abbildung 17 demonstriert den Aufbau eines XML-Dokumentes, in diesem Fall hält
das Dokument die Marktanteile verschiedener Web Server für die Jahre 1997-1999
fest:
<?xml version="1.0" ?>
<marketshare>
<marketname>Web Server</marketname>
<year value="1998">
<product pname="Apache">50.6%</product>
<product pname="Netscape">8.2%</product>
<product pname="Microsoft">22.7%</product>
</year>
<year value="1997">
</year>
<year value="1999">
</year></marketshare>
Abbildung 17: XML-Beispiel [nach EnCh01]
3.2.6.2
XSL
Da XML nur die Struktur der Daten beschreibt, besteht die Notwendigkeit, eine
Technologie zur Verfügung zu stellen, die dem Anwender die Möglichkeit gibt zu
definieren, wie die Daten dargestellt werden sollen.
Hier kommt die Extensible Style Language (XSL) ins Spiel. XSL ist eine Sprache zur
Beschreibung von Stylesheets. XSL besteht aus drei Teilen:
Seite: 61
•
XSL-Transformation ist eine Sprache zur Transformation von XML-Dokumenten.
•
XML Path Language (XPath) ist eine Ausdruckssprache die u.a. von XSLT
verwendet wird, um Zugang zu Teilen von XML-Dokumenten zu erhalten oder
dorthin zu verweisen.
•
XSL Formatting Objects definiert ein XML-Vokabular um FormatierungsSemantiken zu spezifizieren.
Ein XSL-Stylesheet ist eine Datei, die angibt, wie ein bestimmtes XML-Dokument
darzustellen ist. Obwohl XSL eine unterschiedliche Syntax verwendet, ist sie
kompatibel zu CSS2. Für nähere Ausführungen siehe W3C01.
Abbildung 18 zeigt ein XSLT-Stylesheet, mit dem das XML-Dokument (vgl. Abbildung
17) über die Marktanteile einiger Webserver in ein HTML-Dokument umgewandelt
werden kann [siehe EnCh01]:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.0">
<xsl:output method="html"/>
<xsl:template match="/">
<HTML>
<HEAD>
<STYLE TYPE="text/css">
.tableText{
font-weight : bold;
font-family : monospace;
background-color : silver;
text-align : right;}
</STYLE>
</HEAD>
<BODY>
<H1>Market share report for the
<xsl:apply-templates select="marketshare/marketname"/>
market
</H1>
<TABLE BORDER="1" class="tableText">
<THEAD>
<th></th>
<xsl:for-each select="marketshare/year[1]/product">
<xsl:sort order="ascending" select="@pname"/>
<th><xsl:value-of select="@pname"/></th>
</xsl:for-each>
</THEAD>
<TBODY>
<xsl:for-each select="marketshare/year" >
<xsl:sort order="ascending" data-type="number"
select="@value" />
<tr><td><xsl:value-of select="@value"/></td>
<xsl:for-each select="product">
<xsl:sort order="ascending" select="@pname"/>
<td><xsl:value-of select="."/></td>
</xsl:for-each>
</tr>
</xsl:for-each>
</TBODY>
</TABLE>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>
Abbildung 18: XSLT-Beispiel [nach EnCh01]
Seite: 62
3.2.6.3
XSLT
XSLT ist die Sprache um XML-Dokumente in andere Dokumente wie z.B. andere
XML-Dokumente, HTML-Dokumente, WML-Dokumente, etc. umzuwandeln.
XSLT ist neben der reinen Umformatierung von XML-Dokumenten auch in der Lage,
aus
bestehenden
XML-Dokumenten
bei
der
Umwandlung
neue
Elemente
hinzuzufügen oder zu entfernen. Es ist ebenfalls möglich, die Elemente
umzugruppieren, zu sortieren und festzulegen, welche Elemente dargestellt werden
sollen und welche nicht. Für die Transformierung von XML-Dokumenten verwendet
XSLT XSL-Stylesheets, die Vorlagen enthalten, wie die einzelnen Marken der
Vorlage umzusetzen sind. Um XSL auf XML-Dokumente anwenden zu können, ist
eine XSL-Engine notwendig, die die oben genannten Funktionen ausüben kann.
Mit geeigneten XSL-Dokumenten ist es damit möglich, XML-Dokumente in beliebige
Endformate zu formatieren und damit eine Datenquelle vielen unterschiedlichen
Endgeräten z.B. Handys, braillefähigen Endgeräte, PDAs, etc. zugänglich zu
machen. XML lässt dem Anwender die Freiheit, die Darstellung des XMLDokumentes von einem XSL-fähigen Client übernehmen zu lassen, oder die
Umformatierung gleich am Server vorzunehmen und dem Endgerät das passend
formatierte Dokument zu schicken. Ein weiterer Vorteil ist, dass XSL-Vorlagen nicht
nur auf ein bestimmtes XML-Dokument angewendet werden können, sondern
wiederverwendbar sind. D.h. man kann eine XSL-Vorlage auf viele verschiedene
XML-Dokumente
anwenden,
solange
die
Struktur
der
XML-Dokumente
im
Wesentlichen gleich bleibt.
Abbildung 19 zeigt wie das XML-Dokument nach Anwendung des XSLT-Stylesheets
durch einen XSLT-Prozessor in HTML aussieht. Dabei ist zu beachten, dass die
Daten nach Jahr und Hersteller sortiert ausgegeben werden, obwohl sie im XMLDokument ungeordnet enthalten sind.
Seite: 63
Abbildung 19: Beispiel für XSL-Konvertierung [nach EnCh01]
3.2.6.4
Weitere XML-Technologien
XPath wird dazu verwendet, um bestimmte Teile innerhalb eines XML-Dokumentes
zu adressieren. XPath wurde unter anderem entwickelt, um sowohl von XSLT als
auch von Xpointer verwendet zu werden. XPath wird auch von XML Linking
verwendet.
XPointer unterstützt den Zugriff auf die interne Struktur, wie Elemente oder Attribute,
von XML-Dokumente.
XLink ermöglicht dem Anwender, Links zwischen verschiedenen XML-Dokumenten
herzustellen. Dabei ist es auch möglich, auf mehrere Resourcen zu verweisen.
Namespaces erlauben dem Autor eines XML-Dokuments mehrere DTDs innerhalb
eines Dokuments zu verwenden, selbst wenn Elemente mit demselben Namen in
zwei oder mehreren DTDs definiert sind.
Ein Beispiel dafür wäre ein Bibliothekseintrag [siehe EnCh01]:
<?xml version”1.0”?>
<library-entry xmlns:authr=”authors.dtd”
xmlns:bk=”books.dtd”>
<bk:book>
Seite: 64
<bk:title>XML Sample</bk:title>
<bk:pages>210</bk:pages>
<bk:isbn>1-868640-34-2</bk:isbn>
<authr:author>
<authr:firstname>Joe</authr:firstname>
<authr:lastname>Bloggs</authr:lastname>
<authr:title>Mr</authr:title>
</authr:author>
</bk:book>
</library-entry>
Abbildung 20: Beispiel für Namespaces
In diesem Beispiel ist das Element title sowohl in der DTD für den Autor als auch
in der DTD für das Buch definiert. Mithilfe der Namespaces kann spezifiziert werden,
welches Element konkret gemeint ist.
XQL stellt eine Abfrage-Sprache ähnlich wie SQL zur Verfügung, um Daten aus
XML-Dokumente extrahieren zu können.
XSL Formatting Objects werden dazu verwendet, um die Darstellungsform eines
XML-Dokumentes festzulegen.
3.2.6.5
WebSphere und XML
Die Anwendungsmöglichkeiten für XML im Rahmen der IBM WebSphere Plattform
sind
vielseitig.
Einige
Konfigurationsdateien
sind
bereits
in
XML
codiert,
WebServices-Konfigurationsdaten, der Deployment Descriptor und das Web
Application Archive werden in XML abgespeichert.
Die WebSphere Plattform stellt einige Tools zur Verfügung, die die Verwendung von
XML unterstützen:
•
XMLConfig Tool – dient zur Administration des Application Servers,
•
XEENA – ist ein visueller XML-Editor,
•
XML Viewer – ermöglicht die Anzeige von XML-Dokumenten, ihre hierarchische
Struktur und die dazugehörigen DTDs,
•
XML for Java Parser – ein in Java geschriebener Parser zur Validierung von
XML-Dokumenten und zur Extrahierung der Daten aus XML-Dokumenten,
•
XSL-Editor – ermöglicht die Erstellung, Bearbeitung und Speicherung von XML
und XSL-Dokumenten,
•
LotusXLS – ist ein XSLT-Prozessor, der die Umwandlung von XML-Dokumenten
in beliebige andere Dokumente ermöglicht,
Seite: 65
•
DTD Catalogs (DTDs für WML, MathML, CDF),
•
u.v.m
Am Beginn jeder Arbeit mit XML-Dokumenten steht die Generierung dieser
Dokumente. WebSphere bietet im Wesentlichen drei Möglichkeiten:
1. Println-Statements aus Servlets,
2. mithilfe des DOM APIs in JavaBeans oder Servlets können XML-Dokumente
generiert und durch Servlets oder JSPs wieder ausgegeben werden,
3. mithilfe von XML-formatierten JSPs.
Im Zentrum jeder Applikation, die mit XML-Dokumenten arbeitet, steht der XMLProzessor. Die Aufgabe eines XML-Prozessors ist die Verarbeitung von XMLDokumenten, um die Daten über bestimmte Schnittstellen dem Programm zugänglich
zu machen, die Syntax zu überprüfen und zu kontrollieren, ob ein Dokument wellformed bzw. valide ist.
Im Moment haben sich zwei APIs als quasi-Standards etabliert, um auf die Daten, die
der Parser liefert, zugreifen zu können:
•
SAX – Simple API for XML,
•
DOM – Document Object Model.
Der von IBM zur Verfügung gestellte XML for Java Parser ist ein XML Prozessor und
arbeitet mit DOM.
Die Klassen des Java Parsers können in jede Java-fähige Applikation eingebunden
werden und ermöglichen so den Zugriff auf die notwendigen Verarbeitungskapazitäten, um mit XML-Dokumenten zu arbeiten.
Um XML-Dokumente in andere Dokumente umzuwandeln wird von IBM LotusXSL
zur Verfügung gestellt. Der Lieferumfang von LotusXSL enthält u.a. ein Servlet, das
direkt eingebunden werden kann und die Transformationen vornimmt.
Dieses Tool kann auch von der Command Line aus aufgerufen werden.
Seite: 66
3.2.7
WebServices
Die in Version 4.0 des Application Servers neu integrierten WebServices werden im
Folgenden kurz vorgestellt, da sie ganz neue Möglichkeiten zur Erstellung und
Vermarktung von Web-Applikationen eröffnen.
3.2.7.1
Definition
WebServices sind gekapselte, selbst-beschreibende, modulare Applikationen die
quer über das Internet verteilt und benutzt werden können. Eine solche Applikation
könnte z.B. Börsedaten sammeln und zur Verfügung stellen. Sobald ein WebService
installiert ist, können andere Applikationen oder WebServices dieses Service finden
und die zur Verfügung gestellten Funktionen, nutzen. WebServices sind sprach- und
betriebssystem-unabhängig, da sie sich auf bereits vorhandene Technologien wie
HTML und XML stützen.
3.2.7.2
Architektur
WebServices werden durch Service Providers zur Verfügung gestellt. Die
Funktionen, die ein WebService anbietet, werden mithilfe der Web Services
Description Language (WSDL) beschrieben.
Ein Service Broker hilft Service Provider und Service Requestors sich gegenseitig
zu finden. Ein Service Requestor benützt das Universal Discovery Description and
Integration (UDDI) API, um dem Service Broker mitzuteilen, was er für Services
benötigt. Der Service Broker liefert dem Service Requestor die gefundenen Resultate
der Anfrage zurück, die es dem Service Requestor ermöglichen, mit dem Service
Provider Verbindung aufzunehmen und die angebotenen Dienste in Anspruch zu
nehmen.
Abbildung 21: Web Service Komponenten und Vorgangsweise [nach EnClu01]
Seite: 67
3.2.7.3
WebServices Implementierung
Die WebServices Implementierung stützt sich größtenteils auf vier Technologien:
•
Web Services Description Language (WSDL),
•
Universal Discovery Description and Integration (UDDI),
•
Simple Object Access Protocol (SOAP),
•
eXtensible Markup Language (XML).
WSDL ist eine XML-basierte Schnittstellendefinitions-Sprache, die die Erstellung von
WebService-Katalogen inklusive einer Beschreibung der offerierten Funktionen
ermöglicht.
WSDL
definiert
die
WebService
Schnittstelle.
Diese
Schnittstellendefinition enthält Angaben über:
•
den Kommunikationstyp. D.h. wie funktioniert die Kommunikation zwischen dem
WebService und dem Anwender des Service (one-way, request-response,
notification).
•
Meldungen, die das WebService definieren.
•
verwendete Datentypen(XML-Schema).
•
das WebService Zugangsprotokoll. D.h. über welches Protokoll kann der
Anwender das WebService ansprechen (z.B. SOAP over http).
•
den WebService Kontaktpunkt. D.h. über welche Adressierung erreicht der
Anwender das WebService (z.B. WebService URL).
UDDI stellt ein globales und plattformunabhängiges Framework dar, das es
Unternehmen ermöglicht:
•
sich gegenseitig zu finden,
•
zu definieren, wie man miteinander interagiert und
•
in einer globalen Registry Informationen abzulegen.
Die Informationen, die ein Unternehmen preisgibt, wenn es sich bei einer UDDIRegistry anmeldet, sind:
•
„White pages“ : Adressen und Kontaktmöglichkeiten
•
„Yellow pages“ : standardisierte Angaben zu welcher Branche sich ein
Unternehmen zählt,
•
„Green Pages“: Technische Informationen über die angebotenen WebServices.
Im Moment (September 2001) existieren drei öffentliche Registries, die von IBM
(„http://www-3.ibm.com/services/uddi/“),
Microsoft
(„http://uddi.microsoft.com/“) und HP („https://uddi.hp.com/uddi/“)
Seite: 68
betrieben werden. Alle drei Registries befinden sich im Beta-Status und bieten die
Möglichkeit an, nicht näher beschriebene Web Services über die Registry
anzubieten. SOAP ist ein netzwerkneutrales, schlankes, auf XML-basierendes
Protokoll, das zum Datenaustausch zwischen zwei Applikationen dient.
Seite: 69
3.2.8
Servlet
Der folgende Abschnitt soll dem Leser einen Überblick über Servlets und ihre
Funktionsweise geben.
3.2.8.1
Überblick
Ein Servlet ist eine Web-Komponente, die in einem Container, dem WebContainer,
läuft und zur Erstellung von dynamischen Inhalten dient. Servlets sind kleine,
plattformunabhängige Java Klassen, die kompiliert im Container ausgeführt werden.
Um zu verstehen, wie der WebSphere Application Server mit Servlets arbeitet, ist es
wichtig zu verstehen, wie die grundlegende Funktionsweise aussieht.
Die Kommunikation zwischen Clients und Servlets funktioniert mit Hilfe des
Request/Response-Modells, das als Standard-Interface im Java Servlet API definiert
ist. Der Ablauf der Kommunikation zwischen Client und Servlet gestaltet sich
folgendermaßen:
1. Der Client schickt eine Anfrage an den Application Server
2. Der Application Server leitet die Anfrage an das angeforderte Servlet weiter
3. Das Servlet konstruiert dynamisch eine Antwort an den Client, wobei auch
externe Ressourcen wie EJBs, Unternehmens-Datenbanken, EIS,etc. zum
Einsatz kommen können, und gibt sie an den Application Server zurück.
4. Der Server leitet die Antwort an den Client zurück.
Abbildung 22: Client-Servlet-Kommunikation [nach ArIy01]
Bezogen auf die Funktionalität verhalten sich Servlets wie Common Gateway
Interface (CGI)-Programme, haben aber im Vergleich zwei Vorteile aufzuweisen:
•
Plattformunabhängigkeit durch die Verwendung von Java
•
Performance-Vorteile: ein Servlet wird nur einmal vom Application Server geladen
und bedient jeden Request mit einem neuen Thread. Das hat den Vorteil, dass
Seite: 70
nicht für jede Anfrage das Servlet neu geladen und instanziiert werden muss, wie
es bei CGI-Programmen der Fall ist.
Das Java Servlet-API ist nicht Bestandteil der Kern-Funktionalität von Java, sondern
kann
als
Zusatz-Paket
bezogen
werden.
Diese
Pakete
(javax.servlet,
javax.servlet.http) bestehen aus Java-Klassen, die Standard-Schnittstellen zwischen
dem Web-Client und dem Servlet und dem Servlet und seiner Umgebung definieren.
Das Javax.servlet-Paket enthält protokollunabhängige Klassen um Servlets zu
erstellen, das javax.servlet.http-Paket erweitert die Funktionalität des Basispaketes,
um das HTTP-Protokoll zu unterstützen.
Die folgenden Ausführungen zum Lebenszyklus eines Servlets beschränken sich der
Einfachheit-halber auf das javax.servlet.http-Paket.
3.2.8.2
Der Servlet-Lebenszyklus
Ein WebClient kommuniziert nie direkt mit einem Servlet, sondern stellt die Anfrage
nach einem Servlet an den Application Server und dieser leitet die Anfrage an das
Servlet weiter. Die Aufgabe des Servers ist es, das Servlet bei Bedarf zu laden und
zu initialisieren, die Anfragen an die Servlets weiterzuleiten und ein Servlet bei
Bedarf wieder zu schließen. Sobald ein Servlet instanziiert wurde, wird bei jeder
Anfrage immer nur ein neuer Thread generiert, der die Anfragen behandelt. D.h. es
existiert immer nur eine Instanz eines bestimmten Servlets. Abbildung 23 zeigt wie
eine einfache Kommunikation zwischen einem Client und einem Servlet funktioniert.
Abbildung 23: Client-Servlet Kommunikation
Seite: 71
Der Lebenszyklus eines Servlets wird im Servlet-API durch die init, service(doGet
oder doPost) und destroy-Methoden repräsentiert.
Die init-Methode führt alle notwendigen Initialisierungen des Servlets durch, wie z.B.
die Etablierung einer Datenbankverbindung, und wird auf jeden Fall bei jeder
Instanzierung des Servlets einmal aufgerufen, bevor noch ein Request behandelt
wird. Sobald ein Servlet initialisiert ist, kann es Requests entgegennehmen. Jeder
Request wird von einem ServletRequest-Objekt dargestellt, jeder dazugehörige
Response durch ein ServletResponse-Objekt. Die service-Methode ist abstrakt
definiert und muss von jedem Servlet implementiert werden. Dabei werden als
Parameter das Response- und das Request-Objekt übergeben. Das Request-Objekt
enthält alle notwendigen Informationen über den Client und die Anfrage selber.
Das Response-Objekt enthält in den meisten Fällen eine dynamische generierte
HTML-Seite, die an den Client zurückgeliefert wird.
Die destroy-Methode wird aufgerufen, wenn ein Servlet wieder zerstört wird. In
dieser Methode können Tätigkeiten, wie das Schließen von Datenbankverbindungen
durchgeführt werden. Die getServletConfig-Methode liefert ein ServletConfigObjekt, das dazu benutzt werden kann, Initialisierung-Parameter zurückzuliefern.
Die getServletInfo-Methode liefert Informationen über den Author, die Version und
das Copyright des Servlets.
Abbildung 24
zeigt wie der Lebenszyklus eines Servlets an Hand der eben
vorgestellten Methoden aussieht.
Abbildung 24: Servlet Lebenszyklus [nach ArIy01]
Seite: 72
3.2.9
JSP
Die Java Server Pages-Technologie erlaubt, ähnlich den Servlets, die Erstellung von
dynamischen Webseiten. Diese Nähe zu den Servlets kommt nicht von ungefähr, da
JSP eine Erweiterung der Servlet Technologie darstellen.
Die JSP-Technologie trennt die Benutzeroberfläche von der Inhaltsgenerierung, um
eine Seiten-Layout-Änderung ohne Änderung des darunterliegenden Inhalts
durchführen zu können. JSP nutzen XML-ähnliche Marken („tags“, „actions“) und
Java-Scriptlets, um die Logik zur Erstellung des Inhaltes zu kapseln. Dabei profitieren
JSP von der engen Integration mit anderen Java-Technologien wie Java Beans und
Servlets. Im Normalfall bearbeitet ein Web-Entwickler eine HTML-Seite, die das
Layout, statisches HTML und Platzhalter-Marken für dynamischen Inhalt enthält.
Diese Platzhalter sind JSP-Marken („tags“, „actions“) oder Aktionen und beschreiben
den dynamischen Inhalt. Diese Aktionen können Java-Programme (JSP-Scriptlets
oder Ausdrücke) sein, die den dynamischen Inhalt erstellen. JSP Aktionen können
auch in der Form von speziellen JSP-Marken auftreten, die allgemein benötigte
Dienste, wie die Weitergabe eines SQL-Statements an die Datenbank übernehmen.
Die JSP Spezifikation 1.2 definiert acht Standard Elemente („actions“), die von jeder
JSP Implementation zur Verfügung gestellt werden müssen. Diese sind:
•
<jsp:root>
•
<jsp:text>
•
<jsp:forward>
•
<jsp:getProperty>
•
<jsp:include>
•
<jsp:plugin>
•
<jsp:setProperty>
•
<jsp:useBean>
Seite: 73
Zusätzlich zu den Standard Elementen unterstützt die JSP-Spezifikation ab Version
1.1 die Entwicklung von wiederverwendbaren Modulen, „custom actions“ genannt.
Eine custom action wird durch den Einsatz eines „custom tags“ in einer JSP
verwendet. Eine Sammlung von „custom tags“ nennt man „tag library“.
Custom tags haben folgende Eigenschaften:
•
Die aufrufende JSP kann mit dem Aufruf Attribute übergeben
•
Custom tags haben Zugang zu allen Objekten, die auch der JSP zugänglich
sind.
•
Custom tags können die Antwort, die von der JSP erzeugt wird, beeinflussen.
•
Custom tags können untereinander kommunizieren.
•
Custom tags können verschachtelt angeordnet werden und erlauben dadurch
eine komplexere Interaktion mit JSP.
Der Einsatz von JSP wird nur im Zusammenspiel mit JavaBeans und Servlets
empfohlen.
Dabei
übernimmt
das
Servlet
die
Aufgabe,
die
allfälligen
Benutzereingaben zu übernehmen, die Daten der Geschäftslogik entsprechend zu
verarbeiten und die Resultate in eine kleine Anzahl von JavaBeans zu verteilen.
Diese Beans werden an die JSP zurückgeliefert und die JSP muss nun nur mehr an
die richtigen Stellen die Attribute der Beans einfügen. Diese Art der Verwendung von
JSP nützt zwar nicht die komplette Leistungspalette aus, stellt aber in Hinsicht auf
Code-Wiederverwendung und Wartbarkeit die beste Lösung dar. Abbildung 25 zeigt
das Zusammenspiel der einzelnen Komponenten wie JSP, Servlet und JavaBean.
Abbildung 25: JSP-Einsatz
Seite: 74
Wie schon in Kapitel 3.2.5 dargelegt, laufen sowohl Servlets als auch JSP in einer
gemeinsamen Run-time-Umgebung, genannt WebContainer. JSP werden in Servlets
compiliert und nachdem sie compiliert sind, ist der Lebenszyklus der JSP sehr
ähnlich dem eines Servlets.
Abbildung 26: JSP-Lebenszyklus [nach ArIy01]
Wenn der WebContainer eine Anfrage für eine JSP bekommt, wird diese an den
JSP-Processor weitergeleitet. Sollte das die erste Anfrage für diese JSP sein,
existiert noch keine Java-Source-Code-Datei und keine Class-Datei für diese JSP.
Der JSP-Processor erzeugt nun zuerst aus der JSP-Datei eine Java Servlet SourceCode-Datei und compiliert diese, um eine Class-Datei herzustellen. Beide Dateien
werden nun im JSP-Processor-Verzeichnis abgelegt.
Abbildung 27: Java-Source-Code-File-Generierung [nach ArIy01]
Für alle nachfolgenden Anforderungen dieser JSP wird nun die bereits compilierte
Class-Datei verwendet. Das hat den Vorteil, dass nicht für jede einzelne Anfrage der
Vorgang des Erstellens der Source-Code-Datei und der Class-Datei durchlaufen
werden muss.
Seite: 75
3.2.10 JavaBean
JavaBeans stehen zwar nicht im Zentrum dieser Arbeit, spielen aber eine wichtige
Statistenrolle im Konzert des Application Servers. Aus diesem Grund erklärt dieser
Abschnitt kurz was JavaBeans sind und welche Idee hinter dieser Technologie
steckt. Am Zusammenspiel zwischen Servlets und JSP wird eine von vielen
Möglichkeiten des Einsatzes von JavaBeans demonstriert. Das JavaBean API
ermöglicht die Erstellung von wiederverwendbaren Java-Komponenten, die dem
Prinzip des „Write Once, Run Anywhere“ folgen.
Die Einsatzmöglichkeiten von JavaBeans sind praktisch unbegrenzt, wie einige
Beispiele zeigen sollen:
•
Kryptografie-Komponenten,
•
Kalender-Komponenten,
•
Datenzugangs-Komponenten,
•
Informationstransportmittel (siehe JSP),
•
XML-Decoder,
•
usw.
Die Funktionen, die ein JavaBean übernehmen kann, reichen von simplen Aufgaben
wie Datumsüberprüfung bis zu hochkomplexen Aufgaben, wie das Erstellen einer
Performance-Vorschau eines Aktien-Portfolios.
Beans können entweder für den Benutzer sichtbar sein oder unsichtbar im
Hintergrund ablaufen. Beim Einsatz von JavaBeans spielt es auch keine Rolle ob
man eigene, selbstgeschriebene Beans einsetzt oder Beans von Fremdherstellern
zukauft.
Zusammengefasst sind die wichtigsten Vorteile von JavaBeans:
1. JavaBeans profitieren von den Vorteilen des Java „Write once, run-anywhere“
Paradigmas.
2. Die Eigenschaften, Ereignisse und Methoden einer Bean, die einer Applikation
zur Verfügung gestellt werden, sind kontrollierbar.
3. Der aktuelle Zustand von Beans kann gespeichert und zu jedem beliebigen
späteren Zeitpunkt wieder reaktiviert werden.
4. JavaBeans sind verteilbar.
5. Ein und dasselbe Bean kann je nach Einsatzort (Server, Client) verschiedene
Aufgaben durchführen.
Seite: 76
3.2.11 Enterprise Java Bean
Enterprise Java Beans stellen ein Serverkomponentenmodell für eine verteilte und
objekt-orientierte Architektur dar. Weiters muss hier festgehalten werden, dass EJBs
kein Produkt sind, sondern ein API und Programmiermodell.
Die EJB Spezifikation legt nur fest, wie man ein EJB programmiert (API) und es zur
Verteilung und Installation beschreibt (Deployment Descriptor).
Die Voraussetzung, damit man EJBs verwenden kann, ist ein EJB-Container, der für
die EJB-Komponenten als Laufzeitumgebung dient und sie von low-level Diensten
wie Datenbankverbindungen, Transaktion, Sicherheit, Zustandsverwaltung, etc.
entlastet. Diese Entlastung ermöglicht die Konzentration auf die reine Geschäftsbzw. Applikationslogik. Der Leitsatz lautet „Deklarieren statt Programmieren“.
Der EJB-Container stellt für die EJBs die Laufzeit-Umgebung bereit.
Die Eigenschaften eines EJB und seine Anforderungen (Transaktionen,
Datenbankverbindungen, Sicherheit, etc.) an den Container bzw. den Application
Server stellen Metadaten dar und werden in einem sogenannten Deployment
Descriptor festgehalten.
Die im Deployment Descriptor enthaltenen Informationen werden teilweise bei der
Entwicklung und teilweise bei der Installation festgelegt. Jeder Aufruf eines Clients an
ein EJB wird vom Container abgefangen und dahingehend überprüft, ob eine
Leistung vom Container notwendig ist z.B. Öffnen einer Datenbankverbindung,
Starten einer Transaktion, Zugangsüberprüfung,etc.
Abbildung 28: EJB Funktionsprinzip [angelehnt an HrNo01]
Seite: 77
3.2.11.1
Rollen
Im Zusammenhang mit der Entwicklung, Installation und Administration von EJB
werden von den Beteiligten mehrere Rollen eingenommen:
•
Enterprise Bean Provider
o entwickelt die EJBs und
o legt die Schnittstellen fest, implementiert die Klassen und erzeugt die EJB-jarDateien.
•
Deployer
o konfiguriert die EJBs, um sie für die Laufzeitumgebung anzupassen.
•
EJB Container provider
o stellt den Container für die EJBs zur Verfügung und passt diesen an die
Anforderungen der EJBs an.
•
Application assembler
o erstellt neue Applikationen, die sich aus den Teilen Servlets, JSPs, HTML,
XML und EJBs zusammensetzen können.
•
EJB Server provider
o stellt den Application Server zur Verfügung und passt ihn an die Bedürfnisse
des EJB-Containers an.
•
System administrator
o überwacht und betreibt den Application Server.
Seite: 78
3.2.11.2
Arten von Beans
EJB Beans können in 2 Gruppen mit jeweils 2 Unterkategorien eingeteilt werden:
1. Entity Beans
•
Bean Managed
•
Container Managed
2. Session Beans
•
Stateful Beans
•
Stateless Beans
Session Beans haben entweder keinen Zustand (Stateless Bean) oder einen
Zustand, der für die Lebensdauer eines Beans gilt (Stateful Bean).
Die Existenz eines Beans beginnt mit der Erstellung durch den Client und endet mit
der Löschung durch den Client oder den Server. Stateful Session Beans die einen
Zustand haben, sind exklusiv einem Client zugeordnet, Stateless Session Beans
können unterschiedlichen Clients zugeordnet werden. Normalerweise überstehen
Session Beans den Absturz bzw. Neustart eines Servers/Containers nicht und haben
für den Client keine sichtbare Identität (Schlüssel).
Entity Beans haben eine persistenten Zustand, der entweder vom Bean (Bean
managed) oder vom Container (Container managed) verwaltet wird.
Entity Beans können von mehreren Clients gleichzeitig verwendet werden und
überstehen normalerweise den Absturz bzw. Neustart eines Servers bzw.
Containers. Jedes Entity Bean kann anhand eines Schlüssels eindeutig identifiziert
werden. Beans, die nicht selber für ihre Persistenz sorgen, müssen dem Container
mit Hilfe der Deployment Description, die zu persistierenden Felder offen legen und
damit wird der Container für die Speicherung des Zustandes des Beans in der
Datenbank zuständig. Bean Managed EJBs sorgen selber für ihre Persistenz.
Um Ressourcen zu sparen, können Entity Beans und Stateful Session Beans
passiviert werden, d.h. ihr Zustand wird gespeichert und bei Bedarf wird das Bean
mit dem gespeicherten Zustand wieder reaktiviert.
Session Beans werden normalerweise dazu benutzt, um Prozesse zu unterstützen,
die keine expliziten Zustände verlangen oder ein „Gedächtnis“ der erfolgten
Kommunikation brauchen. Mit Entity Beans wird die persistente Geschäftslogik
modelliert. Abbildung 29 erläutert den grundlegenden Unterschied zwischen Session
Beans und Entity Beans aus der Sicht der zugreifenden Clients.
Seite: 79
Abbildung 29: Session Beans vs. Entity Beans [angelehnt an HrNo01]
Als Beispiel zur Anwendung von EJBs kann ein Online-Shop dienen.
Dabei übernimmt ein Stateful Session Bean die Funktion eines Warenkorbes. In
diesem Session Bean werden über die Dauer der kompletten Session die Artikel
eingetragen, die der Benutzer kaufen möchte. Leitet der Benutzer den Kaufvorgang
ein, so wird über ein Stateless Session Bean, das auf die Daten des Stateful Session
Beans zugreifen kann, ein Entity Bean angesprochen, dass den internen Prozess
des Bestellens abwickelt.
3.2.11.3
EJB-Architektur
DieEJB-Architektur gestaltet sich folgendermaßen:
•
Die Bean Instance ist das eigentliche Enterprise Bean, das die Geschäftslogik
enthält.
•
EJB Remote Interface -Das EJB Remote Interface legt nach aussen alle zur
Verfügung stehenden Business-Methoden offen. Das EJB Object stellt die
Benutzersicht des EJBs und implementiert das EJB Remote Interface.
Das Interface wird vom Enterprise Bean Provider erstellt, die Implementierung
wird vom EJB Container Provider durchgeführt.
•
EJB Home Interface -Das Home Interface ist der Mechanismus mit dem ein Client
den Container anweisen kann, neue Instanzen eines EJB zu kreieren oder
bestehende EJBs zu finden oder zu löschen. Das Interface wird vom Enterprise
Bean Provider erstellt und wird vom EJB Container Provider implementiert. Durch
die Implementierung entsteht das Home Object eines bestimmten EJB.
Seite: 80
•
Naming Service -Ein Naming Service (LDAP, NDS, DNS, etc.), hilft dem Client
den EJB Container zu finden, auf dem das gesuchte EJB läuft. In Java wird der
Zugriff auf solche Services durch JNDI realisiert.
•
EJB Container -Der Container fungiert als Schnittstelle zwischen der Aussenwelt
und den EJBs und stellt dem EJBs low-level Services zur Verfügung.
•
EJB Server -Der EJB-Server stellt u.a. dem Container die notwendige Umgebung
zur
Verfügung
und
übernimmt
auch
Aufgaben
wie
load-balancing,
Resourcenmanagement, Sicherheitsdienste, etc.
Abbildung 30: Komponenten der EJB-Architektur
Der Ablauf des Zugriffes auf ein EJB beginnt mit der Suche des Clients über ein
Naming Service nach einem EJB-Container, der das gesuchte EJB enthält.
Ist das Bean gefunden, erhält der Client eine Referenz auf das Home-Object und das
EJB-Object. Mithilfe des Home-Objects ist es dem Client möglich, eine neue Instanz
des EJBs zu erzeugen oder eine bestehende zu löschen. Durch das EJB-Object
kann der Client die offengelegten Methoden des eigentlichen EJBs aufrufen.
Das EJB-Object nimmt diese Aufrufe entgegen und leitet sie an die entsprechende
Instanz des EJBs weiter. Wie man erkennen kann, kommunizieren Clients und EJBs
nie direkt miteinander, sondern nur über die im Container implementierten Interfaces.
Seite: 81
3.2.11.4
Transaktionen
Transaktionen gehören zu den Ressourcen, die vom EJB Container den EJBs zur
Verfügung gestellt werden können. Für die Einbettung des Transaktionssystems
werden die in Java Transactional Service (JTS) und Java Transactional API (JTA)
definierten Schnittstellen verwendet. EJBs unterstützen Transaktionen, deren
Grenzen entweder vom Client, EJB oder vom Container festgelegt werden.
Über diverse Bridges ist die Anbindung von bestehenden Transaktionssystemen(IBM
CICS, Siemens openUDM, etc.) an den EJB Server möglich.
3.2.11.5
Datenbankzugriffe
Für die Datenbankzugriffe der EJBs ist der Container zuständig, der dafür die JDBCSchnittstelle verwendet. Die Datenbankverbindungen werden vom Container
verwaltet und in einem Pool gesammelt. Über JNDI und einem Name Service können
EJBs die Referenz auf eine Datenbankverbindung anfordern. Sobald ein EJB eine
Datenbankverbindung nicht mehr braucht, wird diese Verbindung wieder an den Pool
zurückgegeben, wo sie dann eine andere EJB verwenden kann.
D.h. die Verbindungen werden von EJB nicht physisch sondern nur logisch
geschlossen.
3.2.11.6
Sicherheit/Authentifizierung
Die Authentifikation von Clients bzw. Benutzern ist nicht Teil der EJB-Spezifikation,
sondern wird vom Application Server übernommen.Diesen Bereich deckt u.a. in der
WebSphere Produkt Plattform das Produkt Tivoli Policy Director ab. Der Application
Server muss allerdings dem Container Daten über die Identität des Clients
bereitstellen. Dazu gehört, wer der Client ist und welchen Rollen er zugeordnet ist.
Durch den Deployment Descriptor wird auch festgelegt, welche Rollen welche
Methoden verwenden dürfen. D.h. für jedes einzelne Enterprise Bean wird festgelegt,
welche Benutzerrollen es kennt und welche Rollen welche Methode aufrufen dürfen.
Da das im Application Server integrierte Sicherheitssystem auf jeden Fall anders
aussehen wird und andere Rollen definiert haben wird, als die vom Enterprise Bean
Provider im Deployment Descriptor festgelegten Rollen, müssen die im EJB
definierten Rollen auf die im Sicherheitssystem existierenden Rollen umgelegt
werden. Diese Aufgabe übernimmt der Deployer.
Seite: 82
3.2.12 J2EE - Applikationen
Eine J2EE Applikation besteht aus einem oder mehreren Modulen:
•
Enterprise Bean Module (EJB Klassen),
•
Web Module (Servlets, JSPs, Statische Resourcen wie HTML, GIF, JPGs, etc. ),
•
Client Module (Client Klassen).
Jedes dieser Module besitzt jeweils einen Deployment Descriptor. Der Deployment
Descriptor ist ein XML-Text-basierte Datei mit der .XML-Extension, der beschreibt
wie die einzelnen Komponenten zu installieren sind. Ein Descriptor für ein Enterprise
Bean Modul umfasst z.B. die notwendigen Definitionen damit das EJB Transaktionen
nutzen kann oder die Sicherheitsfeatures, die den Zugriff auf das EJB regeln.
Da der Descriptor nur deklarative Wirkung entfaltet, kann er geändert werden, ohne
den Sourcecode der betreffenden Komponenten verändern zu müssen. Zur Laufzeit
liest der Application Server die Definitionen aus dem Descriptor aus und passt die
Umgebung dementsprechend an. Nachfolgend sehen Sie ein Beispiel für den
Deployment Descriptor der Beispiel-Applikation, die im Installationsumfang enthalten
ist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application 1.2//EN"
"http://java.sun.com/j2ee/dtds/application_1_2.dtd">
<application id="Application_ID">
<display-name>WebSphere Application Server Samples</displayname>
<description>WebSphere Application Server Samples
EAR</description>
<module id="WebModule_1">
<web>
<web-uri>YourCo.war</web-uri>
<context-root>/WebSphereSamples</context-root>
</web>
</module>
<web>
<web-uri>Samples.war</web-uri>
<context-root>/WebSphereSamples/SingleSamples</contextroot>
</web>
</module>
<web>
<web-uri>theme.war</web-uri>
<context-root>/theme</context-root>
</web>
</module>
<module id="EjbModule_1">
<ejb>TimeoutEJBean.jar</ejb>
</module>
<ejb>IncrementEJBean.jar</ejb>
</module>
<ejb>HelloEJBean.jar</ejb>
</module>
Seite: 83
<ejb>AccountAndTransferEJBean.jar</ejb>
</module>
<module id="JavaClientModule_1">
<java>HelloEJBClient.jar</java>
</module>
</application>
Abbildung 31: Deployment-Descriptor [nach EnCl201]
Diese Module werden in einem Enterprise Application Archiv Datei (.EAR)
zusammengefasst. Die EAR-Datei ist eine Standard-JAR-Datei mit der Extension
.EAR. Eine EAR-Datei repräsentiert eine ganze J2EE Applikationen oder nur einen
Teil
davon,
da
sich
eine
Applikation
auch
aus
mehreren
EAR-Dateien
zusammensetzen kann. Die EAR-Datei besteht aus einem oder mehreren Enterprise
Bean-, Web- bzw. Application Client Modulen. Diese Bestandteile der EAR-Datei sind
im folgenden aufgelistet und werden grafisch in Abbildung 32 dargestellt:
•
Ein EJB Modul besteht aus einer .JAR-Datei, die den Deployment Descriptor, die
.class-Dateien für die Enterprise Beans und eventuell zusätzliche Dateien enthält.
•
Ein Client Modul besteht aus einer .JAR-Datei, die den Deployment Descriptor,
die .class-Dateien für den Application Client und eventuell zusätzliche Dateien
enthält.
•
Ein Web Modul besteht aus einer .WAR-Datei, die den Deployment Descriptor,
die .class-Dateien für die Servlets bzw. JSPs, JSP Dateien und eventuell
zusätzliche Dateien enthält.
Abbildung 32: Aufbau einer J2EE Applikation
Die
Kapselung
in
Wiederverwendbarkeit
homogenen
bestehender
Modulen
hat
Komponenten
den
Vorteil,
erhöht
Übersichtlichkeit auch bei grossen Applikationen bewahrt wird.
wird
dass
die
und
die
Seite: 84
Um eine J2EE Applikation zu packen, stellt der WebSphere Application Server das
grafische Application Assembly Tool (AAT) zur Verfügung.
Der stark ausgeprägte modulare Aufbau der J2EE Applikationen ermöglicht eine gute
Aufteilung der Aufgaben auf unterschiedliche Rollen. Daher wurden im Rahmen des
J2EE Frameworks einige Rollen definiert, die, je nach Grösse des Unternehmens,
von einer oder mehreren Personen erfüllt werden können.
Die ersten beiden Rollen (J2EE Product Provider, Tool Provider) übernehmen die
Prozesse der Auswahl, des Kaufes und der Installation des J2EE Produktes z.B. IBM
WebSphere Application Server, BEA WebLogic, usw. Die eigentlichen Komponenten
werden von einem Application Component Provider erstellt, von einem
Application Assembler zusammengesetzt und von einem Application Deployer
installiert. Die Aufteilung auf diese verschiedenen Rollen baut auf dem Prinzip auf,
daß jede Rolle eine verteilbare Datei als Output produziert, die wiederum den Input
für die nachfolgende Rolle darstellt. In der Applikationsentwicklungsphase erstellt ein
Entwickler in der Rolle als Application Component Provider diverse Enterprise
Beans, die in eine EJB .JAR-Datei zusammengefasst werden.
Die Rolle des Application Assemblers fasst mehrere JAR-Dateien und andere
Module zu einer Applikation zusammen und erstellt eine EAR-Datei.
Diese EAR-Datei wird von einem System Administrator in der Rolle des Application
Deployers im Zielsystem installiert und den gegebenen Umständen angepasst.
Abbildung 33 wiederholt anschaulich den Entwicklungsprozess einer J2EE
Applikation und demonstriert die Einbindung der unterschiedlichen Rollen in diesen
Prozess.
Seite: 85
Abbildung 33: J2EE Rollen im Entwicklungsprozess
Kapitel 5.3 auf Seite 167 ff zeigt an einem Beispiel einer einfachen J2EEApplikationen, wie das Packen und Installieren von Enterprise Applikationen
funktioniert.
Seite: 86
3.3 Systemvoraussetzungen
Die folgenden Tabellen geben darüber Auskunft, welche Hardware-Voraussetzungen
für die unterschiedlichen Editionen des WebSphere Application Servers gelten und
welche Betriebssysteme unterstützt werden. Die Angaben über den notwendigen
Hauptspeicher und Prozessor betreffen Intel-kompatible Systeme mit einem
Betriebssystem von Microsoft (Windows 2000 oder NT). Für andere Betriebssysteme
können die Angaben leicht variieren. Tabelle 5 dokumentiert die Anforderungen für
die Standard Edition Version 3.5 des Application Servers.
IBM Websphere Application Server Standard Edition Version 3.5
Hardware-Anforderungen
•
CD-Rom Laufwerk
•
Minimum 256 MB RAM, Empfohlen 512 MB RAM
•
75 MB auf der Festplatte
Software-Anforderungen
•
Windows NT Server 4.0 oder
•
Windows 2000 Server 5.0 oder
•
Solaris 2.6 oder
•
AIX 4.3.3 oder
•
HP-UX 11.0
•
Netscape Navigator 4.07 oder Microsoft Explorer 4.01
•
IBM JDK 1.2.2
Unterstütze Betriebssysteme
AIX, HP-UX, Solaris, Windows 2000, Windows NT.
Tabelle 5: Systemanforderungen „Application Server Standard Edition 3.5“ (Stand: Ende 2001)
Seite: 87
Tabelle 6 dokumentiert die Anforderungen für die Advanced Edition Version 4.0 des
Application Servers.
IBM Websphere Application Server Advanced Edition Version 4.0
•
CD-Rom Laufwerk
•
Minimum 384 MB RAM, Empfohlen 512 MB RAM
•
180 MB auf der Festplatte
•
Intel Pentium 500 Mhz
•
Windows NT Server 4.0 oder Windows 2000 Server 5.0 oder
•
Solaris 2.6 oder
•
AIX 4.3.3 oder
•
HP-UX 11.0 oder
•
Linux RedHat 7.1 oder SuSe 7.1
•
Netscape Navigator 4.73
•
Web Browser der HTML4 und CSS unterstützt
•
IBM JDK 1.2.2
AIX, HP-UX, Linux, NetWare, OS/2, OS/390, OS/400, Solaris,
Windows 2000, Windows NT und z/OS
Tabelle 6: Systemanforderungen „Application Server Advanced Edition 4.0“ (Stand: Ende 2001)
Seite: 88
Tabelle 7 dokumentiert die zusätzlichen Anforderungen der Enterprise Edition
Version 3.6 und der damit verbundenen Applikationen gegenüber der Standard
Edition Version 3.5.
IBM Websphere Application Server Enterprise Edition Version 3.6 Components Broker Server
Zusätzlich zu Anforderungen für den IBM Websphere Application Server
Advanced Edition Version 3.5
•
Minimum 256 MB RAM
•
800x600 Display
•
5 GB auf der Festplatte
•
Intel Pentium 300 Mhz
•
Windows NT Server 4.0 oder
•
Solaris 2.7 oder
•
AIX 4.3.3 oder
•
IBM JDK 1.2.2
AIX, Solaris, Windows NT
Tabelle 7: Systemanforderungen „Application Server Enterprise Edition 3.6“ (Stand: Ende 2001)
Tabelle 8 dokumentiert die Anforderungen und unterstützen Betriebssystem für den
IBM HTTP Server.
IBM HTTP Server Version 1.3.12.4
Keine Angaben
AIX, HP-UX, Linux, NetWare, OS/2, OS/390, OS/400, Solaris,
Windows 2000, Windows NT und z/OS
Tabelle 8: Systemanforderungen „IBM HTTP Server“ (Stand: Ende 2001)
Ein wichtiger Teil eines Application Servers stellt der HTTP-Server dar.
Seite: 89
Der WebSphere Application Server unterstützt per Plugin folgende HTTP-Server:
•
Apache Server, Version 1.3.12 oder höher, für AIX, Solaris, Windows NT und
HP-UX,
•
Netscape Enterprise Server, Version 3.5.1 oder höher, für AIX, Solaris und
Windows NT,
•
iPlanet Enterprise Server 4.0 für AIX, Solaris, Windows NT, Windows 2000 und
HP-UX,
•
Microsoft Internet Information Server 4.0 für Windows NT,
•
Microsoft Internet Information Server 5.0 für Windows 2000,
•
Lotus Domino Application Server, Release 5.0.2b für AIX, Solaris, Windows NT
und HP-UX,
•
IBM HTTP Server 1.3.12 for AIX, Solaris, Windows NT, Windows 2000 und
HP-UX.
Tabelle 9 gibt einen Überblick, welche Entwicklungstools und unterstützenden
Produkte auf welchen Betriebssystemen lauffähig sind.
Weitere Websphere Produkte
Produktname
Visual Age for Java
Windows 2000, Windows 98 und Windows NT
WebSphere Studio
Windows 2000, Windows 98, Windows Me und
Windows NT
WebSphere Homepage Builder
Windows und Linux
WebSphere Personalization
AIX, HP-UX, Linux, OS/400, Solaris, Windows
2000 und Windows NT
WebSphere Voice Server
Microsoft
Windows
NT.
Unterstützung
von
Windows 2000, Linux und Solaris ist geplant
WebSphere Transcoding
AIX, Linux, OS/400, Solaris, Windows 2000 und
Publisher
Windows NT
WebSphere Edge Server
AIX, Linux, Solaris, Windows 2000 und Windows
NT
WebSphere Site Analyzer
AIX, Linux, Solaris, Windows 2000, Windows 95,
Windows NT und Windows 98
Tabelle 9: Betriebssystemunterstützung für WebSphere Produkte (Stand: Ende 2001)
Seite: 90
4 Installation des WebSphere-Servers
Im Zentrum dieses Kapitels steht die Installation des WebSphere-Referenzservers.
Dazu werden im Kapitel 4.1 die Voraussetzungen aufgelistet, die notwendig sind, um
den Server aufsetzen zu können. Kapitel 4.2 und 4.3 erklären wie ein Benutzer unter
Windows 2000 angelegt und mit den notwendigen Rechten ausgestattet wird. Kapitel
4.5 enthält eine detaillierte Beschreibung wie die einzelnen Komponenten installiert
und konfiguriert werden. Um die Beispiele installieren, verwenden und verstehen zu
können, die im Kapitel 5 beschrieben werden, ist die Installation einiger zusätzlicher
Programme notwendig, die teilweise frei verfügbar im Internet zu beziehen sind. Die
dafür notwendigen Programme sind in Tabelle 10 aufgelistet. Da es im Rahmen der
vorliegenden Arbeit nicht möglich ist auch nur annähernd alle Komponenten der
WebSphere Plattform zu installieren, beschränken sich die Ausführungen auf die
wesentlichsten Teile. Tabelle 10 dokumentiert welche Produkte werden im Rahmen
des Referenzservers installiert werden.
Installierte Software
Produktname
Bemerkung
Bezugsquelle
Microsoft Windows 2000
Betriebssystem
Microsoft
IBM HTTP Server 1.3.19
WebServer
IBM
DB2 Enterprise Edition 7.2
Datenbanksystem
IBM
IBM WebSphere Application
Application Server
IBM
Java-Entwicklungstool
IBM
WebSphere Studio 4.0 Entry
Entwicklungstool für
IBM
Edition
JSP,Servlet,etc.
Xeena
Visueller XML-Editor
Alphaworks
XML Viewer
Viewer für XML-Dokumente
Alphaworks
XSLerator
Ein Tool zur Erstellung von
Alphaworks
Professional
Server Advanced Edition 4.0
VisualAge for Java 4.0 Entry
Edition
XSLT-Skripts
LotusXSL
Ein XSLT-Prozessor
Alphaworks
Tabelle 10: Übersicht über die installierten Produkte
Seite: 91
Alle
im
Zusammenhang
mit
XML
stehenden
Tools
können
unter
www.alphaworks.ibm.com (Alphaworks) kostenlos bezogen werden.
Die einzelnen Installationsabschnitte bestehen in den meisten Fällen aus drei Teilen:
1. Arbeiten, die vor der eigentlichen Installation des Produktes durchzuführen sind,
2. die eigentliche Installation und
3. Konfigurations- und Verifikationsarbeiten.
Seite: 92
4.1 Voraussetzungen und wichtige Hinweise
Die
an
dieser
Stelle
gemachten
Angaben
beziehen
sich
nur
auf
die
Referenzinstallation. Tabelle 11 listet den notwendigen freien Platzbedarf auf der
Festplatte auf, der benötigt wird, um die Applikationen zu installieren.
Hardware
200 MB Festplattenplatz (Minimum) für WebSphere Application Server
350 MB Festplattenplatz (Minimum) für IBM DB2 Personal Edition 7.1
50 MB Festplattenplatz (Minimum) für IBM HTTP Server 1.3.19
350 MB Festplattenplatz (Minimum) für Visual Age for Java 4.0 Entry Edition
300 MB Festplattenplatz (Minimum) für WebSphere Studio 4.0 Entry Edition
100 MB Festplattenplatz (Minimum) für die XML-Tools
135 MB Festplattenplatz (Minimum) für das TEMP-Verzeichnis
1485 MB ~ 1,5 GB Festplattenplatz (Minimum)
256 MB RAM (Minimum)
Tabelle 11: Hardwareanforderungen
Tabelle 12 enthält die betriebssystemseitigen Softwarevoraussetzungen.
Software
Microsoft Windows 2000 Service Pack 1.
Microsoft Internet Explorer 5 oder höher
bzw. Netscape Navigator 4.7 oder höher
Winzip
Tabelle 12: Softwareanforderungen
Die für die Referenzinstallation notwendigen und in Tabelle 10 auf Seite 90
angegebenen Applikationen, erlauben nur zum Teil (z.B. WebSphere Studio) eine
Installation unter Windows 98 bzw. ME. Für eine vollständige Installation aller
notwendigen Applikationen auf einem Rechner ist daher Windows 98 bzw. ME keine
Option. Grundsätzlich ist eine Installation des Application Servers unter Linux
möglich, allerdings ist zu diesem Zeitpunkt (Oktober 2001) z.B. das WebSphere
Studio nicht für Linux erhältlich. Damit ist eine komplette Installation des
Seite: 93
Referenzservers auf Basis Linux ausgeschlossen. Tabelle 13 dokumentiert die
Installationspfade, die für die wichtigsten Komponenten genutzt werden.
Software
WebSphere Application Server
D:\WebSphere\AppServer
WebSphere Application Server HTTP
D:\WebSphere\AppServer
Plugin
DB2 Server und Client
D:\Program Files\SQLLIB
IBM HTTP Server
D:\IBM HTTP Server
IBM VisualAge for Java 4.0
D:\Program Files\IBM\VisualAge for Java
Entry Edition
IBM WebSphere Studio 4.0
D:\Program Files\WebSphere\Studio40
Entry Edition
XEENA
D:\IBM\Xeena
XML-Viewer
D:\WebSphere\XMLTools\xmlviewer
XSLerator
D:\WebSphere\XMLTools\XSLerator
LotusXSL
D:\WebSphere\XMLTools\lotusxsl-j_2_0_1
Tabelle 13: Installationspfade
Im Laufe der Installation wird es notwendig sein, einige zusätzliche Benutzer
anzulegen. Tabelle 14 listet alle Benutzer auf, die für die Installation und den Betrieb
des Application Servers und der damit zusammenhängenden Applikationen (DB2,
HTTP Server, etc.) notwendig sind. Zusätzlich finden Sie in der Installationsanleitung
jeweils an geeigneter Stelle einen Hinweis darauf, welchen Benutzer Sie mit
welchem Namen und mit welchen Rechten anlegen sollen.
Notwendige Benutzer
Benutzername Beschreibung
db2admin
Administrationsbenutzer für die DB2-Datenbank
wasuser
Benutzer für den Zugriff des Application Server auf die
Administrationsdatenbank im DB2-System
wasadmin
Administrationsbenutzer für Application Server und HTTP Server
wsdemo
Benutzer für den Zugriff der Application Server Beispiele auf die
DB2-Datenbank
Tabelle 14: Notwendige Benutzer
Seite: 94
Sie können auch andere Benutzernamen verwenden, allerdings wird davon
abgeraten, da sich alle Ausführungen auf die in Tabelle 14 angegebenen Namen
beziehen. Wenn Sie selbstgewählte Benutzernamen verwenden, achten Sie darauf,
dass diese Benutzernamen nicht länger als 8 Zeichen sein dürfen, da es sonst im
Zusammenspiel mit DB2 zu Problemen kommt.
Weitere wichtige Namen, die im Rahmen der Installation benötigt werden, sind in
Tabelle 15 aufgelistet.
Weitere wichtige Namen
Name
Beschreibung
DB2 - DB2
DB2-Dienste
DB2 - DB2CTLSV
DB2 - DB2DAS00
DB2 JDBC Applet Server
DB2 JDBC Applet Server - Steuerzentrale
DB2-Lizenzserver
DB2-Sicherheitsservice
IBM HTTP Administration
HTTP Server Dienste
IBM HTTP Server
IBM WS AdminServer 4.0
Application Server Dienst
wasdb
Application Server
Administrationsdatenbank
wasalias
Aliasname für die Application Server
wasnode
DB2-Knoten für die Application Server
wasuser
Benutzer für den Zugriff des Application
Server auf die Administrationsdatenbank
im DB2-System
Tabelle 15: Weitere wichtige Namen
Seite: 95
In Tabelle 16 sind die von den wichtigsten Produkten verwendeten IP-Ports
aufgelistet. Diese IP-Ports müssen unbelegt sein, damit die reibungslose Funktion
der Produkte gewährleistet ist.
Belegte IP-Ports
Name der Applikation
Port
WebSphere Application Server
Beschreibung
900 Bootstrap port
9000 Location Service Daemon
9080 Default application server
DB2 Server und Client
523 DB2 Administration Server
50000 DB2 instance connection port
50001 DB2 instance interrupt port
50002 DB2 Control Server
IBM HTTP Server
80 Standard HTTP port
443 Standard HTTPS port
8008 IBM HTTP Server Administration port
Tabelle 16: Port-Belegungen
Zur Überprüfung welche IP-Ports bereits belegt sind, können sie folgende
Vorgangsweise wählen:
•
Öffnen Sie eine DOS-Box mit Start > Run > Command.
•
D:\netstat –an
•
Überprüfen Sie anhand der Liste ob sich unter den aufgelisteten IP-Ports keiner
der oben genannten Ports befindet (als Beispiel siehe Abbildung 34).
Abbildung 34: Beispiel für Port-Überprüfung
Seite: 96
Falls einer der in Tabelle 16 angegebenen Ports belegt sein sollte, müssen Sie den
Dienst bzw. die Applikation, die diesen Port belegt stoppen bzw. beenden.
Kapitel 4.4 beschreibt wie man Dienste unter Windows 2000 starten und stoppen
kann. Um die Installation der einzelnen Produkte durchführen zu können, ist es
notwendig mit einem Benutzer angemeldet zu sein, der Administrationsrechte hat.
Sollte das nicht der Fall sein, kann es sein, dass manche Produkte gar nicht oder
nicht vollständig installiert werden. Sie haben auch die Möglichkeit über die Datei
„D:\WINNT\SYSTEM32\DRIVERS\ETC\SERVICES“ die Port-Zuordnung der Dienste
zu verändern. Dieser Vorgang wird allerdings nicht empfohlen, da er detailliertes
Wissen über das Betriebssystem, die Funktionsweise von Diensten und dem TCP/IPProtokoll verlangt. Die Referenzinstallation wurde auf einer englischen Windows
2000
Version
durchgeführt,
dementsprechend
beziehen
Handlungsanweisungen und Screenshots auf diese Version.
sich
auch
alle
Seite: 97
4.2 Anlegen eines Windows 2000 Benutzers
Dieser Abschnitt beschreibt wie man unter Windows 2000 einen Benutzer anlegt. Es
soll hier nur demonstriert werden, wie die Vorgangsweise grundsätzlich abläuft.
Welche Benutzer sie konkret anlegen müssen, wird in der Installationsanleitung
beschrieben.
1. Starten sie die Systemsteuerung „Start > Settings > Control Panel“.
2. In Control Panel starten sie die Anwendung „Users and Password“.
Abbildung 35: Control Panel
3. Auf Add klicken.
(Hinweis: Wenn die Checkbox „Users must enter a username and a password to
use this computer„nicht angeklickt ist, können keinen neuen Benutzer angelegt
werden.)
Abbildung 36: Users and Passwords
Seite: 98
4. Geben Sie den neuen Benutzernamen, den vollen Namen und eine Beschreibung
an und klicken Sie auf „Next“.
Abbildung 37: Einen neuen Benutzer hinzufügen
5. Geben Sie das Passwort für den Benutzer ein und klicken Sie auf „Next“.
Abbildung 38: Passwort festlegen
6. Klicken Sie auf „Other/Administrators“ und klicken Sie auf „Finish“.
Abbildung 39: Gruppenzugehörigkeit festlegen
Seite: 99
7. Jetzt sollte der neue Benutzer zusammen mit den schon vorher bestehenden
Benutzern in der Liste aufscheinen.
8. Klicken Sie auf den Reiter „Advanced“ und auf den Button „Advanced“.
Abbildung 40: „Advanced“-Dialog in „Users and Passwords“
9. Klicken Sie auf den Ordner „Users“ und wählen Sie dann auf der rechten Seite
den gewünschten Benutzer aus, dessen Eigenschaften Sie ändern wollen.
Abbildung 41: "Local Users and Groups"-Dialog
10. Mit der rechten Maustaste klicken Sie auf den gewünschten Benutzer und wählen
„Properties“.
Seite: 100
11. Wählen Sie die Option „Password never expires“ an und klicken Sie auf „OK“.
Abbildung 42: „Benutzer Eigenschaften“-Dialog
Hinweis: Ohne Ihr Zutun ist in Windows 2000 die Paßwort-Option so eingestellt,
dass das Paßwort nach einiger Zeit (Default: 42 Tagen, einstellbar) abläuft d.h.
ungültig wird. Sobald ein Paßwort abläuft, muß man das Paßwort ändern. Wenn
man einen Dienst mit einem Benutzer zu starten versucht, dessen Paßwort
abgelaufen ist, schlägt dieser Versuch fehl. Der Grund ist, da ein Dienst nicht
direkt und visuell mit dem Benutzer interagieren kann, daß kein Dialog erscheinen
kann, der es dem Benutzer ermöglichen würde, das Paßwort zu ändern.
Deswegen sollte man einen Benutzer, der dafür bestimmt ist einen Dienst zu
starten, immer mit der Option „Password never expires“ anlegen.
Seite: 101
4.3 Benutzerrechte für den Benutzer vergeben
Dieser Abschnitt beschreibt wie man unter Windows 2000 Benutzerrechte vergeben
kann. Es soll hier nur demonstriert werden, wie die Vorgangsweise grundsätzlich
abläuft. Welche Rechte Sie welchem Benutzer zuweisen müssen, wird in der
Installationsanleitung beschrieben.
1. Starten sie die Systemsteuerung „Start > Settings > Control Panel“.
2. Rufen Sie die „Local Security Settings“ auf und wählen Sie den Ordner „Local
Policies/User Rights Assignment“ aus.
Abbildung 43: Local Security Settings
3. Markieren Sie das gesuchte Recht auf der Liste auf der rechten Seite und klicken
Sie darauf mit der rechten Maustaste.
4. Jetzt wählen Sie „Security“.
Seite: 102
5. Im jetzt erscheinenden Dialog klicken Sie auf „Add“.
Abbildung 44: Local Security Policy Setting
6. Jetzt wählen Sie aus der Liste den Benutzer aus, dem Sie das ausgewählte Recht
zuweisen wollen (z.B. wasadmin). Durch einen Doppelklick auf den
Benutzernamen wird der Benutzer in der unteren Liste eingetragen. Dieser
Vorgang wird mit einem Klick auf „OK“ abgeschlossen.
Abbildung 45: Benutzer auswählen
Seite: 103
7. Jetzt schliessen Sie diese Aktion mit einem Klick auf „OK“ ab.
Abbildung 46: Abschliessen der Local Security Policy Settings
8. Die Liste der Benutzerrechte sollte nach dieser Aktion so aussehen.
Abbildung 47: Übersicht über die Local Security Settings
Seite: 104
4.4 Dienste starten bzw. stoppen
Dieser Abschnitt beschreibt wie man unter Windows 2000 Dienste starten bzw.
stoppen kann.
1. Starten sie die Services mit „Start > Settings > Control Panel > Administrative
Tools > Services“.
2. Um einen Dienst zu starten, drücken Sie auf das Play-Symbol.
Abbildung 48: Starten eines Dienstes
3. Um einen Dienst zu stoppen drücken Sie auf das Stop-Symbol
Abbildung 49: Stoppen eines Dienstes
Seite: 105
4.5 Installationsschritte
Dieser Abschnitt beschreibt die einzelnen Installationsschritte für die in Tabelle 10
aufgelisteten Applikationen.
4.5.1
IBM HTTP Server
Als erste Applikation muß der IBM HTTP Server installiert werden, da der Application
Server auf den HTTP-Server aufsetzt.
4.5.1.1
Vorarbeiten
Um den IBM HTTP Server installieren und verwenden zu können, muss ein neuer
Benutzer angelegt werden.
1. Legen Sie einen neuen Windows 2000 Benutzer mit dem Namen „wasadmin“,
dem Passwort „wasadmin“ und folgenden Eigenschaften an:
•
Lokale Benutzer (kein Domänenbenutzer),
•
Benutzer der Gruppe „Administratoren“,
•
Mit den zusätzlichen Rechten: „log on as a service”, „act as a part of the
operating system”.
4.5.1.2
Installation
Zur Installation des IBM HTTP Servers sind folgende Schritte notwendig:
1. Melden Sie sich mit einem lokalen Benutzer an, der Administrationsrechte besitzt.
2. Starten Sie das Setup mit setup.exe im Verzeichnis HTTPD.
3. Wählen Sie als Sprache English und klicken Sie auf „OK“.
Abbildung 50: Sprachauswahldialog
4. Lesen Sie sich den Willkommenstext durch und klicken Sie auf „Next“.
Seite: 106
5. Lesen Sie sich den Text zum Software Lizenz Abkommen durch und klicken Sie
auf „Next“.
6. Im „Choose Destination Dialog“ legen Sie den Ziel-Installationspfad auf „D:\IBM
HTTP Server“ fest und klicken auf „Next“.
Abbildung 51: Installationspfadangabe
7. Im „Setup Type Dialog“ wählen Sie „Typical“ aus und klicken auf „Next“.
Abbildung 52: Setupart auswählen
8. Im „Select Program Folder Dialog“ klicken Sie auf „Next“.
Seite: 107
9. Im „Information for Service Setup“ geben Sie die folgenden Daten ein und klicken
auf „Install“:
- User ID: wasadmin
- Password: wasadmin
- Enter the password again for verification: wasadmin
Abbildung 53: Benutzerangaben für den Start des Services
Dieser Dialog legt fest mit welchem Benutzer das Service gestartet wird.
Die folgenden Eingaben gehen von der Annahme aus, dass Sie den Benutzer wie
im Kapitel 4.5.1.1 beschrieben angelegt haben.
10. Das Setup-Programm richtet jetzt den HTTP Server ein.
11. Sobald der „Setup Complete Dialog“ erscheint, klicken Sie auf „Yes, I will restart
my computer now“ und klicken auf „Finish“.
12. Wenn das System wieder gestartet ist, melden Sie sich wieder als ein Benutzer
mit Administrationsrechten z.B. „Administrator“ an.
Seite: 108
4.5.1.3
Bevor
Konfiguration
der
HTTP-Server
komplett
funktionsfähig
ist,
müssen
noch
einige
Einstellungen vorgenommen werden. Dazu muss zuerst ein Administrationsaccount
auf dem HTTP-Server eingerichtet werden und die Konfigurationsdatei httpd.conf
angepasst werden. Abschliessend wird noch der die Funktionsfähigkeit des HTTP
Servers überprüft.
Anlegen des Administrations Accounts:
1. Öffnen Sie eine DOS-Box mit Start > Run > Command.
2. Wechseln Sie in das Verzeichnis des HTTP-Servers („D:\IBM HTTP Server“)
Da unter Windows 2000 die langen Dateinamen angezeigt werden und nicht
mehr die kurzen wie unter Win98, man allerdings für sämtliche DOS-Befehle
immer noch die kurzen Namen braucht, ist folgende Vorgangsweise angeraten:
mit dem Befehl Dir /x wird eine Verzeichnisliste ausgegeben, die auch die
kurzen Namen enthält. Dann suchen Sie den kurzen Namen für das Verzeichnis
“D:\IBM HTTP Server“ aus der Liste heraus z.B. „IBMHTT~1“.
Mit dem Befehl „cd IBMHTT~1“ können Sie in das Zielverzeichnis wechseln.
Wenn Sie allerdings die DOS-Box statt mit „Command“ mit „cmd“ aufrufen,
können Sie auch direkt lange Dateinamen verwenden.
3. Im Zielverzeichnis rufen Sie den Befehl “htpasswd –m conf\admin.passwd
admin“ auf. Dieser Befehl legt einen neuen Administrationsbenutzer im HTTP
Server mit dem Namen „admin“ an. Prinzipiell können Sie hier jeden beliebigen
Namen verwenden, für die weiteren Ausführungen wird angenommen, dass Sie
„admin“ gewählt haben. Nach Aufruf des Befehls werden Sie nach einem
Passwort und der Bestätigung für dieses Passwort gefragt. Hier geben Sie in
beiden Fällen „admin“ ein.
Abbildung 54: Anlegen eines Administrationsbenutzers
Seite: 109
4. Jetzt können Sie die DOS-Box wieder schliessen.
Aktualisieren der httpd.conf
1. Öffnen Sie mit einem Texteditor die Konfigurationsdatei
„D:\IBM HTTP Server\conf\httpd.conf“.
2. Suchen Sie nach dem Eintrag „ServerName“ und ändern Sie ihn nötigenfalls auf
ihren Servernamen z.B. „stargazer“
Abbildung 55: Ausschnitt aus der httpd.conf
3. Speichern Sie die bearbeitete Datei.
4. Rebooten Sie das System.
4.5.1.4
Verifizierung
In diesem Abschnitt wird dokumentiert, wie man überprüfen kann ob die Installation
erfolgreich verlaufen ist.
Überprüfung, ob die Serverdienste gestartet sind
1. Starten Sie die Diensteverwaltung „Start > Settings > Control Panel >
Administrative Tools>Services“.
2. Überprüfen Sie ob in der Liste die Einträge
IBM HTTP Server
IBM HTTP Administration
jeweils mit dem Status „Started“, dem Startup Type „Automatic“ und mit dem Wert
„.\wasadmin“ im Feld „Log On As“ vorkommen.
Abbildung 56: Ausschnitt aus den Services
Seite: 110
Überprüfung ob Sie auf die Startseite des HTTP-Serves zugreifen können
1. Starten Sie einen Webbrowser und geben Sie die Adresse
http://<computername>/ z.B. http://stargazer/ ein.
Der Computername muss derselbe sein, wie der, den Sie in der „httpd.conf“Datei eingetragen haben. Danach sollten Sie folgendes Bild sehen:
Abbildung 57: Startseite des IBM HTTP-Servers
Falls Sie nicht auf diese Seite zugreifen können, kann das mehrere Gründen
haben:
- eine falsche Einstellung in der httpd.conf Datei,
- konkurrierende Einstellungen im Internet-Browser,
- nicht gestartete Server-Dienste (siehe Abbildung 56),
- ein nicht erfolgter Reboot,
- etc.
Seite: 111
4.5.2
IBM DB2 Universal Database Enterprise Edition 7.2
Dieser Abschnitt beschreibt die Installation der DB2 Datenbank.
4.5.2.1
Vorarbeiten
Um die IBM DB2 Universal Database Enterprise Edition installieren und verwenden
zu können, muss ein neuer Benutzer angelegt werden.
1. Legen Sie einen neuen Windows 2000 Benutzer mit dem Namen „db2admin“,
dem Passwort „db2admin“ und folgenden Eigenschaften an:
•
Lokale Benutzer (kein Domänenbenutzer).
•
Benutzer der Gruppe Administratoren.
Mit den zusätzlichen Rechten: „log on as a service”, „act as a part of the operating
system“, “create tokens“, “increase quotas“, “replace a process level token“.
4.5.2.2
Installation
Um die DB2 Universal Database Enterprise Edition zu installieren, sind folgende
Schritte notwendig:
1. Melden Sie sich als „db2admin“ am System an.
2. Starten Sie das Setup-Programm mit „setup.exe“.
3. Klicken Sie auf „Installation“.
Abbildung 58: DB2 Installationsdialog
Seite: 112
4. Im „Produkte“-Dialog wählen Sie nur die Option „DB2 Enterprise Extended
Edition“ an und klicken auf „Weiter“.
Abbildung 59: Auswahl der DB2 Enterprise Extended Edition
5. Im „Installationstyp“-Dialog wählen Sie die Option „Standard“ und klicken auf
„Weiter“.
Abbildung 60: Auswahl der Installationsart
6. Im „Zielspeicherpositions“-Dialog akzeptieren Sie den Standard-Installationspfad
und klicken auf „Weiter“.
Abbildung 61: Auswahl des Installationspfades
Seite: 113
7. In diesem Dialog geben Sie folgendes ein und klicken auf „Weiter“:
- Benutzername: db2admin
- Kennwort : db2admin
- Kennwort bestätigen: db2admin
und aktivieren auch die Checkbox „Dieselben Werte für die übrigen Einstellungen
der DB2 Benutzernamen und –Kennwörter verwenden“.
Abbildung 62: Benutzerangaben für die Steuerzentrale
8. Jetzt werden die notwendigen Dateien installiert. Die Frage nach der Installation
von OLAP beantworten Sie mit „OLAP Starter Kit nicht installieren“ und klicken
auf „Weiter“.
Abbildung 63: OLAP Starter Kit
9. Damit ist die Installation beendet und Sie müssen das System rebooten.
10. Danach melden Sie sich als ein Windows 2000 Benutzer mit
Administrationsrechten z.B. Administrator an.
Seite: 114
4.5.2.3
Verifizierung
Um die DB2-Installation zu überprüfen, führen Sie folgende Schritte durch:
1. Überprüfung der DB2 Release,
2. Überprüfung des Servicenamens,
3. Überprüfung der Konfiguration des Database Managers.
Überprüfung der DB2 Release
1. Starten sie die Befehlsfenster mit „Start > Programs > IBM DB2 >
Befehlsfenster“. Geben Sie den Befehl „c:\db2level“ ein.
Dieser Befehl sollte die folgende Ausgabe zurückliefern:
DB21085I Exemplar "DB2" verwendet DB2-Codefreigabe "SQL07021" mit
Aktualitäts-ID "03020105" und den Information-Tokens "DB2 v7.1.0.43",
"n010504" und "WR21254a".
Überprüfung des Servicenamens
Nach der Installation hat das Setup die Servicenamen der DB2-Dienste in die
„services“ Datei eingetragen. Es wäre grundsätzlich möglich an dieser Stelle den
Servicenamen zu verändern bzw. den Port zu verändern, doch würde dies einen
hohen Anpassungsaufwand in der Konfiguration nachsichziehen und die potentiellen
Fehlerquellen drastisch erhöhen. Daher ist diese Vorgangsweise nur anzuraten,
wenn die benötigten Ports schon belegt sind und das Anhalten der blockierenden
Dienste keine Option darstellt.
1. Öffnen Sie mit einem Texteditor die Datei „services“ im Verzeichnis
„D:\WinNT\system32\drivers\etc\“ und suchen Sie nach Einträgen, deren
Kommentare sich auf DB2 beziehen.
In dieser Datei sollten zwei Einträge vorhanden sein, die folgendermassen
aussehen sollten:
db2cDB2
db2iDB2
50000/tcp
50001/tcp
#connection port for the DB2 instance DB2
#interrupt port for the DB2 instance DB2
2. Der Eintrag, der später noch benötigt wird, ist in der 1. Spalte zu finden und ist
der mit der niedrigeren Portnummer(50000). In diesem Fall ist das der Eintrag
„db2cDB2“.
3. Schreiben Sie sich diesen Namen auf, denn er wird später noch benötigt.
Seite: 115
Überprüfung der Konfiguration des Database Managers
Befehlsfenster“.
2. Geben Sie den folgenden Befehl ein:
“db2 get dbm cfg |more“
3. Suchen Sie in der Liste nach dem Eintrag SVCENAME, der folgendermassen
aussehen sollte: “TCP/IP Service name (SVCENAME)=db2cDB2“
Abbildung 64: Überprüfen der Datenbank-Konfiguration 1
4. Wenn dieser Wert nicht angezeigt wird, geben Sie folgenden Befehl ein:
“db2 update dbm cfg using svcename <servicename>“, wobei
„<servicename>“ der Eintrag aus der „service“-Datei ist, den sie sich im vorigen
Abschnitt notiert haben. In diesem Falle „db2cDB2“.
Abbildung 65: Überprüfen der Datenbank-Konfiguration 2
5. Schließen Sie das Befehlsfenster.
Seite: 116
4.5.2.4
Konfiguration
Bevor die DB2-Datenbank vom Application Server verwendet werden kann, müssen
noch einige Aktivitäten durchgeführt werden:
1. Die Java-Version muss auf Version 2 gesetzt werden.
2. Der Kommunikationsmodus muss auf TCP/IP eingestellt werden.
3. Die WebSphere Application Server Administrationsdatenbank muss aufgesetzt
werden.
4. Ein WebSphere Application Server Benutzer muss angelegt werden.
Java-Version aktualisieren
1. Stoppen Sie das „DB2 JDBC Applet Server“ Service (Zum Starten und Stoppen
von Diensten siehe Kapitel 4.4).
2. Wechseln Sie in das Verzeichnis D:\Program Files\SQLLIB\Java12\ und
starten Sie das Programm „usejdbc2.bat“.
Abbildung 66: Java-Version aktualisieren
Die der Eingabe folgende Ausgabe sollte eine Liste der kopierten Dateien
ergeben. Falls das nicht der Fall sein sollte und die Meldung „access denied“
erscheint, stoppen Sie alle DB2-Dienste (DB2-DB2, DB2-DB2CTLSV, DB2DB2DAS00, DB2 JDBC Applet Server, DB2 JDBC Applet Server-Steuerzentrale,
DB2-Lizenzserver, DB2-Sicherheitsservice) und starten Sie das Programm
usejdbc2.bat erneut.
Seite: 117
3. Starten Sie das „DB2 JDBC Applet Server“ Service (Zum Starten und Stoppen
von Diensten siehe Kapitel 4.4).
Kontrollieren Sie die Datei „D:\Program Files\SQLLIB\Java12\inuse“.
Enthält diese Datei den Eintrag „JDBC 2.0“ so ist die Umstellung geglückt.
Falls die Datei diesen Eintrag nicht haben sollte, kontrollieren Sie ob Sie wirklich
alle DB2 Dienste (DB2-DB2, DB2-DB2CTLSV, DB2- DB2DAS00, DB2 JDBC
Applet Server, DB2 JDBC Applet Server-Steuerzentrale, DB2-Lizenzserver, DB2Sicherheitsservice) gestoppt haben und gehen Sie das Verfahren Schritt für
Schritt beginnend bei Punkt 1 noch einmal durch.
Kommunikationsmodus einstellen
Befehlsfenster“.
2. Mit dem Befehl „db2set DB2COMM“ können Sie überprüfen, welcher
Kommunikationsmodus im Moment eingestellt ist.
Abbildung 67: Kommunikationsmodus einstellen
3. Wenn der Kommunikationsmodus nicht auf „TCPIP“ gesetzt ist, können Sie mit
dem Befehl „db2set DB2COMM=TCPIP“ die Einstellung manuell setzen.
Seite: 118
WebSphere Application Server Administrationsdatenbank aufsetzen
Befehlsfenster“.
2. Erstellen Sie eine Datenbank mit dem Namen „wasdb“ und erhöhen Sie die
Heapsize für diese Datenbank.
“db2 create db wasdb
db2 update db cfg for wasdb using applheapsz 256“
Abbildung 68: Erstellen der WAS Administrationsdatenbank
3. Überprüfen Sie ob die Datenbank korrekt angelegt wurde:
“db2 list db directory“
Abbildung 69: Datenbank-Überprüfung
Seite: 119
4. Legen Sie einen neuen DB2 Knoten mit dem Namen „wasnode“ an:
“db2 catalog tcpip node wasnode remote STARGAZER server
db2cDB2“
Abbildung 70: DB2 Knoten erstellen
Es ist sehr wichtig, dass der Servername in Grossbuchstaben geschrieben wird.
Ist das nicht der Fall, stimmt die Zuordnung von Knoten zu Server nicht.
Der Servername ist der, den Sie bei der Überprüfung des Servernamens nach der
Installation des http Servers notiert haben z.B. STARGAZER.
5. Jetzt muss ein Aliasname („wasalias“) eingetragen werden, der die Datenbank mit
dem neu erstellten Knoten („wasnode“) verbindet:
“db2 catalog db wasdb as wasalias at node wasnode“
Abbildung 71: Aliasnamen eintragen
6. Überprüfen Sie, ob der Aliasname korrekt eingetragen wurde:
“db2 list db directory“
Abbildung 72: Überprüfung des Aliasnamen
Seite: 120
7. Überprüfen Sie, ob Sie sich mit einem Benutzer z.B. db2admin zur Datenbank
verbinden können:
“db2 connect to wasalias user db2admin using db2admin“
“db2 disconnect current“
Abbildung 73: Verbindungsaufbau zur Administrationsdatenbank
Seite: 121
WebSphere Application Server Benutzer anlegen
1. Legen Sie einen neuen Windows 2000 Benutzer namens „wasuser“ an.
2. Starten sie das Befehlsfenster mit „Start > Programs > IBM DB2 >
Befehlsfenster“.
3. Verbinden Sie sich als Administrator („db2admin“) zur Datenbank,vergeben Sie
die Zugangsberechtigungen für den neuen Benutzer und versuchen Sie sich als
Benutzer „wasuser“ an der Datenbank anzumelden:
“db2 connect to wasalias user db2admin using db2admin“
“db2 grant connect,createtab on database to user wasuser“
“db2 connect to wasalias user wasuser using wasuser“
Abbildung 74: Verbindungsaufbau zur Administrationsdatenbank
Hinweis: Sollte sie nach einigen Wochen den Application Server Dienst „IBM WS
AdminServer 4.0“ nicht mehr starten können, kontrollieren Sie, ob das Passwort
für den Benutzer „wasuser“ nicht abgelaufen ist. Dazu
starten sie das
Befehlsfenster mit „Start > Programs > IBM DB2 > Befehlsfenster“ und
versuchen sich mit dem Befehl „db2 connect to wasalias user wasuser
using
wasuser“
zur
„was“-Datenbank
zu
verbinden.
Wenn
dieser
Seite: 122
Verbindungsversuch mit der Fehlermeldung „Das Kennwort ist abgelaufen“
scheitert, müssen Sie das Passwort neu setzen. Dazu geben Sie im
Befehlsfenster den Befehl „db2 CONNECT TO wasalias USER wasuser
USING wasuser NEW wasuser CONFIRM wasuser“ ein. Danach können Sie
den Dienst „IBM WS AdminServer 4.0“ wieder starten.
Seite: 123
4.5.3
IBM DB2 Database Client
Der folgende Abschnitt beschreibt die Installation der DB2 Clientsoftware, die Sie bei
der Arbeit mit der DB2-Datenbank unterstützt.
4.5.3.1
Installation
Um den DB2 Datenbank Client zu installieren sind folgende Schritte notwendig:
1. Melden Sie sich als ein Benutzer mit Administrationsrechten z.B. Administrator
am System an.
2. Starten Sie das Setup-Programm mit setup.exe auf der DB2-Installationscd.
3. Im Installationsdialog klicken Sie auf „Install“.
4. Im Produktauswahldialog wählen Sie „DB2 Administrations Client“ und klicken Sie
auf „Weiter“.
Abbildung 75: DB2 Administrationsclient installieren
Seite: 124
5. Im „Installationsart-Auswahl“-Dialog wählen Sie „Standard“ und klicken auf
„Weiter“.
Abbildung 76: Installationsart auswählen
6. Im „Zielspeicherpositions“-Dialog klicken Sie auf „Weiter“.
Abbildung 77: Installationspfad auswählen
7. Im nächsten Dialog klicken Sie auf „Weiter“ und der Kopiervorgang beginnt.
8. Sobald die Installation beendet ist, erscheint ein Dialog, der die ersten Schritte mit
DB2 beschreibt. Hier klicken sie auf „Beenden“.
Seite: 125
4.5.4
IBM WebSphere Application Server
Der folgende Abschnitt beschreibt die Installation des WebSphere Application
Servers.
4.5.4.1
Vorarbeiten
Um die Installation durchführen zu können, müssen Sie das „IBM HTTP Server“
Service beenden. Das können Sie entweder mit dem Service-Programm („Start >
Settings > Control Panel > Administrative Tools>Services“) oder dem Befehl
net stop „IBM HTTP Server“ tun.
4.5.4.2
Installation
1. Melden Sie sich als ein Windows 2000 Benutzer mit Administrationsrechten z.B.
Administrator am System an.
2. Starten Sie das Setup-Programm mit „setup.exe“ auf der WebSphere
Application Server Setup-CD.
3. Im Sprachenauswahl-Dialog wählen Sie „Englisch“ und klicken Sie auf „Weiter“.
Sie können auch eine andere Sprache wählen. Alle weiteren Ausführungen
beziehen sich auf die englische Version.
4. Im nächsten Dialog klicken Sie auf „Weiter“.
5. Im Installationsart Dialog wählen Sie „Custom Installation“ und klicken Sie auf
„Next“.
Abbildung 78: Auswahl der Installations Optionen
Seite: 126
6. Im Dialog zur Auswahl der zu installierenden Komponenten wählen Sie alle außer
„IBM HTTP Server“ und „IBM Universal Database“ aus und klicken auf „Next“.
Abbildung 79: Komponenten-Auswahl
7. Als WebServer Plugin wählen Sie nur „IBM HTTP Server“ aus und klicken auf
„Next“.
Abbildung 80: Plugin-Auswahl
8. Um das Application Server Service zu starten, wird der Benutzer „wasadmin“
verwendet.
Abbildung 81: Benutzerangaben für das IBM HTTP Server Service
Seite: 127
9. Im “Zielort“-Dialog klicken Sie auf „Next“.
Abbildung 82: Installationspfad auswählen
10. Im „Datenbank-Optionen“-Dialog tragen Sie als Datenbanknamen den
Aliasnamen „wasalias“ und als Datenbankbenutzer „wasuser“ ein und klicken auf
„Next“.
Abbildung 83: Datenbankoptionen angeben
11. Im nächsten Dialog klicken Sie auf „Next“.
Seite: 128
12. Im Dialog, der die ausgewählten Installationsoptionen anzeigt, klicken Sie auf
Next und die Installation wird gestartet.
Abbildung 84: Installationsoptionen
13. Sobald die Installation beendet ist, beantworten Sie die Frage nach einem
sofortigen Reboot des Systems mit „Nein“ und klicken auf „OK“.
14. Benennen Sie die Datei „createwasdb.scr“ im Verzeichnis
„D:\WebSphere\AppServer\BIN“ in „createwasdb.bak“ um.
Dies verhindert, daß bei einer möglichen Neuinstallation des Application Servers
die bestehende Administrationsdatenbank („wasdb“) überschrieben wird und
dadurch alle in der Konfigurationsdatenbank gespeicherten Daten verloren
gehen.
15. Kontrollieren Sie ob im Log-File „wssetup.log“, das sich im Verzeichnis
„D:\WebSphere\AppServer\logs“ befindet, keine Fehler eingetragen wurden
(Total Errors: 0) und am Ende der Datei „Install Complete“ steht.
16. Rebooten Sie das System.
Seite: 129
4.5.4.3
Verifizierung
Um die Funktionsfähigkeit der Installation zu testen sind folgende Schritte
durchzuführen:
1. Kontrolle ob das Application Server Administrations Service vorhanden ist.
2. Kontrolle der admin.config Einstellungen.
3. Überprüfen der Änderungen der Webserverkonfiguration.
4. Starten des WebSphere Administrations Prozesses.
5. Starten des Default Servers.
6. Webserver Plugin-Einstellung aktualisieren.
Kontrolle des WAS Administrations Services
Überprüfen Sie ob das Service IBM WS AdminServer in den Services eingetragen
ist. Dazu starten Sie das Services-Programm mit „Start > Settings > Control Panel
> Administrative Tools > Services“ und kontrollieren ob in der Liste der Dienst “IBM
WS AdminServer 4.0“ enthalten ist.
Abbildung 85: Ausschnitt aus den Services
Seite: 130
Kontrolle der admin.config Einstellungen
Überprüfen
Sie
ob
u.a.
folgende
Einträge
in
der
Datei
„D:\websphere\appserver\bin\admin.config“ eingetragen sind:
1. Die Einstellungen(databasename,dbuser,dbpassword) der Repository-Datenbank
(wasalias) müssen denen ihrer Testumgebung entsprechen:
# Repository database settings
com.ibm.ejs.sm.adminServer.dbdataSourceClassName=COM.ibm.db2.jdbc.DB2Con
nectionPoolDataSource
com.ibm.ejs.sm.adminServer.dbserverName=
com.ibm.ejs.sm.adminServer.dbportNumber=
com.ibm.ejs.sm.adminServer.dbdatabaseName=wasalias
com.ibm.ejs.sm.adminServer.dbuser=wasuser
com.ibm.ejs.sm.adminServer.dbpassword=wasuser
com.ibm.ejs.sm.adminServer.dbdisable2Phase=true
Abbildung 86: admin.config Einstellungen
Wenn Sie sich bis jetzt an die Vorgaben gehalten haben, müssen in der Datei
admin.config folgende Einträge vorhanden sein:
•
Datenbankname (com.ibm.ejs.sm.adminServer.dbdatabaseName): „wasalias“
•
Datenbankbenutzer (com.ibm.ejs.sm.adminServer.dbuser): „wasuser“
•
Datenbankbenutzer-Passwort (com.ibm.ejs.sm.adminServer.dbpassword):
„wasuser“
2. Prüfen Sie ob das WAS Schema und die Initialkonfiguration beim ersten Start des
Application Servers in die Repository-Datenbank geschrieben werden. Das
Eintragen des WAS Schemas und der Initialkonfiguration beim ersten Start wird
von
den
Parametern
„com.ibm.ejs.sm.adminServer.createTables“
und
„install.initial.config“ gesteuert. Folgende Einträge müssen sich in der Datei
„D:\websphere\appserver\bin\admin.config“
com.ibm.ejs.sm.adminServer.createTables=true
finden:
Seite: 131
install.initial.config=true
Diese Einstellungen bewirken, dass beim erstmaligen Start des Application
Servers, die zur Administration des Application Servers notwendigen Tabellen
und Daten in die Administrationsdatenbank „wasdb“ geschreiben werden. Der
Application Server wird durch den Start des Dienstes „IBM WS AdminServer 4.0“
aufgerufen.
Webserverkonfiguration überprüfen
1. Prüfen Sie, ob folgende Einträge durch die WAS Installation in die „IBM HTTP
Server“-Konfigurationsdatei („D:\IBM HTTP Server\CONF\httpd.conf“)
eingetragen wurden:
LoadModule ibm_app_server_http_module
C:/WebSphere/AppServer/bin/mod_ibm_app_server_http.dll
WebSpherePluginConfig C:\WebSphere \AppServer \config \plugin-cfg.xml
2. Wenn diese Zeilen nicht vorhanden sind, fügen Sie sie manuell an.
Starten des WAS Administrations Prozesses
1. Starten Sie den WAS AdminServer mit „Start > Programs > IBM WebSphere >
Application Server V4.0 AE > Start Admin Server“.
2. Das Starten des Admin Servers war erfolgreich wenn:
o In der „Services“ Liste der Eintrag für den Dienst „IBM WS AdminServer 4.0“
auf „Started“ steht. Dazu starten Sie das Services-Programm mit „Start >
Settings > Control Panel > Administrative Tools > Services“ und
kontrollieren ob in der Liste der Dienst „IBM WS AdminServer 4.0“ mit dem
Eintrag „Started” in der Spalte „Status”enthalten ist.
o Kontrollieren Sie ob der folgende Eintrag in der Datei
„D:\WebSphere\AppServer\LOGS \tracefile“ vorhanden ist:
“[01.09.26 21:03:29:176 GMT+02:00] 305a5242 Server
A WSVR0023I: Server __adminServer bereit für e-business“
Starten des Default Servers
Seite: 132
Durch die Auswahl der Komponenten bei der Installation wurde ein „Default“
Application Server in die Administrationsdomäne eingetragen. Dieser Server und
seine Servlets können dazu benutzt werden, um festzustellen, ob die Installation
richtig funktioniert hat.
1. Starten Sie die Administrationskonsole mit „Start > Programs > IBM WebSphere
> Application Server V4.0 AE > Administrator’s Console“.
Bitte beachten Sie, daß dieser Vorgang einige Zeit in Anspruch nehmen kann.
2. Klicken Sie mit der rechten Maustaste auf den Eintrag „Default Server“ und
wählen Sie den Eintrag „Start“.
Abbildung 87: Starten des Default-Servers
3. Das Starten des Servers hat funktioniert, wenn Sie folgende Einträge im unteren
Fenster sehen:
Seite: 133
Transport http ist empfangsbereit an Port 9.080
Server default server bereit für e-business
Abbildung 88: Überprüfung des Startvorganges
4. Sie können die Konfiguration des Servers kontrollieren, indem Sie einige Servlets
ansprechen, die bereits im „default server“ installiert sind.
Dazu öffnen Sie einen Webbrowser und geben die URL
http://stargazer:9080/servlet/snoop bzw.
http://stargazer:9080/webapp/examples/showCfg ein.
Danach sollten Sie folgende Seiten zu sehen bekommen:
Seite: 134
Die explizite Portangabe „9080“ bewirkt, dass der embedded WebServer
angesprochen wird und nicht der stand-alone WebServer, dessen Installation im
Kapitel 4.5.1 auf Seite 105 beschrieben wurde.
Der embedded WebServer ist eine neue Kompontene im Rahmen des Websphere
Application Servers und stellt einen funktional eingeschränkten (z.B keine
Sicherheitsfeatures,
WebServer
dar.
kein
Dieser
Workload
Management,
WebServer
dient
schlechtere
ausschließlich
Performance)
zu
Test-
und
Entwicklungszwecken und kann den Stand-Alone-Webserver (z.B. IBM HTTP
Server) auch nur in diesem Bereich ersetzen bzw. ergänzen.
Der
Vorteil
des
embedded
WebServers
ist
,
dass
nicht
für
jede
Entwicklungsumgebung ein eigener , vollwertiger WebServer aufgesetzt und
administriert werden muß. Um die Servlets zu testen, kann in diesem Stadium auch
nur der embedded WebServer verwendet werden, da die Konfiguration des StandAlone WebServers (IBM HTTP Server) noch nicht aktualisert ist.
Seite: 135
Webserver Plugin-Einstellung aktualisieren
Bevor man auf den „default Server“ über den Stand-Alone WebServer zugreifen
kann,
muss
die
Konfigurationsdatei
„D:\WebSphere\AppServer\CONFIG\plugin-cfg.xml“ aktualisiert werden um
folgende Änderungen zu reflektieren:
1. Virtual Host Einstellungen.
2. Application Server Transportprotokolle.
3. Web Container URIs.
Die „plugin-cfg.xml“-Datei enthält die Konfigurationsdaten für das HTTP Transport
plugin. Für eine genaue Beschreibung der enthaltenen Konfigurationsdaten siehe
EnCl201, Seite 1061 ff.
Das plugin entscheidet an Hand der Konfigurationsdatei welche Requests an den
WebServer (embedded oder Stand alone) und welche an den Application Server
weitergeleitet werden sollen. Deswegen muß die Konfigurationsdatei nach jeder
Neuinstallation bzw. Änderung einer Kompontene (Servlet, Enterprise Java Beans,
JSPs, Applikationen, etc.) aktualisiert werden. Wenn die Aktualisierung nicht erfolgt,
kann es sein, daß die Ressource (Servlet, etc.) zwar richtig am Application Server
installiert ist, aber dem plugin auf Grund einer veralteten Konfiguration nicht bekannt
ist, dass die verlangte Resource bereits am Application Server existiert. Das
Endergebnis ist eine Fehlermeldung, da der WebServer den Request durch das
plugin erhält und versucht eine nicht existierende Resource anzusprechen.
Seite: 136
Um die plugin-Konfigurationsdatei zu aktualisieren, führen Sie folgende Anweisungen
durch:
2. Klicken Sie mit der rechten Maustaste auf den Knoten des Servers unter den der
default host eingetragen ist und wählen Sie „WebServer Plugin erneut
generieren“.
Abbildung 90: Neugenerierung des Plugins
Zum Lieferumfang des Application Servers gehört auch eine Applikation, mit dessen
Hilfe die Konfigurationsdatei auch ohne Administrator Konsole aktualisiert werden
kann. Um die
plugin-Konfigurationsdatei zu aktualisieren, müssen Sie das
Programm mit folgendem Aufruf starten:
“D:\WebSphere\AppServer\BIN\GenPlugInCfg.bat -wasnode STARGAZER“
Seite: 137
3. Überprüfen Sie die Datei „plugin-cfg.xml“, ob die entsprechenden
Änderungen für die Servlets des „default servers“ gemacht wurden (siehe
Abbildung 91):
Abbildung 91 : Plugin-cfg.xml
4. Starten Sie den Dienst „IBM HTTP Server“ (Zum Starten und Stoppen von
Diensten siehe Kapitel 4.4 auf Seite 104).
5. Um die Einstellungen in der plugin Konfigurationsdatei zu überprüfen, können Sie
via Stand-Alone WebServer analog zum obigen Test (Starten des default servers,
Punkt
4)
auf
Dazu
öffnen
die
Sie
Servlets
einen
des
„default
Webbrowser
und
servers“
geben
zugreifen.
die
URL
„http://stargazer/servlet/snoop“
bzw.
„http://stargazer/webapp/examples/showCfg“
ein.
Danach
sollten
Sie
die
folgenden
Seiten
zu
sehen
bekommen:
Seite: 138
4.5.5
IBM Visual Age for Java 4.0 Entry Edition
Der folgende Abschnitt beschreibt die Installation von VisualAge for Java.
1. Starten Sie das Installationsprogramm mit „Setup.exe“.
2. Klicken Sie auf „Install Products“ und „Install VisualAge for Java“.
Abbildung 93: Installation VisualAge
3. Klicken Sie auf „Next“.
4. Klicken Sie auf “I accept the terms in the license agreement“ und auf “Next“.
Abbildung 94: Lizenzabkommen
5. Klicken Sie auf „Complete“ und auf „Next“.
Seite: 139
6. Klicken Sie auf „Next“.
Abbildung 95: Installationsumfang wählen
7. Klicken Sie auf „Install“.
Abbildung 96: Installation starten
8. Jetzt beginnt die Installation von „VisualAge for Java“.
Dieser Vorgang kann einige Minuten dauern.
Seite: 140
4.5.6
IBM WebSphere Studio 4.0 Entry Edition
Der folgende Abschnitt beschreibt die Installation des WebSphere Studios.
1. Starten Sie das Installationsprogramm mit „Setup.exe“.
2. Klicken Sie auf „Weiter“.
3. Klicken Sie auf „Ja“.
Abbildung 97: Auswahl der zu installierenden Komponenten
8. Nach Beendigung der Installation rebooten Sie ihren Computer.
Seite: 141
4.5.7
XML-Tools
Der folgende Abschnitt beschreibt die Installation der XML-Tools XEENA, XMLViewer, XSLerator und LotusXSL.
4.5.7.1
XEENA
XEENA ist eine XML-Editor, der als Ausgangsbasis eine beliebige DTD akzeptiert.
Auf Basis der DTD ist die Erstellung neuer und die Bearbeitung und Veränderung
bestehender, von dieser DTD abgeleiteten, XML-Dokumente möglich.
1. Starten Sie das Installationsprogramm mit „Xeena-1.2EA.exe“.
2. Lesen Sie sich die Lizenzbestimmungen für Alphaworks durch und klicken Sie auf
„Yes“.
3. Lesen Sie sich die Lizenzbestimmungen für das „Swingpack“ durch und klicken
Sie auf „Yes“.
4. Lesen Sie sich die Lizenzbestimmungen für „Apaches Xerces“ Paket durch und
klicken Sie auf „Yes“.
5. Lesen Sie sich die Lizenzbestimmungen für „Apaches Xalan“ Paket durch und
klicken Sie auf „Yes“.
6. Bestätigen Sie den vorgeschlagenen Installationsort mit „Next“.
7. Wählen Sie die Option „Java2 (Runtime Environment or SDK) “ und klicken Sie
auf „Next“.
Abbildung 98: Auswahl der Java Umgebung
Seite: 142
8. Im „Java Installation“-Dialog müssen Sie das Verzeichnis angeben, in dem das
Java SDK installiert ist. In diesem Fall ist das im Verzeichnis
„D:\WebSphere\Appserver\java\“. Danach klicken Sie auf „Next“.
Hinweis : Das Installationsprogramm sucht die „Java.exe“, trotzdem muß man
das Verzeichnis über dem „BIN“-Verzeichnis angeben. Das Setup fügt das „BIN“
Verzeichnis, in dem sich die „Java.exe“ befindet, automatisch an den
eingegebenen Pfad an.
Abbildung 99: Java-Installationspfad auswählen
9. In Dialog „Proxy-Settings“ müssen Sie einen allenfalls vorhanden Proxy-Server
angeben. Dies ist allerdings nur notwendig, wenn Sie auf XML-Dokumente bzw.
DTDs
zugreifen
wollen,
die
auf
einem
anderen
WebServer
liegen.
In Normalfall lassen Sie das Feld „Proxy host“ leer und klicken auf „Next“.
Abbildung 100: Proxy-Host
10. Den nächsten Dialog bestätigen Sie mit „Next“ und die Installation wird
fertiggestellt.
Seite: 143
4.5.7.2
XML-Viewer
Zur Installation des XML-Viewers muss nur die Datei „xmlviewer.zip“ in ein
geeignetes
Verzeichnis
entpackt
werden.
Vorschlag: „D:\WebSphere\XMLTools“.
4.5.7.3
XSLerator
Zur Installation des XSLT-Skript-Generators muss nur die Datei
„XSLerator_Win.zip“ in ein geeignetes Verzeichnis entpackt werden. Vorschlag:
„D:\WebSphere\XMLTools“.
4.5.7.4
LotusXSL
Der folgende Abschnitt beschreibt die Installation des LotusXSL-Programmes.
1. Zur Installation des XSLT-Transformators muss die Datei „lotusxslj_2_0_1.zip“ in ein geeignetes Verzeichnis entpackt werden.
Vorschlag: „D:\WebSphere\XMLTools“.
2. Danach muss noch eine Umgebungsvariable namens JAVA_HOME angelegt
werden, die den Pfad zum Java SDK enthält. Dazu gehen Sie in die SystemUmgebung mit „Start > Settings > Control Panel > System“.
3. Im Reiter „Advanced“ klicken Sie auf „Environment Variables“.
4. Dann klicken im Bereich „System variables“ auf „New“ und geben als Name der
Variable „JAVA_HOME“ ein und als Wert „D:\WebSphere\AppServer\java“
ein. Diese Variable enthält den Pfad zum Java SDK.
Abbildung 101: Umgebungsvariable erstellen
Seite: 144
5 Beispiele
Um die im „WebSphere Application“ Server eingesetzten Technologien besser
verstehen zu können, hat es sich als sehr hilfreich erwiesen, praktische Beispiele zu
benützen. Die in Kapitel 3.2.1 bis 3.2.11 vorgestellten Technologien werden durch
diese Beispiele abgedeckt. Die folgenden Kapiteln enthalten jeweils eine Anleitung
zur Installation und Konfiguration und eine Kurzbeschreibung über den Aufbau und
Ablauf des Beispiels. Diese Beispiele sind Teil des Lieferumfanges des Application
Servers und werden bei der Installation automatisch angelegt.
Voraussetzung für sämtliche Beispiele ist die vollständige Installation und
funktionierende Konfiguration, wie in Kapitel 4 beschrieben, der notwendigen
Softwarepakete. Kapitel 5.3 zeigt exemplarisch, wie eine selbsterstellte WebApplikation verpackt und im Application Server installiert wird.
5.1 Installation und Konfiguration
Die notwendigen Dateien (EAR-Dateien) für diese Beispiele werden von der
Installationsroutine des „WebSphere Application Servers“ in das Verzeichnis
„D:\WebSphere\AppServer\installableApps“
kopiert
installiert.
Beispiele
Nach
der
Installation
werden
die
und
im
automatisch
Verzeichnis
„D:\WebSphere\AppServer\installedApps“ abgelegt.
Dennoch verbleiben einige Dinge zu tun, um die Beispiele lauffähig zu machen.
1. Öffnen Sie einen Webbrowser und geben Sie folgende Adresse ein:
“http://<computername>/Wssamples/index.html“
Wobei „<computername>“ für den Namen ihres Computers steht, den Sie auch in
der Datei „D:\IBM HTTP Server\CONF\httpd.conf“ eingetragen haben.
Z.B.: „http://stargazer/WSsamples/index.html“
Falls Sie nicht auf die Seite zugreifen können, kontrollieren Sie die Schreibweise
der URL auf Groß/Kleinschreibung.
2. Klicken Sie auf „Getting Started“.
Seite: 145
3. Klicken Sie auf „Complete the Database Configuration Steps“.
Abbildung 102: Datenbank-Einstellungen für die Beispiele
4. Klicken Sie auf „Start DB2 Database Configuration“.
5. Legen Sie einen neuen Windows 2000 Benutzer namens „wsdemo“ mit dem
Passwort „wsdemo1“ mit den folgenden Einstellungen an:
a. „Password never expires“ muss aktiviert sein.
b. „User must change password at next LogOn“ muss deaktiviert sein.
6. Klicken Sie auf „Step2“.
7. Überprüfen Sie, ob das „WebSphere Application Server Service“ gestartet ist.
Dazu starten Sie das Services-Programm mit „Start > Settings > Control Panel
> Administrative Tools > Services“ und kontrollieren ob in der Liste der Dienst
„IBM WS AdminServer 4.0“ mit dem Eintrag „Started” in der Spalte
„Status”enthalten ist.
Seite: 146
8. Starten Sie das Programm, um die Beispielsdatenbank anzulegen:
“D:\Websphere\Appserver\Bin\ImportSamplesDB2.bat db2admin db2admin“
Abbildung 103: Anlegen der Samples-Datenbank
„db2admin“ ist der Benutzer der im Kapitel 4.5.2 als Datenbank-Administrator
angelegt wurde. „db2admin“ ist das dazugehörige Passwort.
9. Restarten Sie den default Server mit Hilfe der Administrations Konsole:
a. Starten Sie die Administrationskonsole mit „Start > Programs > IBM
WebSphere > Application Server V4.0 AE > Administrator’s Console“.
b. Klicken Sie mit der rechten Maustaste auf den Eintrag „Default Server“ und
wählen Sie den Eintrag „Neustart“.
Abbildung 104: Starten des Default Servers
Seite: 147
10. Klicken Sie in der Administrationskonsole auf „Enterprise Anwendungen“ und
öffnen Sie den Ordner. Dann klicken Sie auf „Refresh“.
Jetzt sollten Sie den Eintrag „stargazer/Samples“ sehen.
Abbildung 105: Kontrolle der Installation
11. Klicken Sie im Webbrowser auf „Step3“.
12. Klicken Sie im Webbrowser auf „Submit“. Wenn jetzt keine Fehlermeldung
erscheint, so sind die Beispiele korrekt eingerichtet worden.
Falls doch eine Fehlermeldung erscheint, können folgende Umstände daran
Schuld haben:
a. Sie haben den Benutzer „wsdemo“ falsch oder mit einem falschen Passwort
eingerichtet.
b. Das Einrichten der Samples-Datenbank hat nicht richtig funktioniert. In diesem
Fall kontrollieren Sie ob Sie unter Punkt 8 den richtigen Benutzer angegeben
haben.
Seite: 148
Einrichten des Online-Shop Beispieles
1. Starten Sie einen Webbrowser und geben Sie die Adresse
“http://<computername>/WSsamples/index.html“ ein.
Wobei „<computername>“ für den Namen ihres Computers steht, den Sie auch in
der Datei „D:\IBM HTTP Server\conf\httpd.conf“ eingetragen haben.
Z.B.: http://stargazer/WSsamples/index.html
2. Klicken Sie auf Petstore.ear.
Abbildung 106: Einrichten des Onlineshops
3. Klicken Sie auf „DB2 Configuration Instructions“.
4. Erstellen Sie eine Sicherungskopie der Datei
“D:\WebSphere\AppServer\installableApps\petstore\petstore.ear“
z.B.: petstore2.ear
5. Starten Sie die Applikation „D:\WebSphere\AppServer\bin\assembly.bat“
Seite: 149
6. Wechseln Sie in den Reiter „Vorhanden“, klicken Sie auf „Durchsuchen“ und
wählen die Sicherungskopie, die Sie im Schritt 4 angelegt haben. In diesem Fall
ist das die Datei „petstore2.ear“.
Abbildung 107: Anpassen der Applikation
7. Klicken Sie auf „OK“.
8. Wechseln Sie in den Zweig „petstore > EJB Modules > Customer Component
> Entity Beans > TheOrder > Umgebungseinträge“.
Abbildung 108: Anpassen der Umgebungseinträge
Seite: 150
9. Ändern Sie den Wert von
„com.ibm.j2ee.blueprints.customer.order.dao.OrderDAOIDB“ auf
„com.ibm.j2ee.blueprints.customer.order.dao.OrderDAODB2“
10. Klicken Sie auf „Anwenden“.
11. Klicken Sie „Datei > Speichern“ und beenden Sie das Programm.
12. Kopieren Sie die Datei
„D:\WebSphere\AppServer\installableApps\petstore\ps_db2.sql“
in das Verzeichnis „D:\Program Files\SQLLIB\bin“.
Befehlsfenster“.
14. Geben Sie folgende Befehle ein:
a. db2 create database PETSDB
b. db2 connect to PETSDB user db2admin using db2admin
c. db2 –f ps_db2.sql
d. db2 terminate
Abbildung 109: Datenbank anlegen
15. Starten Sie den Application Server mit „Start > Programs > IBM WebSphere >
Application Server V4.0 AE > Start Admin Server“.
Seite: 151
17. Nun werden die notwendigen Resourcen mit der Applikation verbunden.
Dazu wechseln Sie in den Zweig „Resourcen > JDBC-Provider > Sample DB
Driver > Datenquellen“. Klicken Sie mit der rechten Maustaste auf den Eintrag
„Datenquellen“ und wählen Sie den Eintrag „Neu“.
Abbildung 110: Datenquelle anlegen
Seite: 152
18. In den Eingabefeldern für die neue Datenquelle geben Sie folgende Daten ein:
a. Name: PetStoreDatasource
b. JNDI-Name: ps/PetStoreDatasource
c. Datenbankname: PETSDB
d. Benutzer-ID: db2admin
e. Kennwort: db2admin
f. Kennwort bestätigen: db2admin
Abbildung 111: Eigenschaften der Datenquelle
19. Es ist auch notwendig eine JavaMail-Session anzulegen. Dazu wechseln Sie in
den Zweig „Resourcen > JavaMail-Sitzung“. Klicken Sie mit der rechten
Maustaste auf den Eintrag „JavaMail-Sitzung“ und wählen Sie den Eintrag „Neu“.
Seite: 153
20. In den Eingabefeldern für die neue Mail Sitzung geben Sie folgende Daten ein:
a. Name: PetStoreMail
b. JNDI-Name: ps/PetStoreMailSession
c. Protokoll: smtp
d. Server: Geben Sie hier den Namen ihres Mailservers ein, z.B.:
e. email.aon.at
f. Benutzername: Ihr Mail Benutzernamen
g. Kennwort: Ihr Mail Benutzerpasswort
h. Kennwort bestätigen: Ihr Mail Benutzerpasswort
Hinweis: Falls Sie keinen Zugang zu einem Mailserver haben oder die
notwendigen Daten nicht wissen, können Sie die notwendigen Felder mit
Beispielswerten füllen, um das Einrichten der Mailsession abschließen zu
können. Um das Beispiel „Petshop“ nutzen zu können, ist es unbedingt
notwendig, dass eine MailSession-Resource vorhanden ist.
Abbildung 112: Eigenschaften der Mail-Session
21. Damit WARs und EJB JARs Klassen auch in anderen Applikationen finden
können, muss die Modulsichtbarkeit auf Anwendungsebene umgestellt werden.
Seite: 154
Wechseln Sie in den Zweig „<Knoten><stargazer>Anwendungsserver>Default
server“ und klicken mit der rechten Maustaste auf den Eintrag „default server“.
22. Klicken Sie auf „Merkmale“ und ändern Sie im Feld Modulsichtbarkeit den Eintrag
auf „Anwendung“ und klicken Sie auf „OK“.
Abbildung 113: Modulsichtbarkeit ändern
23. Nun muss die Applikation installiert werden. Dazu klicken Sie mit der rechten
Maustaste auf „Enterprise Anwendung“ und wählen „Enterprise Anwendung
installieren“ aus.
Abbildung 114: Enterprise-Anwendung installieren
Seite: 155
24. Im nächsten Dialog wählen Sie die Sicherungsdatei (D:\WebSphere\
AppServer\installableApps\petstore\petstore.ear) aus (siehe
Einrichten des Online-Shop Beispieles, Punkt 4). Als Anwendungsnamen geben
Sie „petstore“ ein. Im Feld in dem der Knoten festgelegt wird auf dem die
Anwendung gesucht werden soll müssen Sie Ihren Computernamen auswählen.
Danach klicken Sie auf „Weiter“.
Abbildung 115: Anwendung installieren
25. Bei allen weiteren Dialogen können Sie die „default“ Einstellung übernehmen und
auf „Weiter“ drücken. Wenn alle Einstellungen richtig gemacht wurden erscheint
am Ende der Installation folgende Meldung:
Abbildung 116: Verteilung der Applikation
Auf diese Fragen antworten Sie mit „Nein“. Danach erscheint die Bestätigung
dass die Applikation erfolgreich eingerichtet wurde.
Abbildung 117: Bestätigung der Installation
Seite: 156
Hinweis: Sollten Sie zwischendurch Fehlermeldung bekommen, dass eine der
Ressourcen (Datenquellen, JavaMail) nicht gefunden werden können, so
kontrollieren Sie ob Sie wirklich alle notwendigen Ressourcen (Datenquellen,
JavaMail) angelegt haben und ob die Schreibweise der Ressourcen korrekt ist.
26. Aktualisieren Sie die Ansicht der Administrations Konsole.
27. Klicken Sie mit der rechten Maustaste auf den Knoten des Servers unter dem der
„default host“ eingetragen ist und wählen Sie „WebServer Plugin erneut
generieren“.
28. Restarten Sie den Server, indem Sie mit der rechten Maustaste auf den Eintrag
„Default Server“ klicken und den Eintrag „Neustart“ auswählen.
29. Danach starten Sie erneut die Administrations Konsole.
30. Öffnen Sie den Eintrag „Enterprise-Anwendungen“, klicken mit der rechten
Maustaste auf den Eintrag „petstore“ und wählen „Starten“ aus.
Abbildung 118: Starten der Anwendung
Seite: 157
31. Um den „PetStore“ benutzen zu können, öffnen Sie einen Webbrowser und
geben Sie die Adresse „http://stargazer/estore/“ ein. Von dort gelangen Sie direkt
zum „OnlineShop“.
Abbildung 119: Verifizierung der Installation
Hinweis: Falls Sie eine Fehlermeldung beim Zugriff auf den „Onlineshop“
bekommen, überprüfen Sie ob die „petstore“-Anwendung in der
Administrationskonsole gestartet wurde bzw. ob der Application Server gestartet
ist.
Seite: 158
5.2 Beschreibung
Tabelle 17 listet die beiliegenden Beispiele auf, die in einem sogenannten Enterprise
Archiv („Samples.ear“) zusammengefasst sind. In diesem Archiv sind wiederum die
einzelnen Beispiel-Applikationen enthalten, deren Bestandteile zum Teil in Web
Archiven (WAR) und zum Teil in Java Archiven (JAR) zusammengefasst sind.
Inhalt der Samples.ear
Samples.war
•
BeanScripting
•
StockQuote
•
XML
•
Hello EJB
•
Increment EJB
•
Account EJB
Transfer EJB servlets and JSPs
YourCo.war
•
YourCo Beispiel-Servlets und JSPs
Theme.war
•
Bilder und Stylesheets, die von den Beispielen benutzt werden.
AccountAndTransferEJBean.jar
•
Enthält ein CMP Entity EJB, ein BMP Entity EJB und ein stateless session
EJB.
HelloEJBean.jar
•
Enthält ein stateless session EJB.
IncrementEJBean.jar
•
Enthält ein CMP Entity EJB.
TimeoutEJBean.jar
•
Enthält drei CMP Entity EJBs und ein stateless session EJB.
Tabelle 17: Auflistung der installierten Beispiele
Seite: 159
Tabelle 18 listet die Komponenten auf, die in den einzelnen Beispielen enthalten
sind.
Übersicht über die von IBM WebSphere installierten Beispiele
Name
JSP
Bean Scripting
X
Stock Quote
X
XML
Servlet
EJB
CMP
BMP
EJB
EJB
X
JDBC
Database
X
X
EJB Samples
Hello
X
Increment
X
X
X
X
X
X
Account
X
X
X
X
X
Transfer
X
X
X
X
X
Application Client
X
PetStore
X
X
X
X
X
YourCo
X
X
X
X
X
Customization
X
X
X
X
Form
X
Job Listing
X
X
X
X
Login/Logout
X
X
X
X
News
X
X
Page Hit Counter
X
X
X
Poll
X
X
X
X
Quote
X
Scheduler
X
X
X
X
Stock
X
X
Survey
X
X
X
X
Timeout
X
X
Whitepages
X
X
X
X
X
X
X
Tabelle 18: Inhalt der installierten Beispiele
Im Folgenden wird dargestellt welche Funktionen die einzelnen Beispiele
demonstrieren. Um die Beispiele sich ansehen zu können, starten Sie einen
Webbrowser
und
geben
die
Adresse
Seite: 160
„http://stargazer/WSsamples/index.html“ ein. Von dieser Seite können Sie
zu jedem beliebigen Beispiel navigieren. Damit die Beispiele funktionieren, muß der
WebSphere Application Server („IBM WS AdminServer 4.0“-Dienst) und die DB2Datenbank („DB2-DB2“-Dienst) gestartet sein. Alle Beispiele, außer „Pet Store“, sind
auch
mit
ihrem
Sourcecode
verfügbar
und
sind
im
Verzeichnis
„D:\WebSphere\AppServer\installedApps“ abgelegt. Die Beispiele sind auf
verschiedene
Archive
(sampleApp.ear,
Sourcecodes
(*.Java-Dateien)
der
Samples.ear)
Servlets
und
aufgeteilt.
JavaBeans
sind
Die
in
Unterverzeichnissen im Verzeichnis „WEB-INF\classes“ unter dem jeweiligen
WebArchiv (.war-Verzeichnis) abgelegt. Das WebArchiv ist wiederum unter einem
Enterprise Application Archiv (.ear-Verzeichnis) abgespeichert. Z.B. liegt der
Sourcecode für das Servlet aus dem Beispiel (YourCo/Poll) im Verzeichnis
„D:\WebSphere\AppServer\installedApps\Samples.ear\YourCo.war\WE
B-INF\classes\WebSphereSamples\YourCo\Poll“.
5.2.1
YourCo
Das Beispiel „YourCo“ demonstriert anhand eines Intranets die vielfältigen
Anwendungsmöglichkeiten von EJBs, JSPs, Servlets, JavaBeans in Verbindung mit
einer Datenbank-Anbindungen.
Tabelle 19 dokumentiert welche Funktionen das
Intranets bereitstellt.
Funktionen des YourCo Intranets
Name
Customization
Funktion
Dieses Beispiel zeigt, wie man das Web-Angebot an den
Benutzer anpassen kann. Dazu wählt der Benutzer aus mehreren
Themen eines oder mehrere aus. Nach dieser Auswahl wird eine
Liste von Links ausgegeben, die auf Webseiten verweisen, die für
den Benutzer von Interesse sind. Die Steuerung übernehmen
Servlets. Dabei wird u.a. überprüft, ob der Benutzer eingeloggt ist
und ob eventuell bereits vorhandene, eingegebene Präferenzen
auf die Ausgabe angewendet werden sollen. Die angegebenen
Präferenzen werden gespeichert.
Seite: 161
Form
Dieses Beispiel demonstriert das Zusammenspiel zwischen
HTML, Servlet und JSP. Sie können im HTML-Formular Daten
eingeben, diese werden an ein Servlet geschickt und in einem
JSP wieder ausgegeben.
Als Datentransportmittel zwischen Servlet und JSP wird ein
JavaBean verwendet.
Job Listing
Diese Funktion erlaubt das Suchen nach Job Möglichkeiten in der
Beispielfirma.
Man
kann
außerdem
nach
Position
und
Qualifikationsniveau abgestuft suchen. Wenn man als ein
bestimmter Benutzer(„sally“) eingeloggt ist, kann man weitere
Jobs in der Datenbank anlegen.
Mit Hilfe von Servlets werden die Anfragen an die Datenbank, das
Einfügen neuer Jobs und die Customization bewerkstelligt.
Login/Logout
Dieses Beispiel erlaubt das Ein- bzw. Ausloggen aus dem
Employee Center. Sobald sich der Benutzer angemeldet hat,
werden die persönlichen Daten des eingeloggten Benutzers in
einem Session Bean gespeichert, um Sie zu einem späteren
Zeitpunkt auslesen zu können.Gleichzeitig wird dieses Bean auch
von anderen Beispielen genutzt, um festzustellen ob sich der
Benutzer eingeloggt hat.
News
Dieses Beispiel zeigt, wie man Daten abhängig von der Tageszeit
präsentieren könnte. Einstiegspunkt ist ein Servlet, das abhängig
von der Tageszeit den Benutzer zu unterschiedlichen JSPs
weiterleitet, die jeweils andere Nachrichten bereitstellen.
Page Hit Counter Dieses Beispiel zeigt die Implementierung eines Web-Seiten bzw.
WebSite Hit Counters. Die Basis bildet ein JavaBean, das zwei
Methoden hat. Eine zum Abfragen und die Andere zum Erhöhen
des Hit Counters. Mit diesem Beispiel kann man auch die Hits für
einzelne Seiten getrennt von der WebSite zählen lassen, da für
jede einzelne Seite ein eigenes Java Bean erzeugt wird. Die ID
des jeweiligen Java Beans wird in der Datenbank abgelegt.
Der jeweilige aktuellen Stand der Hits für die WebSite als Ganzes
oder die einzelne Seite wird ebenfalls in der Datenbank abgelegt.
Seite: 162
Poll
Dieses Beispiel ermöglicht eine minimale Ja/Nein-Umfrage zu
bewältigen. Ein JavaBean mit einem temporären Cache wird dazu
verwendet, um die Entscheidung des Benutzers zu speichern.
Die Speicherung in die Datenbank und die Abfragen aus der
Datenbank übernimmt ein Servlet.
Die Interaktion mit dem Benutzer wird über JSPs abgewickelt.
Quote
Mit diesem Beispiel können zufällig Aussprüche aus einer
Textdatei ausgelesen und ausgegeben werden. Dazu wird ein
JavaBean verwendet, das die Daten aus einer Datei ausliest und
an ein JSP liefert.
Scheduler
Mit dieser Funktion kann man eine einfache Raumverwaltung
implementieren. Es gibt die Möglichkeit, belegte bzw. freie Räume
zu suchen und Räume zu reservieren. Hinter den Abfragen nach
freien bzw. belegten Räumen und der Reservierung von Räumen
stehen JavaBeans. Die Interaktion und Darstellung der Daten
übernehmen JSPs.
Stock
Dieses Beispiel stellt den „aktuellen“ (zufällig generierten)
Tageskurs der YourCo-Aktie dar. Die Kalkulation des neuen
Kurses und Übergabe der Daten an das ausgebende JSP
übernimmt ein JavaBean.
Survey
Dieses Beispiel zeigt, wie man eine Umfrage online durchführen
und die Ergebnisse in der Datenbank speichern könnte.
Ein Servlet übernimmt das Eintragen der Daten in die Datenbank,
ein anderes holt die Daten bei Bedarf wieder aus der Datenbank.
Die Datenübertragung zu den JSPs übernehmen JavaBeans.
Die Darstellung der Daten und die Interaktion mit dem Benutzer
läuft über JSPs.
Seite: 163
Timeout
Dieses Beispiel zeigt an Hand einer Urlaubsverwaltung die
Verwendung von EJBs. Dabei kann der Benutzer Tage zwischen
den „Banken“ Persönlich, Krankenstand und Urlaub transferieren.
Diese Änderungen werden über ein CMP EJB mitgeloggt und in
einer Tabelle abgelegt. Ein Stateless Session Bean wird
verwendet, um alle notwendigen Daten wie transferierte Daten,
den Tagessaldo usw. zusammenzustellen. Drei CMP EJBs
übernehmen das Generieren von Auditnummern, den Zugriff auf
die Transfergeschichte und den Zugriff auf die „Bankzahlen“.
Ein Servlet übernimmt die Steuerung der Funktionalität dieses
Beispieles und bedient sich der oben genannten EJBs.
Whitepages
Mit diesem Beispiel kann man sich alle Mitarbeiter der YourCo
nach unterschiedlichen Kriterien ausgeben lassen. Für jede Art
von Suche wird ein bestimmtes Servlet verwendet. Den
Datentransfer
zwischen
JSPs
und
Servlets
übernehmen
JavaBeans.
Tabelle 19: Beschreibung der Funktionen des YourCo Beispieles
5.2.2
Bean Scripting
Dieses Beispiel zeigt an Hand eines JSPs die Verwendung des BSF (siehe Kapitel
3.2.2).
Beide JSPs zeigen eine Umrechnungstabelle von Fahrenheit in Grad Celsius an.
Die eine JSP verwendet die Standard-Sprache Java für Skripts in JSPs, um die
Umrechnung zu bewerkstelligen. Die zweite JSP demonstriert mittels des JSPMarken <jsp:directive.page language="javascript"/> die Verwendung
von JavaScript als Skriptsprache.
5.2.3
StockQuote
Das StockQuote-Beispiel demonstriert, wie ein und dieselbe Applikation auf
verschiedene Clients (Webbrowser, Sprache, Handy) reagieren und den Output
(HTML, VXML, WML) auf den entsprechenden Client anpassen kann.
Um das Beispiel zu starten, fragt man mit einem Client bei einem Servlet an, das
aufgrund der Eigenschaften des Clients erkennt, welche Form der Kommunikation
(HTML, VXML, WML) aktiv ist.
Seite: 164
Über eine entsprechende JSP kann man ein Aktienkürzels eingeben.
Diese Eingabe wird an das Servlet übergeben, das die weitere Verarbeitung
übernimmt. Je nach anfragendem Client leitet das Servlet den Output auf eine JSP,
das die Antwort für den Client passend formatiert (HTML, VXML, WML) ausgibt.
Damit dieses Beispiel funktioniert muss der Computer einen Internetzugang haben,
um
den
Aktienkurs
von
der
Adresse
„http://finance.yahoo.com/d/quotes.csv“ abfragen zu können.
5.2.4
XML
Eine Verwendungsmöglichkeit von XSLT wird im Beispiel XML gezeigt. Dabei wird
ein XML-Dokument mittels zweier unterschiedlicher XSL-Dateien, unterschiedlich
formatiert, in HTML dargestellt. Es besteht auch die Möglichkeit ein eigenes XMLDokument als Basis und eigene XSL-Stylesheets zu verwenden. Ein Servlet
übernimmt die Anwendung des jeweiligen XSL-Stylesheets auf das XML-Dokument.
5.2.5
HelloEJB
Das HelloEJB-Beispiel enthält ein Stateless Session EJB das einfach nur den Text
„Hello from Hello EJB Sample!“ über eine JSP ausgibt.
5.2.6
Increment EJB
Dieses Beispiel verwendet ein Servlet das über ein CMP EJB einen Zähler bei
Knopfdruck immer um eins erhöht. Das EJB speichert den jeweiligen Wert in der
Datenbank und lädt ihn bei Bedarf wieder. Die Ausgabe erfolgt wieder über das
Servlet.
Seite: 165
5.2.7
Account EJB und Transfer EJB
Diese Beispiele erlauben dem Benutzer das Anlegen eines Bankkontos, das
Durchführen von Überweisung zwischen den angelegten Konten und das Abrufen
von Kontoständen.
Der Benutzer hat die Wahl, ein Konto über ein HTML-Formular oder über ein JSPFormular anzulegen. Bei beiden Varianten übernimmt letztlich ein Servlet die
Kommunikation mit den EJBs. Welche Art von EJB verwendet wird, kann auch vom
Benutzer festgelegt werden. Zur Wahl stehen die Varianten CMP EJB bzw. BMP
EJB. Für jeden angelegten Account wird eine Instanz des entsprechenden EJBs
angelegt, das sich wiederum mit der Datenbank synchronisiert, um den aktuellen
Kontostand zu speichern.
5.2.8
Application Client
Dieses Beispiel demonstriert den Zugriff einer J2EE Client Application auf ein
Stateless Session EJB. Das EJB gibt nur den Text „Message from Hello EJB:
<b>Hello</b> from Hello EJB Sample!“ zurück. Dieser Text wird dann
ausgegeben.
Das
Beispiel
wird
mit
dem
Befehl
„D:\>launchclient
D:\WebSphere\AppServer\installableApps\samples.ear“
aufgerufen.
Abbildung 120: Starten der J2EE Client Applikation
Hinweis: Sollte der Aufruf der Applikation nicht gelingen, kontrollieren Sie ob die
Umgebungsvariable Path den Pfad „D:\WebSphere\Appserver\Bin“ enthält.
Seite: 166
Wenn eine Fehlermeldung bei der Initialisierung der Umgebung des J2EE Application
Clients nach dem Start der Applikation erscheint, prüfen Sie ob die Umgebungsvariable CLASSPATH den Pfad „D:\WebSphere\AppServer\lib“ enthält.
5.2.9
Pet Store
Der „Pet Store“ stellt ein Beispiel für einen kompletten Online-Shop dar, über den
man Haustiere bestellen kann. Aufgrund des grossen Umfangs wird dieser Shop hier
nur der Vollständigkeit halber angegeben und nicht im Detail beschrieben. Um den
„Pet Store“ aufzurufen, starten Sie einen Webbrowser und geben die Adresse
„http://stargazer/estore/“ ein. Von dieser Seite kommen Sie mit dem Link
„Enter the Store“ direkt zum „Pet Store“. Tabelle 20 gibt Auskunft darüber,
welche Funktionen der „Pet Store“ zur Verfügung stellt.
Funktionen des „Pet Store“
•
Benutzerverwaltung mit Adress- und Präferenzinformationen
•
Personalisiertes Erscheinungsbild der WebSite
•
Suchfunktion über die WebSite
•
Onlineshop mit Einkaufskorbfunktion, Abrechnung, etc.
•
Durchsuchbarer Haustier-Katalog
Tabelle 20: Funktionen des "Pet Store"
Seite: 167
5.3 Verpacken und Installieren einer Webapplikation
an Hand eines Beispieles
Anhand einer minimalen Webapplikation, die nur aus drei JSPs, einem Servlet und
einer HTML-Datei besteht, soll dem Leser gezeigt werden, wie die selbst erstellte
Webapplikation ihren Weg in den Application Server finden. Dieser Vorgang ist ein
wichtiger Zugang zum Verständnis des Aufbaus des Application Servers, da er auf
einigen
grundlegenden
Basiskonzepten
(J2EE-Applikationsaufbau,
Requestverteilung zwischen HTTP- und Application Server, Webtechnologien wie
z.B. Servlets, etc. ) aufbaut. Die Applikation als solche verfolgt keinen bestimmten
Sinn, da das zentrale Interesse dieses Abschnitts darin liegt zu vermitteln, wie
Applikation verpackt und installiert werden können. Die drei enthaltenen JSPs dienen
dazu, zu demonstrieren wie der Zugriff auf eine Tabelle von JSPs aus bewerkstelligt
wird. Das Servlet gibt den Text „THIS IS A SERVLET FOR WEBENGINEERING
PS!“
aus
und
soll
die
grundsätzliche
Funktionsweise
eines
Servlets
veranschaulichen.
Zur Erstellung und Verpackung der JSPs und des Servlets wurde das IBM
WebSphere Studio 4.0 Entry Edition in Verbindung mit IBM Visual Age for Java
verwendet. Die Palette der angebotenen Entwicklungstools im Rahmen der
WebSphere Plattform befinden sich zu diesem Zeitpunkt (Oktober 2001) gerade in
einer Umstrukturierung. Die Entry Edition des WebSphere Studios 4.0 orientiert sich
vom Aufbau noch sehr an der Version 3.5 des Application Servers. Die
nachfolgenden Editionen des WebSphere Studios haben zum Teil einen anderen
Aufbau und sind wesentlich enger mit dem Application Server integriert.
Leider war es nicht möglich, für diese Arbeit die Application Developer Edition des
WebSphere Studios zu bekommen.
Dieses Kapitel konzentriert sich auf die Tätigkeiten die notwendig sind, um die
Webapplikation zu verpacken und zu installieren. Die Funktion des Publizierens
(„Publish“) im WebSphere Studio wird daher nur am Rande erwähnt, da der Vorgang
des Erstellens und Installierens von Webapplikationen den Schwerpunkt bildet
Die Publish-Funktion betrifft die Möglichkeit, von WebSphere-Studio aus, die
geänderten Dateien direkt auf den HTTP-Server bzw. Application Server zu verteilen,
Seite: 168
ohne den Umweg des Verpackens und Installierens der kompletten Applikation nach
jeder Änderung durchführen zu müssen.
Selbstverständlich ist das Verwenden der Publish-Funktion bei „ernsthaften“ Projekte
unerlässlich, um den Arbeitsaufwand in vernünftigen Grenzen zu halten.
Die Erstellung der JSPs, Servlets usw. steht ausdrücklich nicht im Mittelpunkt der
nachfolgenden Zeilen. Um dem Leser den Einstieg in die Entwicklungsarbeit zu
erleichtern, enthält dieses Kapitel auch einige Hinweise, welche Besonderheiten bei
der Erstellung Webapplikationen mit WebSphere Studio zu beachten sind.
5.3.1
Projekterstellung
Am Beginn jedes Projektes steht die Verzeichnisstruktur. Speziell bei grösseren
Projekten sollte man sich genau überlegen, wo welche Datei abgelegt werden soll.
Durch eine wohl überlegte Verzeichnisstruktur, die allerdings von der Art und Größe
des Projektes abhängt, erhöht sich die Wartbarkeit der Applikation deutlich. Die
folgenden Schritte beschreiben die Vorgangsweise bei der Erstellung eines neuen
Projektes mit Hilfe von WebSphere Studio.
1. Ein neues Verzeichnis mit dem Namen „WASBeispiel“ erstellen.
2. Starten Sie WebSphere Studio mit „Start > Programs > IBM WebSphere >
Studio 4.0 > IBM WebSphere Studio v4.0“
3. Klicken Sie auf „Datei > Neues Projekt“ und geben folgende Daten ein:
Projektname: WASBeispiel
Projektordner: D:\WASBeispiel\
Erstellen mit: Standardschablone
Abbildung 121: Neues Projekt erstellen
Seite: 169
4. Stellen Sie die Publikationsstufe auf „Produktion“.
Abbildung 122: Publikationsstufe auswählen
5. Legen Sie, soweit notwendig, zusätzliche Verzeichnisse z.B. für JSPs, HTMLDateien, etc. unter dem Projektordner an.In diesem Beispiel soll ein zusätzliches
Verzeichnis namens JSP angelegt werden, dass die JSPs enthalten wird.
Diese Ordner werden unter dem Projektordner („D:\WASBeispiel\“) angelegt.
Abbildung 123: Ordner anlegen
6. Starten Sie VisualAge for Java mit „Start > Programs > IBM VisualAge for Java
for Windows V4.0 > IBM VisualAge for Java“.
7. Klicken Sie auf „Go to Workbench“ und auf „OK“.
Seite: 170
8. Klicken Sie im Menü auf „Window > Options“.
Abbildung 124: VisualAge for Java Optionenen
9. Gehen Sie auf “Remote Access to Tool API“ und klicken dort auf “Start Remote
Access to Tool API on VisualAge startup“. Danach klicken Sie auf „Start Remote
Access to Tool API“. Dieser Vorgang gibt ihnen die Möglichkeit von „WebSphere
Studio“ aus „VisualAge“ zur Bearbeitung von z.B. Servlets zu verwenden. Ohne
dieses API ist die Integration von „VisualAge“ in „WebSphere Studio“ nicht
möglich.
Abbildung 125: Remote Access to Tool API starten
Seite: 171
10. In WebSphere Studio klicken Sie auf „Projekt > VisualAge für Java > Studio-Tools
in VisualAge installieren“.
11. Danach ist „VisualAge“ auf die Zusammenarbeit mit „WebSphere Studio“
eingestellt.
12. Jetzt können Sie entweder mit Hilfe der Assistenten JSPs, HTML-Seiten und
Servlets anlegen oder diese selber erstellen.
Die Verwendung der Assistenten zum Anlegen der JSPs oder Servlets ist sehr zu
empfehlen solange man noch nicht ausreichend mit der Programmierung von
JSPs bzw. Servlets vertraut ist.
13. Wenn Sie die notwendigen Dateien erstellt haben, dürfen Sie nicht vergessen,
Servlet-Mappings vorzunehmen. Ein Servlet-Mapping ist der Name unter dem Sie
ein in der Webapplikation Servlet ansprechen können. Zum Beispiel wird ein
Servlet mit dem Servlet-Mapping „MyServlet“ in der fertigen Applikation mit der
URL „http://stargazer/WASBeispiel/MyServlet“ angesprochen. Servlet-Mappings
werden angelegt, indem sie mit der rechten Maustaste auf die .class-Datei klicken
(Zur Erstellung von .class-Dateien siehe unten) und Merkmale wählen.
Unter Servlet-Zuordnung tragen Sie den gewünschten Namen z.B.
„WASBeispielServlet“ ein.
Abbildung 126: Servlet-Mapping
Seite: 172
Hinweise:
•
Um Servlets sinnvoll zu bearbeiten, sollten Sie zuerst ein neues Projekt in
VisualAge anlegen. Vergessen Sie nicht das notwendige Package
(„servlet.jar“ z.B. in „D:\Program Files\ibm\VisualAge for
Java\ide\project_resources\IBM WebSphere Test
Environment\lib“) zu installieren, damit die notwendigen Klassen
(„javax.servlet“,“ javax.servlet.httpservlet“) VisualAge bekannt sind.
Falls diese Klassen nicht installiert sind, bekommen Sie eine Fehlermeldung und
können die Quellcode-Datei nicht übersetzen.
•
Das Installieren von Packages in VisualAge funktioniert über Ansicht „Package >
rechte Maustaste > Import > Jar File > Mit Browse das JAR-File angeben >
Finish“.
•
Um den Sourcecode des Servlets in VisualAge zu bearbeiten, selektieren Sie die
.Java-Datei und klicken auf „Projekt > VisualAge für Java > An VisualAge
senden“. Wenn Sie das Servlet unter VisualAge fertig bearbeitet und gespeichert
haben, klicken Sie im WebSphere Studio auf „Projekt > VisualAge für Java > Über
VisualAge aktualisieren“.
•
WebSphere Studio arbeitet mit einer integrierten Versionsverwaltung.
D.h. es gibt grundsätzlich zwei Versionen von ein und derselben Datei. Eine auf
der Sie temporär arbeiten und Änderungen direkt vornehmen können. Die andere
Version ist die „produktive“ Datei, die nur aktualisiert wird, wenn Sie das
ausdrücklich anordnen. Solange Sie sich nicht sicher sind ob sie ihre Änderungen
in die „produktive“ Version übernehmen wollen, sollten Sie die Datei nicht aus der
Versionskontrolle entnehmen. Wenn Sie sicher sind, daß sie die Änderungen
übernehmen wollen, entnehmen Sie die Datei aus der Versionskontrolle. Wenn
eine Datei entnommen wurde, wird bei jedem Speichervorgang die „produktive“
Datei aktualisiert. Wenn Sie die Aktualisierung abgeschlossen haben, stellen Sie
die Datei wieder in die Versionskontrolle zurück. Dadurch stellen Sie sicher, dass
im produktiven System immer nur die Version einer Datei steht, die die Änderung
enthält, die Sie wirklich durchführen wollen.
Solange die Dateien nicht entnommen sind, liegen Sie im Verzeichnis D:\Program
Files\WebSphere\Studio40\check_out\<Projektname>. Wenn Sie mit der rechten
Maustaste auf die Datei klicken und Entnehmen wählen, wird die Datei aus der
Versionskontrolle entnommen und im von Ihnen festgelegten Projektordner (z.B.
Seite: 173
„D:\WASBeispiel“) abgespeichert. Mit der Funktion „Zurückstellen“ können Sie
die Datei wieder in die Versionskontrolle zurückstellen.
•
WebSphere Studio ermöglicht unterschiedliche Ansichten des Projektes. Wenn
Sie eine bestimmte Funktion (z.B. Kompilieren von Servlets) in einer Ansicht nicht
finden, ist dies möglicherweise nur in einer anderen Ansicht (Beziehungssicht,
Publikationssicht) möglich.
•
Servlets können nicht in die Applikation verpackt werden, bevor sie nicht
kompiliert und als Class-Datei abgelegt wurden (rechte Maustaste >
„kompilieren“).
•
Der Name, unter dem Sie die WebApplikation im Webbrowser aufrufen können
wird erst bei der Installation der Applikation festgelegt.
Seite: 174
5.3.2
Verpacken der Applikation
Wenn Sie die Entwicklungsarbeit abgeschlossen haben, müssen Sie ein Paket
erstellen. Dieser Abschnitt beschreibt die Vorgangsweise wie sie so ein Paket
erstellen können. Nur Web- bzw. Enterprise-Applikationsarchive können mit Hilfe der
Administrationskonsole im Application Server installiert werden.
Dazu sollten Sie folgendermassen vorgehen:
1. Erstellen Sie eine Deskriptordatei. Klicken Sie mit der rechten Maustaste auf der
linken Seite auf den Projektnamen und wählen Sie „Deskriptordatei für
Webkonfiguration erstellen“. Im folgenden Fenster wählen Sie zusätzlich alle
Servlets aus die sie inkludieren wollen. Sollte das von ihnen erstellte Servlet hier
nicht erscheinen, haben Sie keine „class“-Datei erstellt.
Danach klicken Sie auf „Erstellen“.
Abbildung 127: Deskriptordatei erstellen
2. Um ein WebArchiv anzulegen, klicken Sie mit der rechten Maustaste auf das
Projekt und wählen „WebArchivdatei erstellen“. Dann wählen Sie die richtige
Descriptorendatei aus und klicken auf „OK“. Zum Schluss wählen Sie noch einen
passenden Speicherort aus z.B. den Projektorder („D:\WASBeispiel“) und
klicken auf „Save“.
Seite: 175
5.3.3
Installation
Um eine Applikation installieren zu können, müssen Sie die Administrationskonsole
des Application Servers mit „Start > Programs > IBM WebSphere > Application
Server V4.0 AE > Administrator’s Console“ starten
In der Applikationskonsole sind folgende Schritte vorzunehmen:
1. Klicken Sie auf das Wizard-Icon und auf „Enterprise-Anwendung installieren“.
Abbildung 128: Enterprise Anwendung installieren
Seite: 176
2. Wählen Sie „Standalone Modul installieren“ aus und geben Sie die vorhin erstellte
.WAR-Datei an. Der Name der Anwendung legt fest, unter welchen Namen die
installierte Anwendung in der Administrationskonsole aufscheint. Geben Sie hier
ebenfalls „WASBeispiel“ ein.
Als Kontext-Root für WebModul tragen Sie den Namen ein, der Teil der BasisURL ihrer Applikation wird. Z.B. „WASBeispiel => http://stargazer/WASBeispiel“
Abbildung 129: Installation des WebModuls
3. Im „Benutzer Aufgabenbereich zuordnen“-Dialog klicken Sie auf „Weiter“.
4. Im „Enterprise-Beans werden an JNDI Namen gebunden“-Dialog klicken Sie auf
„Weiter“.
5. Im „EJB-Referenzen werden Enterprise-Beans zugeordnet“-Dialog klicken Sie auf
„Weiter“.
6. Im „Resourcenreferenzen an Resource binden“ - Dialog klicken Sie auf „Weiter“.
7. Im „Standarddatenquelle für EJB-Module angeben- Dialog“ klicken Sie auf
„Weiter“.
8. Im „Datenquellen für einzelne CMP-Beans angeben“ - Dialog klicken Sie auf
„Weiter“.
9. Im „Virtuelle Hosts für Webmodule auswählen“- Dialog klicken Sie auf „Weiter“.
10. Im „Anwendungsserver auswählen“ - Dialog klicken Sie auf „Weiter“.
11. Im „Assistenten für Anwendungsinstallation ausführen“ - Dialog klicken Sie auf
„Fertigstellen“.
Seite: 177
12. Jetzt wird die Anwendung installiert und sie sollten folgende Bestätigung erhalten:
Abbildung 130: Bestätigung der Installation
13. Klicken Sie mit der rechten Maustaste auf den Knoten des Servers unter dem der
„default host“ eingetragen ist und wählen Sie „WebServer Plugin erneut
generieren“.
14. Restarten Sie den Server, indem Sie mit der rechten Maustaste auf den Eintrag
„Default Server“ klicken und den Eintrag „Neustart auswählen“.
15. Danach starten Sie erneut die Administrations-Konsole.
16. Jetzt müssen Sie noch die Applikation starten. Dazu wählen Sie die Applikation
im Ordner „Knoten > stargazer > Anwendungsserver > Default Server >
Installierte WebModule“, klicken mit der rechten Maustaste auf den
Applikationseintrag und wählen „Starten“.
5.3.4
Test der Applikation
Um die installierte Applikation zu testen, können Sie folgende Vorgangsweise
wählen:
1. Es sollte ein neues Verzeichnis im Ordner
„D:\WebSphere\AppServer\installedApps“ aufgetaucht sein. Das neue
Verzeichnis trägt den Applikationsnamen, den Sie bei der Installation angegeben
haben und zusätzlich dazu, die Endung .ear. Zum Beispiel:
„D:\WebSphere\AppServer\installedApps\WASBeispiel.ear“
2. Starten Sie den Webbrowser und geben Sie die URL ihre Applikation ein.
Zum Beispiel könnte eine gültige URL so aussehen:
„http://stargazer/WASBeispiel/index.html“.
Wenn Sie auf eine Ressource nicht zugreifen können, kontrollieren Sie, ob Sie die
Applikation gestartet haben und ob die Ressource wirklich in ihrem Paket enthalten
ist. Dies können Sie überprüfen indem Sie z.B. mit dem NT-Explorer in das
Seite: 178
Verzeichnis
„D:\WebSphere\AppServer\installedApps“
wechseln.
Dort
suchen Sie das Verzeichnis ihrer Applikation z.B. „WASBeispiel.ear“ und wechseln in
dieses Verzeichnis. Wenn die gesuchte Resource in diesem oder einem der
Unterverzeichnisse nicht enthalten ist, ist ihr Paket unvollständig und Sie sollten den
Vorgang des Packens der Applikation noch einmal durchführen.
Seite: 179
6 Zusammenfassung und Ausblick
Diese Diplomarbeit ist mit dem Ziel geschrieben worden, Studierenden der SBWL
Wirtschaftsinformatik an der Wirtschaftsuniversität Wien den Einstieg in die Materie
der Application Server zu erleichtern. Dazu wurde ein möglichst praktikabler Ansatz
gewählt, der sich auch an den Erfordernissen des WebEngineering Proseminars
orientierte.
Der Anspruch des praktikablen Ansatzes wurde durch mehrere Punkte umgesetzt:
1. Die Technologieeinführungen, die die Basis dieser Arbeit bilden, wurden bewusst
möglichst wenig Technik-lastig beschrieben. Der Grund dafür ist die Ausrichtung
der Diplomarbeit auf Personen, die nur einen beschränkt technischen Background
haben.
2. Es wurde der Weg der Installation eines minimalen Entwicklungssystems für
einen Application Server ausführlich dokumentiert. Der Zweck dieses Teils
bestand einerseits darin, den Leser in die Lage zu versetzen die notwendige
Basis für eigenständige Experimente zu legen und andererseits schon während
der Installation und Konfiguration des Systems „on the job“ mit zu lernen.
3. Aufbauend auf der beschriebenen Referenzinstallation wurden einige Beispiele
beschrieben, die den Studierenden das Verständnis der teilweise sehr
komplizierten Technologie erleichtern sollen.
Um Missverständisse auszuschließen sei an dieser Stelle erwähnt, daß selbst für die
aufgrund des Zeitmangels eingeschränkten Anforderungen des Proseminars, das
Studium der mit dem Thema direkt zusammenhängenden Literatur, speziell der
Redbooks von IBM (siehe Arly01, EnCh01, EnClu01, NuDj01, WaBo01, WaMa01,
WaTo01, WaTo01), durch die vorliegende Arbeit nicht ersetzt werden kann bzw. soll.
Um die Einführung möglichst durchgängig zu vollziehen, wurde ein thematischer
Bogen aufgespannt, der sich vom grundsätzlichen Aufbau eines Application Servers
über die relevanten Technologien bis zu der Beschreibung von Beispielen, die das
erworbene theoretische Wissen vertiefen sollen,
zieht. Den Einstieg bildet eine
allgemeine Beschreibung von Application Servern. Darin wird geklärt aus welchen
Komponenten ein Application Server besteht und wie diese Komponenten
zusammenspielen. Weiters wird ein kurzer Überblick über den Markt der Application
Seite: 180
Server gegeben, um einen ersten Eindruck (Umsatz, Firmen, Marktanteilsverteilung)
von dem Markt der Application Server zu bekommen.
Mit diesem Wissen ausgestattet, gewährt Kapitel 3 eine Übersicht über die IBM
WebSphere Produktplattform, um darauffolgend die Architektur des „IBM WebSphere
Application Servers“ vorzustellen.
Die Architektur umfasst die wichtigsten Technologien, deren grundsätzliches
Verständnis unerlässlich für die Arbeit mit Application Servern ist. Dabei lag der
Schwerpunkt eindeutig auf der Aufgabe, dem Leser einen, wie schon erwähnt,
möglichst wenig Technik-lastigen Überblick über die jeweilige Technologie zu geben.
Es konnte im Rahmen dieser Arbeit auch nicht viel mehr als ein „Mit-derZehenspitze-eintauchen“ realisiert werden, da jede Technologie für sich Potential für
eine eigene Diplomarbeit bietet.
Die behandelten Themen sind u.a. Java 2 Platform, Enterprise Edition (J2EE), Bean
Scripting Framework (BSF), eXtended Markup Language (XML), Enterprise Java
Beans (EJB), Java Server Pages (JSP) und Servlets. Diese Auswahl wurde
wiederum mit Rücksichtnahme auf die Erfordernisse des Proseminares getroffen.
Kapitel 4 beschäftigt sich intensiv mit der Installation des Referenzservers. Das
abschließende Kapitel stellt einige Beispiele vor, die das Verständnis der
verwendeten Technologien vertiefen sollen. Es wird ebenso demonstriert, wie man
eine Applikation erfolgreich „verpacken“ und im Application Server installieren kann.
Der Autor hofft, mit dieser Arbeit das Potential von Application Servern verdeutlicht
und den Studenten Hilfestellung beim ersten Kontakt mit Application Servern
gegeben zu haben. Diese Hilfestellung ist insofern von Bedeutung, da sie die
Studenten in die Lage versetzen soll, möglichst erfolgreich sich mit einer neuen
Materie zu beschäftigen.
Nur wer sich nicht gleich am Anfang einer scheinbar unüberwindlichen Mauer aus
Problemen gegenübersieht, ist bereit, sich auch in Zukunft mit neuer und
unbekannter Technologie auseinanderzusetzen. Genau diese Fähigkeit, sich
vorurteilsfrei mit neuen Themen zu beschäftigen, um diese im Berufsleben
einschätzen zu können und nicht hilflos der rasanten technologischen Entwicklung
gegenüber zu stehen, wird von Absolventen einer Wirtschaftsuniverstität verlangt.
Das große Potential dürfte die Grundlage für die euphorische Beurteilung vieler
Analysten gewesen sein. Laut Analysten der Giga Information Group (siehe GiZe01)
Seite: 181
erreichte der Umsatz im Marktsegment der Application Server im Jahr 2000 1.64
Milliarden US-$ und steigt bis ins Jahr 2003 auf 9 Milliarden US-$.
Doch es gibt auch Anlaß, das Thema Application Server kritisch zu betrachten.
Ein Indiz dafür, dass die Entwicklung nicht mit den geschätzten Zahlen mithalten
kann, ist das Fehlen von bestätigten Zahlen für das Jahr 2000 per Ende 2001. Alle
Schätzungen für die kommenden Jahre in diesem Marktsegment stammen aus dem
Jahr 1999. Zusätzlich hat der Markt der Application Server auch unter dem
Rückschlag im Bereich E-Commerce gelitten. Das aufgrund dieses Rückschlages
verlorene Vertrauen in Internet-Technologie muss erst wieder zurückgewonnen
werden. Ein weiterer Faktor für die zukünftige wirtschaftliche Entwicklung des
Marktsegments der Application Server, ist das Verhalten der Technologieführer.
Denn von ihnen wird es abhängen, ob sich Application Server in den nächsten
Jahren durchsetzen werden oder ob sich die Entwicklung verlangsamt. Da sich
einige Technologieführer, wie z.B. die Telekombranche, momentan (Ende 2001) in
einer schwierigen wirtschaftlichen Phase befinden, wird die Zukunft zeigen, welchen
Einfluß dieser Umstand auf die technologische Weichenstellung in diesen
Unternehmen haben wird.
Die Vielfältigkeit und Komplexität der angeführten Technologien demonstriert in
Ansätzen mit welchen Schwierigkeiten sich IT-Verantwortliche und Entwickler
auseinander setzen müssen. Um auch nur annähernd das volle Potential der
Application Server ausnutzen zu können, bedarf es an Kompetenzen, die vielfach in
den Unternehmen einfach nicht vorhanden sind. An diesem Umstand tragen die
Unternehmen nur bedingt Schuld. Durch die stark verkürzten Innovationszyklen
scheint auch das Bildungssystem auf Dauer nicht in der Lage zu sein, Fachkräfte
auszubilden, die alle benötigten Qualifikationen aufweisen. Dies verstärkt die Kluft
zwischen
dem,
unterschiedlichster
was
zwar
Gründe
technologisch
möglich
(Ausbildungsstand,
wäre,
Infrastruktur,
aber
aufgrund
Kosten,
etc.)
realistischer Weise nicht umsetzbar ist. Diese Entwicklung ist nicht durch Application
Server ausgelöst worden, doch ist sie an diesen sehr deutlich ablesbar.
Die obig genannten Kritikpunkte ändern allerdings nichts an der Tatsache, dass
Application Server als Anknüpfungspunkt im Bereich der Systemintegration den
Unternehmen ganz neue Möglichkeiten eröffnen. Das hohe Problemlösungspotential
ist unbestritten vorhanden. Die schwierige wirtschaftliche Lage, der anstehende
Neuaufbau des E-Commerce und die problematische „Technologieinflation“ wird
Seite: 182
voraussichtlich zu einer Verlangsamung der Verbreitung von Application Server
führen. Allerdings steht diesen Faktoren immer noch das ungebrochen hohe
Potential gegenüber, das schlussendlich dieser Technologie zum Durchbruch
verhelfen sollte.
Seite: 183
7 Literaturverzeichnis
[AdZo01]
Advisor Zone – IBM WebSphere Application Server 4.0
http://advisor.com/Articles.nsf/aid/SMITT256
Abruf am 19.08.2001
[ArIy01]
David Artus, Ashok Iyengar, Simon Kapadia,Mohamed Ramdani,
James Roca, Chenxi Zhang, Ken Ueno, Larry Brown, Larry Clark, Chris
Gerken, Geoff Hambrick, Stacy Joines, Sung-Ik Son, Lorrie Tomek, Jim
VanOosten
WebSphere V3.5 Handbook. Redbook, Nummer SG24-6161-00. IBM
Corporation. 1186 Seiten.
http://www.redbooks.ibm.com/redbooks/SG246161.html
Abruf am 19.08.2001
[CiJe01]
Cimetiere, Jean-Christophe, TechMetrix Research,Serverwatch,
Does the App Server Market still exists ?
http://serverwatch.internet.com/articles/appsmkt/
Abruf am 29.08.2001
[EnCh01]
Louis
Ennser,
Christophe
Chuvan,
Paul
Fremantle,
Ramani
Routray,Jouko Ruuskanen
The XML-Files : Using XML and XSL with IBM WebSphere 3.0
Redbook, Nummer SG24-5479-00. IBM Corporation. 258 Seiten.
[EnClu01]
Mark Endrei,Rohan Cluning,Wut Daomanee,Jeff Hayward,Ashok
Iyengar,Isabelle Mauny,Torsten Naumann,Ascension Sanchez
WebSphere 4.0 Advanced Edition Handbook,
RedPiece(Draft Document 31. August.2001), Nummber SG24-6176-00.
IBM Corporation. 988 Seiten.
Seite: 184
[EnCl201]
Mark Endrei,Rohan Cluning,Wut Daomanee,Jeff Hayward,Ashok
Iyengar,Isabelle Mauny,Torsten Naumann,Ascension Sanchez
WebSphere 4.0 Advanced Edition Handbook,
RedPiece(Draft Document 1. October 2001), Nummber SG24-6176-00.
IBM Corporation. 1094 Seiten.
[EsBe01]
Esan,
Berna
–
Architektur
und
Arbeitsweise
der
E-Plattform
WebSphere, Seminararbeit, Universität Stuttgart
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/hauptseminar/
docWS0001/WAS-Ausarbeitung.pdf
Abruf im August 2001
[FlRo01]
Flatscher Rony G., Java Bean Scripting with Rexx, 06.05.2001
Proceedings of the „12. International Rexx Symposium“,
Triangle Research Park, North Carolina, USA, 30.April 30 – 2.Mai ,The
Rexx Language Association, Raleigh N.C. 2001., 27 Seiten.
[GiZe01]
Gilpin Mike, Zetie Carl – Planning Assumption, 2000 Forecast for the
EJB Application Server Market, 19.Juni 2000, Giga Information Group,
7 Seiten
[HaNe01]
Hansen Hans Robert, Neumann Gustaf, Wirtschaftsinformatik I, ISBN
3-8252-0802-8,1336 Seiten.
[HrNo01]
Hranitzky, Norbert – Enterprise Java Beans,Präsentationsunterlagen,
Siemens AG, 09.07.1999
222 Seiten
[KaPe01]
Kalender, Peter – A concept for and implementation of the BSF for
REXX, Universität Essen, Schiseminar aus Wirtschaftsinformatik,
Wintersemester 2000/2001, 10.12.2000
http://nestroy.wi-inf.uni-essen.de/Lv/seminare/ws0001/PKalender/
Seminararbeit.pdf
Seite: 185
[IBM101]
WebSphere Application Server - Einführung
http://www.transarc.ibm.com/Library/documentation/websphere/WASEE/de_DE/pdf/C1227630.pdf
[ManK01]
Manfred Kunde EDV-Beratung, Fallstudien, Ti(p)ps & Tricks –
Application Server
http://www.mkunde.de/fallst/as_navi.html
[NuDj01]
Barry Nusbaum,Matias Djunatan,Wakako Jinno und Peter Kelley
WebSphere Application Servers: Standard and Advanced Editions.
Redbook,
Nummer
SG24-5460-00.
IBM
Corporation.
ISBN
738413756-3. 480 Seiten.
http://www.redbooks.ibm.com/redbooks/SG245460.html
Abruf am 19.08.2001
[ReHo01]
Reibold, Holger: ZDNet - Im Test: Application Server bis 30.000 Mark
http://www.zdnet.de/produkte/artikel/sw/199906/webappserver01_01ec.html
[SPCW01]
Prehl, Sabine, Computerwelt, “Zähes Ringen im Application-ServerMarkt”, Dezember 2001
[W3C01]
W3C, What is XSL ?
http://www.w3.org/Style/XSL/WhatIsXSL.html
Abruf im November 2001
[WaBo01]
Wahli Ueli, Boyle Iain, Fernandes Juliana, Ribas D’avila Flavio
Version 3.5 Self Study Guide: VisualAge for Java and WebSphere
Studio, Redbook, Nummer SG24-6136-00, IBM Corporation, 404
Seiten.
0-
Seite: 186
[WaMa01]
Wahli Ueli, Matthews Alex, Coll Lapido Paula, Norguet Jean-Pierre,
WebSphere Version 4 Application Development Handbook, Redbook,
Nummer SG24-6134-00, IBM Corporation, 612 Seiten.
[WaTo01]
Ueli Wahli, Tomlinson Mark, Zimmermann Olaf, Deruyck Wouter,
Hendriks Denise
Web Services Wizardry with WebSphere Studio Application Developer,
Redbook, Nummer SG24-6292-00, IBM Corporation, 622 Seiten.
[WASO01]
WebSphere Application Server - Overview
http://www-4.ibm.com/software/webservers/appserv/
Abruf am 18.08.2001
[WSPA01]
http://www-4.ibm.com/software/webservers/appserv/advanced.html
Abruf am 18.08.2001
[WSPE01]
http://www-4.ibm.com/software/webservers/appserv/enterprise.html
Abruf am 18.08.2001
[WSPO01]
WebSphere Software Plattform - Übersicht
http://www7b.boulder.ibm.com/wsdd/products/platformoverview.html
[WSPS01]
http://www-4.ibm.com/software/webservers/appserv/standard.html
[WUVO01]
Putscher,Erdem und Sommer - Präsentationsunterlagen für VO
WebEngineering
http://www.wu-wien.ac.at/usr/h96b/h9625793/
Seite: 187
8 Verzeichnis der sonstigen Quellen und
Hilfsmittel
[Alph01]
IBM Alphaworks
http://www.alphaworks.ibm.com/
[Apac01]
The Apache Software Foundation
http://www.apache.org/
[Java01]
Java.Sun.com – The Source for Java Technology
http://java.sun.com
[Goog01]
Google
http://www.google.com/
[JaWo01]
Java World
http://www.javaworld.com/
[MIIS01]
Microsoft Internet Information Services - Glossar
http://ara.novae.ch/iishelp/iis/htm/core/iigloss.htm
[MüBe01]
Prof. Dr. Müller Bernd, Fachhochschule Harz –Studiengang
Wirtschaftsinformatik , Abkürzungsverzeichnis und Glossar
http://www2.fh-harz.de/~bmueller/skripte/glossar.pdf
Abruf am 22.August 2001
Seite: 188
[Open01]
Openwave
http://www.openwave.com/
[OS2G01]
OS2 und Computer Glossar
http://de.os2.org/tips/glossar/
Abruf am 22.August 2001
[Sowi01]
Sowinet Internet Glossar
http://www.sowinet.com/glossar/
[W3Sc01]
W3Schools Online Web Tutorials
http://www.w3schools.com/
[WWWC01] The World Wide Web Consortium
http://www.w3c.org

Version 1.2 - Wirtschaftsuniversität Wien

Transcription

Similar documents

PDF-Datei - Landkreis Hildesheim

Gliederung Kapitel 3 Java-Komponenten

Good Tags - Waxmann Verlag

Eastern Cape Niedersachsen