WebSphere Remote Server Information Center Version 7.0

Transcrição

WebSphere WebSphere® Remote Server
®
Version 7.0
IBM® WebSphere® Remote Server Information Center Version 7.0
򔻐򗗠򙳰
Juni 2009
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM WebSphere Remote Server Information Center Version 7.0,
herausgegeben von International Business Machines Corporation, USA
© Copyright International Business Machines Corporation 2004, 2009
© Copyright IBM Deutschland GmbH 2009
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz
nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Herausgegeben von:
SW TSC Germany
Kst. 2877
Juni 2009
Inhaltsverzeichnis
Kapitel 1. Produktübersicht . . . . . . 1
Neuerungen in diesem Release . . . . . .
WebSphere Remote Server-Editionen . . . .
WebSphere Remote Server-Installationsprogramm
(Installer) . . . . . . . . . . . . .
Systems Management Accelerators . . . . .
Filialrechner (ISPs) . . . . . . . . . .
Unternehmensserver . . . . . . . . . .
.
.
. 2
. 2
.
.
.
.
.
.
.
.
3
3
4
4
Kapitel 2. Installation . . . . . . . . . 5
Hardware- und Softwareanforderungen . . .
Hardwarevoraussetzungen. . . . . . .
Softwarevoraussetzungen . . . . . . .
Produkt installieren . . . . . . . . . .
IBM WebSphere Remote Server installieren .
Entwicklungsumgebung installieren . . .
Eingabefelder in Deployment Wizard . . .
Unbeaufsichtigte Installation. . . . . .
Installation prüfen . . . . . . . . . .
Installationsprotokolldateien . . . . . .
WebSphere Application Server prüfen . .
WebSphere MQ prüfen . . . . . . .
IBM HTTP Server prüfen . . . . . . .
DB2 Workgroup Server Edition prüfen . .
Informix Dynamic Server prüfen . . . .
WebSphere sMash prüfen. . . . . . .
Deinstallation. . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
. 6
. 6
. 7
. 7
. 8
. 10
. 19
. 21
. 21
. 21
. 21
. 22
. 22
. 23
. 24
. 24
Kapitel 3. Aktualisierung oder Migration
durchführen . . . . . . . . . . . . 27
Aktualisierungsstrategie . . . .
WebSphere Remote Server-Fixpacks
Fixes . . . . . . . . . .
Migration . . . . . . . . .
Migration auf 7.0 . . . . .
Kapitel 4. Verwaltung
. . . . .
und vorläufige
. . . . .
. . . . .
. . . . .
WebSphere Remote Server steuern . . . . . . .
WebSphere MQ-Nachrichtencontroller . . . . .
WebSphere MQ-Nachrichtencontroller installieren
WebSphere MQ-Nachrichtencontroller konfigurieren . . . . . . . . . . . . . . . .
Alternativen zum Nachrichtencontroller . . . .
IBM Tivoli License Compliance Manager installieren
und aktivieren . . . . . . . . . . . . .
Sicherheitsaspekte . . . . . . . . . . . .
33
37
37
37
39
40
41
Kapitel 5. Erweiterung . . . . . . . . 49
Lösung erweitern . . . . . . . . . . .
WebSphere sMash . . . . . . . . . . .
Musterlösung erstellen . . . . . . . . .
Muster erstellen . . . . . . . . . . .
Musterlösung für unbeaufsichtigte Installation
vorbereiten . . . . . . . . . . . .
Musterlösung ändern . . . . . . . . .
WebSphere Remote Server mit einer WebSphereMusteranwendung erweitern . . . . . . .
Erläuterung des Mustercodes . . . . . .
Musterlösung ’PlantsByWebSphere’ verwenden
Eigene Lösungen entwickeln. . . . . . .
Anwendung erstellen . . . . . . . . . .
WebSphere Remote Server- und ISP-Anwendungen
steuern . . . . . . . . . . . . . . .
.
.
.
.
49
50
51
51
. 53
. 54
. 55
. 55
63
. 64
. 70
. 72
Kapitel 6. Fehlerbehebung und Unterstützung . . . . . . . . . . . . . . 79
. 27
IBM Support Assistant installieren und verwenden 79
Log Collector . . . . . . . . . . . . . . 80
Fehlerbehebung, Tipps. . . . . . . . . . . 80
. 27
. 29
. 30
Kapitel 7. Referenzinformationen . . . 85
. . . . . . . . 33
Allgemeine Produktinformationen .
White Papers . . . . . . . .
Bemerkungen und Marken . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 85
. 86
. 86
iii
iv
Kapitel 1. Produktübersicht
IBM® WebSphere Remote Server ist eine der führenden SOA-Plattformen (Service
Oriented Architecture) für fern verwaltete, verteilte Umgebungen und speziell für
die Integration und Unterstützung von bisherigen, aktuellen und zukünftigen Einheiten und Anwendungen der Geschäftsebene konzipiert.
Als zentrale Komponente für IBM Retail Integration Framework bietet WebSphere
Remote Server die Basis für Innovationen in Geschäftsumgebungen, in denen der
Kundenkontakt ebenso wie Selbstbedienungstechnologien zur Vermittlung einer
differenzierten Serviceumgebung für den Kunden von großer Bedeutung sind.
WebSphere Remote Server stellt eine Plattform für die Erstellung, Assemblierung,
Implementierung und Verwaltung dieser Lösungen der nächsten Generation bereit,
die Unterstützung für Branchenstandards und Schutz vorhandener Lösungen bietet
und eine vollwertige Plug-and-Play-Plattform mit der Nutzung von J2EE-Middlewaretechnologien darstellt.
WebSphere Remote Server besteht aus einer Sammlung von IBM Middlewareprodukten und ist für die Installation auf einem Server in einem Geschäft vorgesehen.
Diese Server werden als Filialrechner (In-store Processors, ISPs) bezeichnet.
Abb. 1 veranschaulicht an einem Beispiel, wie eine Geschäftsumgebung mit mehreren fernen Filialrechnern (ISPs) aussehen könnte. Jeder ISP tauscht Daten mit
einem zentralen Unternehmensserver aus. Die Geschäfte befinden sich an unterschiedlichen Standorten und verfügen jeweils über einen ISP, auf dem WebSphere
Remote Server ausgeführt wird.
Abbildung 1. Muster für eine Umgebung mit mehreren fernen ISPs
1
Neuerungen in diesem Release
In diesem Abschnitt werden neue funktionale Erweiterungen und Komponenten
beschrieben, die im Lieferumfang von WebSphere Remote Server V7.0 enthalten
sind.
Dieses Release bietet Upgrades für die Middleware-Produkte sowie folgende Änderungen.
Verfügbare Editionen
WebSphere Remote Server V7.0 steht nur als Starter Edition zur Verfügung. Details
dazu, welche Produkte und Komponenten zu der Starter Edition gehören, finden
Sie im Abschnitt „WebSphere Remote Server-Editionen”.
Anmerkung: Bei Version 7.0 können der Produktname von WebSphere Remote
Server und alternativ der Editionsname von IBM Retail Store Server
verwendet werden.
WebSphere sMash
Dieses Release umfasst WebSphere sMash und die zugehörige Komponente IBM
Reliable Transport Extension for WebSphere sMash, die zusammen mit der
WebSphere Remote Server-Entwicklungsumgebung für eine Installation zur Verfügung stehen. WebSphere sMash bietet einen Übertragungsweg von Einheiten zu
Back-End-Systemen mithilfe von WebSphere MQ. Sie können Ihre eigenen Anwendungen schreiben, um die Funktionen von WebSphere sMash auszuschöpfen. Weitere Informationen finden Sie im Abschnitt „WebSphere sMash” auf Seite 50.
Informix Dynamic Server
In diesem Release können Sie Informix Dynamic Server als Ihre Datenbank verwenden. Details dazu, welche Edition Informix Dynamic Server einschließt, finden
Sie im Abschnitt „WebSphere Remote Server-Editionen”.
WebSphere Remote Server-Editionen
IBM WebSphere Remote Server V7.0 ist in zwei Editionen verfügbar. Die Lizenzbedingungen für die jeweils verwendete Edition von WebSphere Remote Server
enthalten Informationen zu den Einschränkungen hinsichtlich des Produkts und
der Umgebung.
Anmerkung: Bei Version 7.0 können der Produktname von WebSphere Remote
Server und alternativ der Editionsname von IBM Retail Store Server
verwendet werden.
IBM Retail Store Server Starter Edition
Die Starter Edition bietet einen Einstiegspunkt für WebSphere Remote Server und umfasst Folgendes:
v IBM WebSphere MQ 7.0.0.1
v DB2 Workgroup Server Edition 9.5 Fix Pack 3a (eingeschränkte Funktionalität)
v IBM WebSphere Application Server Network Deployment 7.0.0.3 (eingeschränkte Funktionalität)
v IBM HTTP Server 7.0
2
v Systems Management Accelerators (Untergruppe ohne Überwachungskomponenten)
v IBM WebSphere sMash 1.1.0.1
v IBM Solution Assembly Toolkit 3.1.1.5
IBM Retail Store Server Starter Edition mit Informix Dynamic Server
Diese Version der Starter Edition bietet auch einen Einstiegspunkt für
WebSphere Remote Server und umfasst Folgendes:
v IBM Informix Dynamic Server Workgroup Edition 11.50xC3 (weitere
Details im Abschnitt „Hardware- und Softwareanforderungen” auf Seite
5)
v IBM WebSphere Application Server Network Deployment 7.0.0.3 (eingeschränkte Funktionalität)
v Systems Management Accelerators (Untergruppe ohne Überwachungskomponenten)
WebSphere Remote Server-Installationsprogramm (Installer)
Mit dem Installationsprogramm, einem Teil von Systems Management Accelerators,
wird eine mit IBM Solution Assembly Toolkit erstellte Lösung installiert.
Die Lösung besteht aus einer Musteranwendung, IBM Middleware und einer auf
Eclipse basierenden Entwicklungsumgebung namens Express Runtime Developer.
Kunden, ISVs und Systemintegratoren können die Entwicklungsumgebung dazu
verwenden, die Musteranwendung zu ersetzen und eine eigene Lösung zu erstellen.
Das Installationsprogramm bietet die folgenden drei Installationsoptionen:
v IBM Retail Store Server 7.0-Laufzeit installieren: Installiert die IBM Retail Store
Server-Laufzeit, die aus allen Middlewarekomponenten und Musteranwendungen für WebSphere besteht.
v Von WebSphere Remote Server 6.1 auf 6.2.x migrieren: Upgrade für eine vorhandene WebSphere Remote Server 6.1- oder 6.2.x-Laufzeitinstallation auf die
neueste Version der IBM Retail Store Server 7.0-Middlewareprodukte durchführen.
Anmerkung: Diese Task ist nur für Benutzer von DB2 sowie auf den unterstützten Migrationsplattformen verfügbar. Details hierzu finden Sie im
Abschnitt „Migration” auf Seite 29.
v IBM Retail Store Server-Lösungsentwicklungsumgebung installieren: Die
Lösungsentwicklungsumgebung besteht aus IBM Solution Assembly Toolkit
3.1.1.5, einem vollständigen Projektarbeitsbereich und den Installationsimages
für alle Middlewareprodukte.
Systems Management Accelerators
Bei Systems Management Accelerators handelt es sich um eine Reihe von Tools für
verschiedene Funktionen, die bei der Konfiguration einer Geschäftsumgebung
erforderlich sind.
Kapitel 1. Produktübersicht
3
Systems Management Accelerators (im Folgenden Accelerators) vereinfacht die
Installation von WebSphere Remote Server auf mehreren Maschinen.
Filialrechner (ISPs)
Ein Filialrechner (In-store Processor, ISP) ist ein Server im Geschäft.
Dieser Server führt ein Linux®- oder Windows®-Betriebssystem aus und ist mit verschiedenen Einheiten verbunden wie beispielsweise mit Point-of-Sale-Controllern,
Selbstbedienungsterminals, Selbstbedienungskassen und anderen Einheiten. Auf
dem ISP wird die gesamte erforderliche Software für die Geschäftsoperationen ausgeführt. WebSphere Remote Server ist auf dem Filialrechner als Basisplattform für
andere Anwendungen installiert.
Unternehmensserver
Der Unternehmensserver wird als zentraler Verwaltungspunkt für alle Filialrechner
(ISPs) eingesetzt.
Auf dem Unternehmensserver werden Softwareinstallationen gestartet und
Überwachungsdaten empfangen. Nachdem IBM WebSphere Remote Server mithilfe
von Accelerators auf allen ISPs installiert wurde, können die meisten Managementmaßnahmen für die ISPs über Remotezugriff ausgeführt werden.
Der Unternehmensserver ist nur erforderlich, um die nötige Software zum Einleiten von Installationen auf den ISPs über Accelerators auszuführen. Beispiele: FTPClient und Telnet-Client.
4
Kapitel 2. Installation
Gehen Sie wie in den nachstehenden Themen beschrieben vor, um die Installation
vorzubereiten, IBM WebSphere Remote Server und die Entwicklungsumgebung zu
installieren sowie die Installation zu prüfen.
Sie können WebSphere Remote Server Solution Installer für Neuinstallationen von
V7.0 oder zur Migration von Vorgängerreleases verwenden. Weitere Informationen
zu den Migrationsszenarios finden Sie im Abschnitt Kapitel 3, „Aktualisierung oder
Migration durchführen”, auf Seite 27.
Darüber hinaus können Sie auch die Entwicklungsumgebung der WebSphere
Remote Server-Lösung installieren. Sie können mit der Entwicklungsumgebung
angepasste Lösungen auf der Basis von IBM WebSphere Remote Server entwickeln.
Anmerkung: Die Entwicklungsumgebung wird unter Windows Embedded POSReady 2009 nicht unterstützt.
Hardware- und Softwareanforderungen
In diesem Abschnitt werden die Hardware- und Softwareanforderungen für IBM
WebSphere Remote Server und die unterstützten Komponenten beschrieben.
Tipp: Eine aktuelle Liste der unterstützten Hardware- und Softwareplattformen für
alle Editionen von WebSphere Remote Server, finden Sie auf der Seite mit
den Systemvoraussetzungen und im Dokument mit den unterstützten
Betriebssystemen.
Softwarepaket
WebSphere Remote Server bündelt und unterstützt die folgenden IBM Produktversionen bei allgemeiner Verfügbarkeit:
v IBM WebSphere Application Server Network Deployment 7.0.0.3
v DB2 Workgroup Server Edition 9.5 Fixpack 3a oder IBM Informix Dynamic Server Workgroup Edition 11.50xC31
Bevor Sie mit der Installation beginnen, informieren Sie sich über die Hardwareund Softwarevoraussetzungen für den Filialrechner (ISP) und die Unternehmensserver.
1. Die Variable x steht für einen der folgenden Buchstaben, die jeweils eine Plattform darstellen:
– F = 64-Bit auf beliebiger UNIX/Linux-Plattform
– H = 32-Bit auf beliebiger HP 11.x-Plattform (kann auch unter HP 11.x 64-Bit ausgeführt werden)
– T = Windows-Plattformen
– U = 32-Bit auf beliebiger UNIX/Linux-Plattform
Weitere Informationen finden Sie in der Übersicht für Informix-Plattformen.
5
Hardwarevoraussetzungen
Die folgenden Hardwaremindestvoraussetzungen müssen von Filialrechnern (Instore Processors, ISPs) und Unternehmensservern erfüllt werden.
Betriebssystemen.
Filialrechner (ISP)
v IBM PC-Server mit 32-Bit-Prozessor von Intel® Pentium® 500 MHz (empfohlen
werden 2 GHz oder höher)
v 2 GB Hauptspeicher
v 12 GB Plattenspeicher
Unternehmensserver
Für WebSphere Remote Server sind mehrere Unternehmensserver erforderlich.
v IBM PC-Server mit 32-Bit-Prozessor von Intel Pentium 500 MHz (empfohlen
werden 2 GHz oder höher)
v 2 GB Hauptspeicher
v 12 GB Plattenspeicher
Softwarevoraussetzungen
Softwarevoraussetzungen für den Filialrechner und den Unternehmensserver.
Betriebssystemen.
Filialrechner
Tabelle 1. Unterstützte Software für den Filialrechner
Betriebssystem
Unterstützte Versionen
Linux
v SUSE Linux Enterprise Server 10 mit Service-Pack 1 oder Service-Pack 2
v Red Hat Enterprise Linux 5.2
v Red Hat Enterprise Linux 5.3
Windows
v Windows 2003 Server Standard Edition
oder Enterprise Edition mit Service-Pack 2
v Windows 2003 Server R2 Standard Edition
oder Enterprise Edition mit Service-Pack 2
v Windows 2008 Server
v Windows Embedded POSReady 2009
v Windows XP Professional mit ServicePack 2
v Eine Umgebung zum Empfangen von Dateien, z. B. ein FTP-Server, ist vorhanden.
6
v Eine Umgebung zum Ausführen von fernen Scripts, z. B. ein Telnet-Client oder
ein SSH-Server.
Unternehmensserver
v Eine Umgebung zum Verteilen von Dateien, z. B. ein FTP-Client, ist vorhanden.
v Eine Umgebung für Verbindungen zu fernen Servern, z. B. ein Telnet-Server
oder SSH-Client, ist vorhanden.
Produkt installieren
Gehen Sie wie in den nachstehenden Themen beschrieben vor, um IBM WebSphere
Remote Server und die Entwicklungsumgebung zu installieren.
IBM WebSphere Remote Server installieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um IBM WebSphere Remote
Server zu installieren.
Wenn Sie bereits die gesamte oder einen Teil der erforderlichen Middleware aus
einer früheren Version von WebSphere Remote Server installiert haben, führen Sie
die Installation anhand der für die „Migration” auf Seite 29 beschriebenen Anweisungen aus.
Wichtig: Wenn Sie die Installation unter dem Betriebssystem Windows Embedded
POSReady 2009 oder unter Windows XP Professional ausführen und Sie
IPv6 verwenden müssen, aktualisieren Sie die in WebSphere Remote Server enthaltene Version von Informix Dynamic Server auf UC4 für Linux
oder TC4 für Windows.
1. Legen Sie die DVD mit dem Installationsprogramm von WebSphere Remote
Server für die entsprechende Plattform ein.
Anmerkung: Unter Linux müssen Sie sich als Rootbenutzer anmelden, um die
Installation mit den Accelerators-DVDs durchzuführen.
Wenn beim Einlegen der DVD die Klickstartleiste (das Launchpad) von
WebSphere Remote Server nicht automatisch geöffnet wird, müssen Sie unter
Windows den Befehl launchpad.exe bzw. unter Linux den Befehl launchpad.sh
auf der DVD ausführen. Die Klickstartleiste enthält nützliche Informationen
und Links zum Starten der Installation.
2. Wählen Sie in der Klickstartleiste die Installation von WebSphere Remote Server aus.
Wenn Sie den Link zur Installation von WebSphere Remote Server auswählen,
wird Deployment Wizard vorübergehend auf Ihrem Festplattenlaufwerk
installiert. Nach Abschluss der Installation von Deployment Wizard wird dieser automatisch gestartet und führt Sie durch die Installation von WebSphere
Remote Server.
3. Wählen Sie das Optionsfeld neben der Aussage I accept both the IBM and
the non-IBM terms (Ich akzeptiere die Bedingungen von IBM und anderen
Anbietern) aus, wenn Sie mit der Lizenzvereinbarung einverstanden sind, und
klicken Sie auf Next, um fortzufahren.
4. Klicken Sie auf Next, wenn die Begrüßungsseite angezeigt wird, um mit der
Installation fortzufahren.
7
5. Wählen Sie die Installation der IBM Retail Store Server 7.0-Laufzeit aus. Weitere Informationen zu anderen Installationsoptionen finden Sie in den
Abschnitten „Migration” auf Seite 29 und „Entwicklungsumgebung installieren”.
6. Komponenten für die Installation auswählen.
Wichtig: Beachten Sie bei der Installation von Informix Dynamic Server, dass
es nur in einer NTFS-Partition installiert werden kann.
7. Geben Sie die erforderlichen und die optionalen Installationsparameter an,
wenn Sie von Deployment Wizard dazu aufgefordert werden.
Eine detaillierte Beschreibung der Felder finden Sie im Abschnitt „Felder für
die Laufzeitinstallation” auf Seite 10.
Anmerkung: Wenn Sie die WebSphere Application Server-Sicherheit auf
einem Linux-Betriebssystem aktivieren wollen, müssen Sie
sicherstellen, dass zunächst WebSphere Application Server heruntergefahren ist, bevor Sie einen Warmstart für den Server ausführen.
8. Implementieren Sie die Installationstasks, nachdem Sie sie im Fenster mit der
Zusammenfassungsanzeige auf Ihre Richtigkeit hin überprüft haben.
9. Prüfen Sie, ob die Implementierungstasks erfolgreich ausgeführt wurden.
Wenn alle Implementierungstasks ausgeführt wurden, ist in der Anzeige mit
dem Implementierungsstatus zu sehen, dass die Implementierung erfolgreich
war. Die detaillierten Nachrichten sowie das Hauptprotokoll können für weitere Informationen zur Implementierung zurate gezogen werden.
Prüfen Sie zum Lösen von Installationsfehlern die Installationsprotokolle und
verwenden Sie die Informationen im Abschnitt „Fehlerbehebung, Tipps” auf
Seite 80.
10. Wenn Sie die Installation unter dem Betriebssystem Windows Embedded POSReady 2009 oder unter Windows XP ausgeführt haben, führen Sie einen
Warmstart für den Server durch, damit das Betriebssystem die Aktualisierungen übernehmen kann.
Installation prüfen.
Entwicklungsumgebung installieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um die IBM WebSphere
Remote Server-Entwicklungsumgebung zu installieren.
Die Entwicklungsumgebung besteht aus Solution Assembly Toolkit und dem
WebSphere Remote Server-Arbeitsbereich. Sie können optional WebSphere sMash
installieren, um einen Übertragungsweg von Einheiten zu Back-End-Systemen mithilfe von WebSphere MQ bereitzustellen.
Der Arbeitsbereich umfasst alle Projektdateien sowie die Implementierungspakete
(Installationsmedien für die Middlewareprodukte in Form einer .jar-Datei) für ein
bestimmtes Betriebssystem. Für die Entwicklung einer angepassten WebSphere
Remote Server-Lösung müssen Sie das Toolkit für das Betriebssystem Ihrer
Entwicklungsworkstation und den bzw. die Arbeitsbereich(e) für das bzw. die
Betriebssystem(e) Ihres Zielservers bzw. Ihrer Zielserver installieren. Das Toolkit
muss vor dem Arbeitsbereich bzw. den Arbeitsbereichen installiert werden. Wenn
das Betriebssystem Ihrer Entwicklungsworkstation mit dem Betriebssystem der
Zielserver übereinstimmt, können Sie den Arbeitsbereich zum selben Zeitpunkt
installieren. Die Arbeitsbereichs- und Implementierungspakete für eine vorgege-
8
bene Plattform sind auf der DVD von WebSphere Remote Server für die entsprechende Plattform verfügbar. Bei der plattformübergreifenden Entwicklung oder der
Entwicklung auf zwei Plattformen müssen Sie den Arbeitsbereich von der entsprechenden WebSphere Remote Server-DVD installieren.
Beispiel: Sie entwickeln auf einer Windows-Plattformworkstation, bei der Zielplattform handelt es sich jedoch um eine Linux-Plattform. Sie müssen zuerst Solution Assembly Toolkit von der DVD mit WebSphere Remote Server für Windows
installieren. Zur Installation des WebSphere Remote Server-Arbeitsbereichs für
Linux führen Sie das Script WindowsSetup.exe von der DVD mit WebSphere
Remote Server für Linux aus. Bei der Ausführung des Lösungsinstallationsprogramms für Linux auf einer Windows-Maschine ist die Installation des
WebSphere Remote Server-Arbeitsbereichs die einzige verfügbare Option.
Zum Erstellen einer Lösung verwenden Sie das Installatiosprogramm, um die
Entwicklungsumgebung unter einem Windows- oder Linux-Betriebssystem zu
installieren. Nach der Installation der Entwicklungsumgebung müssen Sie Express
Runtime Developer öffnen.
Anmerkung: Die Entwicklungsumgebung wird unter Windows Embedded POSReady 2009 nicht unterstützt.
Remote Server.
5. Wählen Sie die Installation der IBM Retail Store Server-Lösungsentwicklungsumgebung aus.
6. Geben Sie die zu installierenden Komponenten an. Dies sind die Komponenten Solution Assembly Toolkit, WebSphere sMash und der IBM Retail Store
Server-Arbeitsbereich.
7. Geben Sie die erforderlichen und die optionalen Installationsparameter an,
wenn Sie von Deployment Wizard dazu aufgefordert werden.
Details zu den einzelnen Feldern finden Sie im Abschnitt „Felder für die
Installation der Entwicklungsumgebung” auf Seite 19.
9
8.
9.
10.
11.
Falls eine frühere Version von Solution Assembly Toolkit auf dem Server
installiert wurde, wird das in WebSphere Remote Server 7.0 enthaltene Solution Assembly Toolkit standardmäßig an einer neuen Position installiert. Die
unterschiedlichen Versionen von Solution Assembly Toolkit können auf dem
Server koexistieren.
Implementieren Sie die Installationstasks, nachdem Sie sie im Fenster mit der
Prüfen Sie, ob die Implementierungstasks erfolgreich ausgeführt wurden.
Öffnen Sie Express Runtime Developer.
Wählen Sie im Startmenü Alle Programme → IBM Solution
Assembly Toolkit 3.1 → Express Runtime Developer aus.
Führen Sie diesen Befehl aus: cd /opt/IBM/SAT/3.1/
SolutionEnabler ./IRU_Developer.sh
Beim Start von Express Runtime Developer werden Sie in einem Dialogfenster
aufgefordert, die Position des zu öffnenden Arbeitsbereichs anzugeben. Wählen Sie die Position aus, die während der Installation der Lösungsentwicklungsumgebung angegeben wurde, und klicken Sie anschließend auf
OK. Standardmäßig lautet die Arbeitsbereichsposition wie folgt:
C:\Program Files\IBM\SIF\workspace\irss70
/opt/IBM/SIF/workspace/irss70
Wenn das Anwendungsfenster geöffnet wird, wird eine Begrüßungsseite (’Welcome’) angezeigt.
12. Schließen Sie die Begrüßungsseite, um die Arbeitsumgebung und die Projekte
anzuzeigen, aus denen sich der Arbeitsbereich zusammensetzt.
Wenn Sie mit Express Runtime Developer nicht vertraut sind, informieren Sie
sich in der integrierten Hilfefunktion. Führen Sie dazu folgende Schritte aus:
a. Wählen Sie in der Menüleiste von Express Runtime Developer die Optionen Help und Help Contents aus. Das Fenster Help - Express Runtime
Developer wird geöffnet.
b. Klicken Sie im Fenster Contents auf den Link Using the Express Runtime
Developer.
Weitere Informationen zu Solution Assembly Toolkit finden Sie unter folgender
Adresse: http://publib.boulder.ibm.com/infocenter/satinfo/v3r1/index.jsp
Eingabefelder in Deployment Wizard
In diesem Abschnitt werden die Eingabefelder für jeden Abschnitt des
Installationsprogramms beschrieben.
Felder für die Laufzeitinstallation
Tasks auswählen - Installationstyp auswählen
Im Fenster Tasks auswählen - Installationstyp auswählen werden Sie dazu aufgefordert, den WebSphere Remote Server-Installationstyp anzugeben, den Sie durchführen:
v IBM Retail Store Server 7.0-Laufzeit installieren: Installiert die IBM Retail Store
Server-Laufzeit, die aus allen Middlewarekomponenten und Musteranwendungen für WebSphere besteht.
v Von WebSphere Remote Server 6.1 auf 6.2.x migrieren: Upgrade für eine vorhandene WebSphere Remote Server 6.1- oder 6.2.x-Laufzeitinstallation auf die
neueste Version der IBM Retail Store Server 7.0-Middlewareprodukte durchführen.
10
Anmerkung: Diese Task ist nur für Benutzer von DB2 sowie auf den unterstützten Migrationsplattformen verfügbar. Details hierzu finden Sie im
Abschnitt „Migration” auf Seite 29.
v IBM Retail Store Server-Lösungsentwicklungsumgebung installieren: Die
Lösungsentwicklungsumgebung besteht aus IBM Solution Assembly Toolkit
3.1.1.5, einem vollständigen Projektarbeitsbereich und den Installationsimages
für alle Middlewareprodukte.
IBM Retail Store Server-Basiskomponente
Typische Variablen
v Installationsverzeichnis: Der vollständig qualifizierte Pfadname, unter dem die
Imagedateien der IBM Retail Store Server-Basiskomponente installiert werden.
Erweiterte Variablen
v Hostaliasname: Der Hostaliasname, der für das Konfigurieren der Middlewarekomponenten verwendet werden soll.
DB2 Workgroup Server Edition
Linux-Installationen
Installationsimagedateien von DB2 installiert werden.
v Administrator-ID: Die Benutzer-ID, mit der eine Verbindung zu DB2 als DB2Administrator hergestellt wird. Dieser Benutzer wird erstellt, wenn er noch nicht
vorhanden ist. Diese Benutzer-ID darf nicht mit der ID für die Instanz und der
ID für den abgeschirmten Benutzer übereinstimmen.
v Administratorkennwort: Das Kennwort, das für den oben definierten DB2-Administrator verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss dieses Kennwort mit dem Kennwort des betreffenden Benutzers übereinstimmen.
Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v Instanzbenutzer-ID: Diese Benutzer-ID steuert alle DB2-Prozesse und ist der
Eigner aller Dateisysteme und Einheiten, die von den Datenbanken innerhalb
der Instanz verwendet werden. Dieser Benutzer wird erstellt, wenn er noch nicht
vorhanden ist. Diese Benutzer-ID darf nicht mit der Administrator-ID übereinstimmen.
v Instanzbenutzerkennwort: Das Kennwort, das für den oben definierten DB2Instanzbenutzer verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss
dieses Kennwort mit dem Kennwort des betreffenden Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort
erstellt.
v ID des abgeschirmten Benutzers: Der abgeschirmte Benutzer wird verwendet,
um benutzerdefinierte Funktionen (UDFs) und gespeicherte Prozeduren außerhalb des von der DB2-Datenbank verwendeten Adressraums auszuführen. Dieser
Benutzer wird erstellt, wenn er noch nicht vorhanden ist. Die ID des abgeschirmten Benutzers kann mit der Instanzbenutzer-ID identisch sein, eine solche
Übereinstimmung wird aber für Produktionssysteme nicht empfohlen.
v Kennwort des abgeschirmten Benutzers: Das Kennwort, das für den oben definierten abgeschirmten DB2-Benutzer verwendet wird. Wenn der Benutzer bereits
11
vorhanden ist, muss dieses Kennwort mit dem Kennwort des betreffenden
Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v Soll die DB2-Steuerzentrale installiert werden?: Bei Auswahl dieser Option
wird die DB2-Steuerzentrale installiert.
v Spracheingabeaufforderungen für Portugiesisch (Brasilien), vereinfachtes Chinesisch, Deutsch, Französisch, Spanisch, Italienisch, Japanisch, Koreanisch,
traditionelles Chinesisch, Dänisch, Finnisch, Norwegisch, Polnisch, Russisch,
Schwedisch (’Sprachunterstützung für gewünschte_Sprache zusätzlich zu den
anderen angegebenen Sprachen installieren.’): Installiert diese Sprachunterstützung zusätzlich zu den anderen angegebenen Sprachen. Englisch ist immer
installiert.
Windows-Installationen
Installationsimagedateien von DB2 installiert werden.
v DB2-Administrator-ID: Die Benutzer-ID, mit der eine Verbindung zu DB2 als
DB2-Administrator hergestellt wird. Dieser Benutzer wird erstellt, wenn er noch
nicht vorhanden ist.
v DB2-Administratorkennwort: Das Kennwort, das für den oben definierten DB2Administrator verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss
dieses Kennwort mit dem Kennwort des betreffenden Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort
erstellt.
v Kennwort überprüfen: Überprüft das im vorangegangenen Feld definierte DB2
Administratorkennwort.
v Soll die DB2-Steuerzentrale installiert werden?: Bei Auswahl dieser Option
wird die DB2-Steuerzentrale installiert.
v Direktaufrufe für das Startmenü erstellen?: Bei Auswahl dieser Option werden
Direktaufrufe für verschiedene DB2-Funktionen im Menü ’Start’ von Windows
erstellt.
v Spracheingabeaufforderungen für Portugiesisch (Brasilien), vereinfachtes Chinesisch, Deutsch, Französisch, Spanisch, Italienisch, Japanisch, Koreanisch,
traditionelles Chinesisch, Dänisch, Finnisch, Norwegisch, Polnisch, Russisch,
Schwedisch (’Sprachunterstützung für gewünschte_Sprache zusätzlich zu den
anderen angegebenen Sprachen installieren.’): Installiert diese Sprachunterstützung zusätzlich zu den anderen angegebenen Sprachen. Englisch ist immer
installiert.
IBM Informix Dynamic Server Workgroup Edition
Linux-Installationen
Installationsimagedateien von Informix Dynamic Server installiert werden.
v Kennwort für Informix Dynamic Server-Benutzer: Dies ist der Benutzer mit der
Kontoberechtigung für die Informix Dynamic Server-Instanz.
v Kennwort überprüfen: Überprüft Ihr im vorangegangenen Feld eingegebenes
Benutzerkennwort.
v Basisserver: Der zentrale Datenbankserver für DBA-Basisoperationen ohne optionale Erweiterungen, Bibliotheken oder Dienstprogramme.
v Client SDK Version 3.00: Das IBM Informix Client Software Developer’s Kit
(Client SDK) umfasst mehrere Anwendungsprogrammierschnittstellen (APIs),
12
mit denen Entwickler Anwendungen für Informix-Datenbankserver in ESQL, C
und Java™ schreiben können. Sie können auch Informix-ESQL/C-Anwendungen
für den DB2-Datenbankserver schreiben. IBM Informix Connect enthält die
Laufzeitbibliotheken der APIs im Client-SDK.
v IConnect version 3.00: IBM Informix Connect enthält die Laufzeitbibliotheken
der APIs im Client-SDK. Wenn Sie sich für die Installation des Client-SDK entscheiden, wird IConnect nicht installiert.
v Datenbankservererweiterungen: Datenbankverwaltungsprogramme und
Programmierungserweiterungen.
v J/Foundation: Schreiben von benutzerdefinierten Routinen in der Programmiersprache Java.
v Integrierte DataBlade-Module: Ausführen von Tasks, wie beispielsweise Verwaltung der Speicherposition großer Objekte (LOB), MQ-Transaktionsunterstützung,
XML-Veröffentlichung und Unterstützung binärer benutzerdefinierter Typen.
v Unterstützung für Konvertierung und Zurücksetzung: Framework, das für die
Migration von anderen Versionen und auf andere Versionen des Datenbankservers erforderlich ist.
v Komponente für die XML-Veröffentlichung: Enthält eine Reihe von Funktionen
für die Veröffentlichung von SQL-Abfragen im XML-Format.
v Globale Sprachenunterstützung: Die Komponentendateien für die Unterstützung von Sprachen, länderspezifischen Konventionen und codierten Zeichensätzen. Diese Dateien sind nicht erforderlich, wenn Ihre Standardlocale amerikanisches Englisch verwendet; hierbei handelt es sich um die voreingestellte
Sprache in IDS, wenn keine globale Sprachenunterstützung installiert ist.
v West-Europa sowie Nord- und Südamerika: Locales für Dänisch, Niederländisch, Englisch, Finnisch, Französisch, Deutsch, Isländisch, Italienisch, Norwegisch, Portugiesisch, Spanisch und Schwedisch.
v Osteuropäisch und Kyrillisch: Locales für Tschechisch, Polnisch, Russisch und
Slowakisch.
v Chinesisch: Locales für traditionelles Chinesisch und vereinfachtes Chinesisch.
v Japanisch: Locales für Japanisch.
v Koreanisch: Locales für Koreanisch.
v Sonstige: Sonstige Locales.
v Backup und Restore: Dienstprogramme für das Backup und den Restore von
Datenbankserverdaten.
v OnBar-Dienstprogramme: OnBar ist ein editierbares Shell-Script unter UNIX®
und eine Stapeldatei unter Windows (onbar.dat) zum Starten des OnBar-Treibers.
Verwenden Sie das OnBar-Script bzw. die OnBar-Stapeldatei sowie die zugehörigen Befehle, um Backup- und Restoreoperationen anzupassen und die Speichermanagerversion zu überprüfen.
v Informix-Schnittstelle für Tivoli Storage Manager: Implementieren der XSBAFunktionen, die Tivoli Storage Manager mit OnBar verwenden.
v Informix Storage Manager: Verwalten externer Speichereinheiten und Datenträger, die Backups enthalten.
v Dienstprogramm ’archecker’: Prüfen von Backups und Wiederherstellen von
Teilen einer Datenbank, von Tabellen, von Teilen einer Tabelle oder von einer
Gruppe von Tabellen.
v Demos: Demonstrationsdatenbanken und Beispiele.
v Dienstprogramme für das Laden von Daten: Effizientes Laden und Entladen
von Daten in bestimmten Konfigurationen.
13
v Dienstprogramme für das Entladen und Laden: Entladen von Daten aus einer
Datenbank und anschließendes Laden dieser Daten in eine Datenbank.
v Dienstprogramm ’dbload’: Laden von Daten in Datenbanken oder Tabellen, die
mit IBM Informix-Produkten erstellt wurden. Verwenden Sie das Dienstprogramm ’dbload’ dazu, Daten von einer oder mehreren Textdateien in eine
oder mehrere vorhandene Tabllen zu übertragen.
v High-Performance Loader (HPL): Effizientes Laden und Entladen großer Datenmengen in eine oder aus einer Datenbank.
v Unternehmensweite Replikation: Replizieren von Daten zwischen IBM Informix
Dynamic Server-Datenbankservern.
v Verwaltungsdienstprogramme: Zusätzliche Komponentengruppen für
Verwaltungsdienstprogramme.
v Dienstprogramme für die Leistungsüberwachung: Überwachen der Leistung
mit den Dienstprogrammen ’onmonitor’ und ’onperf’.
v Sonstige Überwachungsdienstprogramme: Anzeigen des logischen Protokolls
mithilfe des Dienstprogramms ’onlog’ oder Verwalten des Datenbankservers mit
SNMP mithilfe des Dienstprogramms ’onsnmp’.
v Prüfdienstprogramme: Verwalten von Prüfmasken, Prüflisten und weiteren
Prüfinformationen zum Datenbankserver mithilfe der Dienstprogramme
’onaudit’ und ’onshowaudit’.
v Datenbankimport- und -exportdienstprogramme: Entladen einer Datenbank in
eine Textdatei; Erstellen und Füllen einer Datenbank aus diesen Textdateien; Entladen eines Datenbankschemas in eine Textdatei.
v Rollentrennung: Wählen Sie Yes aus, um die Rollentrennung zu aktivieren oder
wählen Sie No aus, um sie zu inaktivieren.
v DBSA-Gruppenaccount: Gruppe für allgemeine Verwaltungsaufgaben.
(Verwaltungsrolle für das Datenbanksystem). Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Gruppe der Datenbanksicherheitsbeauftragten: Gruppe der
Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Nur
anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Gruppe der Prüfungsbeauftragten: Gruppe der Prüfungsbeauftragten für Prüfungsverwaltungsaufgaben. (Rolle des Beauftragten für die
Prüfungsanalyse). Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Benutzergruppe: Gruppe für Datenbankbenutzer. Nur
v Demo erstellen: Auswahlstatus des Demonstrationsdatenbankservers. Wählen
Sie create aus, um anzugeben, dass der Demonstrationsdatenbankserver erstellt
werden soll. Wählen Sie nocreate aus, um anzugeben, dass der Demonstrationsdatenbankserver nicht erstellt werden soll.
v Bereits vorhandene Datei ’onconfig’: Gibt an, ob eine bereits vorhandene Datei
’onconfig’ für die Konfiguration des Demonstrationsdatenbankservers verwendet
werden soll. Wählen Sie yes aus, wenn eine vorhandene Datei ’onconfig’ verwendet werden soll. Wählen Sie no aus, um individuell angegebene Werte zu
verwenden. Wenn für diesen Wert yes festgelegt ist, müssen Sie im Pfadargument der Datei ’onconfig’ eine Datei angeben.
v Pfad der bereits vorhandenen Datei ’onconfig’: Gibt den Pfad der zu verwendenden Datei ’onconfig’ an. Dieses Feld ist nur erforderlich, wenn Sie yes im
Feld Pfad der bereits vorhandenen Datei ausgewählt haben.
v Servername: Der Datenbankservername für die Demonstrationsdatenbankinstanz.
14
v Servernummer: Der Wert für den Demonstrationsdatenbankserver. Gültige
Werte sind ganze Zahlen zwischen 0 und 255.
v Rootpfad: Vollständiger Pfad für den Speicherbereich des Rootdatenbankbereichs für den IDS-Demonstrationsdatenbankserver.
v Größe des Rootdatenbankbereichs: Die Größe des Rootdatenbankbereichs für
den Demonstrationsdatenbankserver.
v Pufferpool: Vom Standardwert abweichende Pufferpoolinformationen für den
Demonstrationsdatenbankserver.
v Anzahl der virtuellen Prozessoren der CPU: Anzahl der virtuellen Prozessoren
der CPU, die für den Demonstrationsdatenbankserver konfiguriert werden sollen.
v Terminalauswahl: Das Terminal, das nach einer erfolgreichen Installation und
Erstellung der Demonstrationsdatenbankinstanz gestartet werden soll. Bei der
Auswahl von other muss für Manual Terminal Input das von Ihnen
gewünschte Terminal angegeben werden.
v Manuelle Terminaleingabe: Das Terminal, das Sie verwenden wollen. Beispiel:
Um ’xterm’ mit der Option für manuelle Eingabe zu starten, verwenden Sie den
folgenden Befehl: /usr/bin/xterm
Windows-Installationen
Installationsimagedateien von Informix Dynamic Server installiert werden.
v Kennwort für Informix Dynamic Server-Benutzer: Dies ist der Benutzer mit der
Kontoberechtigung für die Informix Dynamic Server-Instanz.
Benutzerkennwort.
v Rollentrennung aktivieren: Wählen Sie Yes aus, um die Rollentrennung zu aktivieren, oder wählen Sie No aus, um sie zu inaktivieren.
v DBSA-Gruppenaccount: Gruppe für allgemeine Verwaltungsaufgaben.
(Verwaltungsrolle für das Datenbanksystem). Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Gruppenaccount: Gruppe der Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Nur anwendbar, wenn
die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Benutzeraccount: Datenbanksicherheitsbeauftragter
für Sicherheitsaufgaben auf Systemebene. Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Benutzerkennwort: Benutzerkennwort des Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Nur
Benutzerkennwort. Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - AAO-Gruppenaccount: Gruppe der Prüfungsbeauftragten für
Prüfungsverwaltungsaufgaben. (Rolle des Beauftragten für die Prüfungsanalyse).
Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - AAO-Benutzeraccount: Prüfungsbeauftragter für Prüfungsverwaltungsaufgaben. (Rolle des Beauftragten für die Prüfungsanalyse). Nur
v Rollentrennung - AAO-Benutzerkennwort: Benutzerkennwort für Prüfungsbeauftragte für Prüfungsverwaltungsaufgaben. Nur anwendbar, wenn die
Rollentrennung aktiviert ist.
15
Benutzerkennwort. Nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Benutzergruppe: Gruppe für Datenbankbenutzer. Nur
v Servername: Der Datenbankservername identifiziert den Datenbankserver für
Clientanwendungen. In den meisten Fällen können Sie den Standardwert auswählen.
v Server initialisieren?: Wenn Sie Ja auswählen, gehen alle vorhandenen Daten
verloren.
v Servicename: Der Name des Service (Windows-Dienstes) für die Informix Dynamic Server-Datenbankinstanz. Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v Port: Geben Sie die Portnummer für das TCP/IP-Protokoll an. Die Portnummer
gibt den Porteintrag für den Datenbankserver in der Registrierdatenbank ″sqlhosts″ an. Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v Servernummer: Die Datenbankservernummer identifiziert einen Datenbankserver eindeutig, falls mehrere Instanzen des Datenbankservers installiert sind.
Wenn nur eine Instanz der Datenbank installiert ist, legen Sie für diese Nummer
den Wert ’0’ fest. Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v DBSpace-Name: Ein Datenbankbereich (DBSpace) ist eine logische Gruppe von
Chunks, denen Datenbanken und Tabellen zugeordnet sind. Nur zutreffend,
wenn Server initialisieren ausgewählt ist.
v DBSpace-Primärdatenposition: Speicherposition für den Datenbankbereich
(DBSpace). Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v DBSpace-Größe: Größe des Datenbankbereichs (DBSpace) in Megabyte. Nur
zutreffend, wenn Server initialisieren ausgewählt ist.
v SBSpace-Name: Ein SBSpace ist ein logischer Speicherbereich, den der
Datenbankserver dazu verwendet, intelligente große Objekte (CLOB- und BLOBDaten) zu speichern. Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v SBSpace-Primärdatenposition: Speicherposition des SBSpace. Nur zutreffend,
wenn Server initialisieren ausgewählt ist.
v SBSpace-Größe: Größe des SBSpace in Megabyte. Nur zutreffend, wenn Server
initialisieren ausgewählt ist.
v SBSpace-Seitengröße: Die SBSpace-Seitengröße sollte in etwa der Größe des am
häufigsten vorkommenden intelligenten großen Objekts im SBSpace entsprechen.
Der Standardwert ist eine Seite. Nur zutreffend, wenn Server initialisieren ausgewählt ist.
v JDBC-Treiber installieren?: Mit dem JDBC-Treiber können Java-Programmierer
von Java-Anwendungen oder -Applets aus auf Datenbanken zugreifen.
v Informix Connect installieren?: Informix Connect enthält die Laufzeitbibliotheken der APIs im Client-SDK.
v Client Software Developer’s Kit (CSDK) installieren?: Dieses SDK enthält eine
Reihe von Anwendungsprogrammierschnittstellen (APIs), mit denen Entwickler
Anwendungen für Datenbankserver schreiben können.
v DataBlade Developer’s Kit installieren?: Dieses Entwicklerkit enthält Tools zum
Entwickeln und Packen von DataBlade-Modulen.
v BladeManager installieren?: Mit BladeManager können neue DataBlade-Module
in Informix-Datenbanken registriert werden.
v ClusterIt installieren?: Dienstprogramm für die Clusterkonfiguration.
16
WebSphere MQ
Felder, die mit der Markierung Linux oder Windows versehen sind, stehen nur für
die Installation auf der entsprechenden Plattform zur Verfügung.
Kennwort für Benutzer mqm: Das Kennwort, das für den Benutzer
v
mqm verwendet wird.
Kennwort überprüfen: Überprüft Ihr im vorangegangenen Feld einv
gegebenes Benutzerkennwort.
Installationsverzeichnis: Der vollständig qualifizierte Pfadname,
v
unter dem die Installationsimagedateien von IBM WebSphere MQ installiert werden.
v Möchten Sie MQ Explorer installieren?: Bei Auswahl dieser Option wird
WebSphere MQ Explorer installiert.
Spracheingabeaufforderungen für Portugiesisch (Brasilien), vereinv
fachtes Chinesisch, Deutsch, Französisch, Spanisch, Italienisch, Japanisch,
Koreanisch, traditionelles Chinesisch: (’Sprachunterstützung für <gewünschte
Sprache> zusätzlich zu den anderen angegebenen Sprachen installieren.’): Installiert diese Sprachunterstützung zusätzlich zu den anderen angegebenen Sprachen. Englisch ist immer installiert.
WebSphere Application Server Network Deployment
Installationsimagedateien von IBM WebSphere Application Server Network
Deployment installiert werden.
Konfiguration des WebSphere Application Server-Standalone-Profils
Typische Variablen
v Name des WebSphere Application Server-Profils: Der Name des zu erstellenden Profils. Der Profilname muss für diese IBM WebSphere Application ServerInstallation eindeutig sein.
v Knotenname: Der Knotenname für WebSphere Application Server. Der Knotenname muss innerhalb einer Zelle eindeutig sein.
v Verwaltungssicherheit aktivieren: Ist diese Option auf ’true’ (wahr) gesetzt,
müssen sich Benutzer anmelden, wenn sie auf WebSphere-Verwaltungstools
zugreifen. Ein Benutzer mit Verwaltungsaufgaben und das zugehörige Kennwort
sind erforderlich, wenn diese Option aktiviert ist.
v Benutzer mit Verwaltungsaufgaben: Bei der Verwendung der Verwaltungssicherheit erforderlich: Benutzer-ID für den Zugriff auf WebSphere Application
Server-Verwaltungstools.
v Kennwort für Benutzer mit Verwaltungsaufgaben: Bei der Verwendung der
Verwaltungssicherheit erforderlich: Kennwort für den Zugriff auf WebSphere
Application Server-Verwaltungstools.
Kennwort für Benutzer mit Verwaltungsaufgaben.
v WebSphere für die Ausführung als Service aktivieren: Ist diese Option auf
’true’ gesetzt, wird WebSphere Application Server für die Ausführung als Service
konfiguriert.
v Zellenname: Der Zellenname für das zu erstellende Profil.
17
v Port für den HTTP-Transport: Der für den HTTP-Transport zum Anwendungsserver verwendete Port. Dieser Port wird primär zur Kommunikation mit dem
Web-Server genutzt.
v Port für den HTTPS-Transport: Der für den HTTPS-Transport zum
Anwendungsserver verwendete Port. Dieser Port wird primär zur Kommunikation mit dem Web-Server genutzt.
v Port für die Verwaltungskonsole: Dieser Port wird für den Zugriff auf die
Anwendung der Verwaltungskonsole verwendet.
v Sicherer Port für die Verwaltungskonsole: Dieser Port wird für den sicheren
Zugriff auf die Anwendung der Verwaltungskonsole verwendet.
v Port für das Bootprogramm: Der Port für das Bootprogramm wird in Clusterumgebungen mit Anwendungsservern verwendet.
v Port für die administrative Interprozesskommunikation: Der Port für den JMXConnector, der am Loopback-Adapter empfangsbereit ist.
v Listener-Port für SAS-Serverauthentifizierung: Port für das SAS-Authentifizierungsprotokoll (Secure Authentication Service). Dieser Port wird zur Kommunikation mit 6.0.x-Servern verwendet, die in eine 6.1-Zelle eingebunden sind.
v SOAP-Connector-Port: Port für SOAP-Verbindungen. SOAP ist ein Protokoll,
das bei der verteilten Datenverarbeitung eingesetzt wird.
v Listener-Port für CSIv2-Serverauthentifizierung: Port für das CSIv2-Serverauthentifizierungsprotokoll (Common Security Interoperability Version 2).
v Listener-Port für CSIv2-Clientauthentifizierung: Port für das CSIv2-Clientauthentifizierungsprotokoll (Common Security Interoperability Version 2).
v ORB-Listener-Port: Der Object-Request-Broker verwendet diesen Port zur Bereitstellung von Services für die verteilte Datenverarbeitung über IIOP (Internet
InterORB Protocol).
v Kommunikationsport für High Availability Manager: High Availability Manager verwendet diesen Port zur Kommunikation mit anderen WebSphere Application Server-Installationen, die Teil derselben Hochverfügbarkeitsgruppe sind.
v Service-Integration-Port: Dieser Port wird zur Kommunikation mit dem Nachrichtenübertragungsservice über den Service-Integration-Bus verwendet. Der Service-Integration-Bus nutzt den JMS-Standard (Java Message Service).
v Sicherer Service-Integration-Port: Dieser Port wird zur sicheren Kommunikation
mit dem Nachrichtenübertragungsservice über den Service-Integration-Bus verwendet. Der Service-Integration-Bus nutzt den JMS-Standard (Java Message Service).
v Port für den MQ-Transport: Der für die Kommunikation mit WebSphere MQServern genutzte Port.
v Sicherer Port für den MQ-Transport: Der für die sichere Kommunikation mit
WebSphere MQ-Servern genutzte Port.
v SIP-Container-Port: Der vom SIP-Container (Session Initiation Protocol) für die
Verarbeitung von SIP-Anforderungen verwendete Port.
v Sicherer SIP-Container-Port: Der vom SIP-Container (Session Initiation Protocol)
für die Verarbeitung von SIP-Anforderungen über HTTPS verwendete Port.
IBM HTTP Server
Installationsimagedateien von IBM HTTP Server installiert werden.
v HTTP-Port: Geben Sie den von IBM HTTP Server verwendeten Standardport an.
v Port des Verwaltungsservers: Geben Sie den vom Verwaltungsserver verwendeten Standardport an.
18
v IBM HTTP Server-Plug-in für WebSphere Application Server installieren?:
Geben Sie an, ob das WebSphere Application Server-Plug-in installiert werden
soll.
Felder für die Installation der Entwicklungsumgebung
Tasks auswählen - Installationstyp auswählen
Im Fenster ’Tasks auswählen - Installationstyp auswählen’ werden Sie dazu aufgefordert, den Installationstyp anzugeben, den Sie ausführen:
v Solution Assembly Toolkit 3.1.1.5 installieren: Dieses Toolkit bietet eine vollständige und Eclipse-basierte integrierte Entwicklungsumgebung mit dem
Express Runtime Developer-Plug-in.
v WebSphere sMash 1.1.0.1 installieren: Informationen zu dieser Option finden Sie
im Abschnitt „WebSphere sMash” auf Seite 50.
v IBM Retail Store Server 7.0-Arbeitsbereich installieren: Installiert den Arbeitsbereich und die Implementierungspakete für IBM Retail Store Server 7.0. Der
Arbeitsbereich enthält den Code und alle Projekte, die zum Entwickeln von
angepassten Lösungen mit IBM Retail Store Server benötigt werden. Die
Implementierungspakete enthalten alle Installationsmedien für die Middlewareprodukte, auf denen IBM Retail Store Server basiert. Der Arbeitsbereich und die
Implementierungspakete für Windows können auch auf einem Linux-basierten
Entwicklungsserver installiert werden, um die plattformübergreifende Entwicklung zu ermöglichen. Ebenso können der Arbeitsbereich und die Implementierungspakete für Linux auch auf einem Windows-basierten Entwicklungsserver
installiert werden.
IBM Retail Store Server-Basiskomponente
Typische Variablen
Imagedateien der IBM Retail Store Server-Basiskomponente installiert werden.
v Hostaliasname: Der Hostaliasname, der für das Konfigurieren der Middlewarekomponenten verwendet werden soll.
Solution Assembly Toolkit
Imagedateien von Solution Assembly Toolkit installiert werden.
WebSphere sMash
Imagedateien von WebSphere sMash installiert werden.
IBM Retail Store Server-Arbeitsbereichskomponente
v Installationsverzeichnis: Der vollständig qualifizierte Pfadname, unter dem der
Arbeitsbereich von IBM Retail Store Server installiert wird.
Unbeaufsichtigte Installation
In diesem Thema wird beschrieben, wie die unbeaufsichtigte Installation des Produkts durchgeführt wird.
Sie müssen die Musterantwortdatei für Ihre Entwicklungsumgebung anpassen,
bevor Sie die unbeaufsichtigte Installation durchführen. In der Musterdatei sind
19
auch Anweisungen zum Anpassen der Datei vorhanden. Nach dem Anpassen der
Datei können Sie den Befehl absetzen, mit dem die unbeaufsichtigte Installation
durchgeführt wird. Die unbeaufsichtigte Installation ist insbesondere nützlich,
wenn Sie Ihr Produkt häufig installieren oder wenn Sie von einer fernen Eingabeaufforderung aus installieren.
Führen Sie die folgenden Anweisungen aus, um das Installationsprogramm in
unbeaufsichtigtem Modus auszuführen.
1. Wählen Sie die Musterantwortdatei für die gewünschte Installation aus. Die
Musterantwortdatei hat den Namen taskList.xml und befindet sich im Verzeichnis tasks der Ihrem Betriebssystem entsprechenden WebSphere Remote ServerDVD.
Anmerkung: Ändern Sie nicht den Wert der Eigenschaft <taskNumber> in der
Datei taskList.xml, sonst schlägt die Installation fehl.
2. Bearbeiten Sie die Datei IRU_install.iss. Bei dieser Datei handelt es sich um die
Antwortdatei für Deployment Wizard.
a. Öffnen Sie die Datei IRU_install.iss, die sich im Rootverzeichnis der Ihrem
Betriebssystem entsprechenden WebSphere Remote Server-DVD befindet.
b. Legen Sie für die Installation den unbeaufsichtigten Modus fest, indem Sie
in die Datei -silent eingeben.
c. Legen Sie -G licenseAccepted=true fest, um die Lizenzvereinbarung zu
akzeptieren.
d. Geben Sie an, welche Taskdatei verwendet werden soll: -W
solutionLauncher.taskFileName="unbeaufsichtigt_name_der_antwortdatei"
Anmerkung: Die Variable unbeaufsichtigt_name_der_antwortdatei gibt den
Namen der Musterantwortdatei an. Schließen Sie nicht den
Pfad der Datei ein.
3. Sie haben zwei Möglichkeiten, um das Installationsprogramm in unbeaufsichtigtem Modus zu starten.
v Verwenden Sie die Datei IRU_install.iss im Stammverzeichnis der DVD.
Wenn Sie diese Option auswählen, dürfen Sie in der Befehlszeile nicht
-options angeben.
WindowsSetup.exe IRU_install.iss
LinuxSetup IRU_install.iss
v Verwenden Sie die Datei IRU_install.iss aus einer anderen Speicherposition.
Wenn Sie diese Option auswählen, dürfen Sie die Datei IRU_install.iss im
Stammverzeichnis der DVD nicht bearbeiten. Mit der Variable pfad wird die
Verzeichnisposition der Datei IRU_install.iss angegeben.
WindowsSetup.exe -options "pfad\IRU_install.iss"
LinuxSetup -options "pfad/IRU_install.iss"
4. Prüfen Sie die Protokolle, um festzustellen, ob die Installation erfolgreich war.
Wenn an dieser Position Protokolldateien vorhanden sind, ist die unbeaufsichtigte Installation abgeschlossen:
C:\Program Files\SolutionFiles\logs
/opt/SolutionFiles/logs
Wenn in den Protokolldateien Fehler aufgetreten sind, lesen Sie den Abschnitt
„Fehlerbehebung, Tipps” auf Seite 80, um mögliche Problemlösungen zu finden.
20
Installation prüfen
In diesem Abschnitt wird beschrieben, wie Sie prüfen können, ob die einzelnen
Softwarepakete korrekt installiert wurden und ordnungsgemäß funktionieren.
Die Schritte zum Überprüfen der Installation der einzelnen Softwarepakete bzw.
Anwendungen werden in den folgenden Abschnitten angegeben. Die Prüfung der
Installation ist optional.
Anmerkung: Es empfiehlt sich, vor dem Überprüfen der Produktinstallation die
Fixpacks für Middlewareprodukte zu installieren.
Installationsprotokolldateien
Während der Installation der einzelnen Middlewareprodukte werden jeweils
Protokolldateien erstellt. Überprüfen Sie anhand dieser Protokolle, ob die Installation erfolgreich ausgeführt wurde.
Die Installationsprotokolldateien befinden sich in den folgenden Verzeichnissen:
v SIF_HOME\logs
v %TEMP%\logs
v C:\Program Files\SolutionFiles\logs
v SIF_HOME/logs
v /tmp/logs
v /opt/SolutionFiles/logs
WebSphere Application Server prüfen
Die Installation von WebSphere Application Server wurde bereits während des
Installationsprozesses mithilfe der Scripts ivt.bat und ivt.sh geprüft.
WebSphere MQ prüfen
In diesem Abschnitt wird beschrieben, welche Schritte ausgeführt werden müssen,
um die Installation von IBM WebSphere MQ zu prüfen.
Dieses Softwarepaket erstellt Benutzer und Gruppen, die der Anwendung
WebSphere MQ zugeordnet sind. Die folgenden Anweisungen unterstützen Sie
beim Erstellen, Starten, Beenden und Löschen eines Warteschlangenmanagers mit
dem Namen ″QM1″.
v Unter Linux:
1. Melden Sie sich beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
2. Geben Sie den folgenden Befehl ein, um zu dem Benutzer ″mqm″ zu wechseln. Dabei handelt es sich um den Benutzer, der vom Installationsscript
erstellt wurde:
su - mqm
3. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager mit
dem Namen ″QM1″ zu erstellen:
crtmqm QM1
21
4. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager zu
starten:
strmqm QM1
5. Geben Sie die folgenden Befehle ein, um den Warteschlangenmanager zu
beenden:
endmqm -i QM1
löschen:
dltmqm QM1
7. Melden Sie sich bei dem Filialsystem ab und schließen Sie alle Fenster.
v Unter Windows:
1. Öffnen Sie die Eingabeaufforderung.
2. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager mit
dem Namen ″QM1″ zu erstellen:
crtmqm QM1
starten:
strmqm QM1
4. Geben Sie die folgenden Befehle ein, um den Warteschlangenmanager zu
beenden:
endmqm -i QM1
löschen:
dltmqm QM1
6. Schließen Sie die Eingabeaufforderung.
IBM HTTP Server prüfen
Die Installation von IBM HTTP Server wurde bereits vom Installationsprogramm
geprüft, das die HTTP-Server stoppt und startet.
DB2 Workgroup Server Edition prüfen
In diesem Abschnitt wird beschrieben, welche Schritte ausgeführt werden müssen,
um die Installation von DB2 zu prüfen.
Um eine Datenbank zu erstellen und zu löschen, gehen Sie wie folgt vor:
1. Greifen Sie auf DB2 zu.
Linux
a. Melden Sie sich beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
b. Geben Sie den folgenden Befehl ein, um zu dem Benutzer ″db2inst1″ zu
wechseln (einer der Benutzer, die vom Installationsscript erstellt wurden):
su - db2inst1
Windows
a. Öffnen Sie das DB2-Befehlsfenster (z. B. indem Sie execute db2cw ausführen).
2. Verwenden Sie das folgende Script, um eine Musterdatenbank zu erstellen: db2
create database test
3. Verwenden Sie das folgende Script, um eine Musterdatenbank zu löschen: db2
drop database test
22
Informix Dynamic Server prüfen
Gehen Sie wie in diesem Abschnitt beschrieben vor, um Ihre Informix Dynamic
Server-Installation unter Windows- oder Linux-Betriebssystemen zu überprüfen.
Prüfung unter Windows-Betriebssystemen
Durch das Installationsverfahren wird eine Stapeldatei dbservername.cmd erstellt,
die Werte für die Umgebungsvariablen festlegt. Diese Datei befindet sich in dem
Verzeichnis, in dem Informix Dynamic Server installiert wurde. Führen Sie die
Datei aus, bevor Sie eines der Informix Dynamic Server-Befehlszeilendienstprogramme ausführen. Der Standardname und die Position der Datei lauten:
C:\Program Files\IBM\SIF\IBM Informix Dynamic Server\11.50\
ol_svr_custom.cmd.
1. Führen Sie von einer Eingabeaufforderung aus die folgenden Befehle aus, um
eine Musterdatenbank zu erstellen:
cd informixInstallDir
dbservername.cmd
cd bin
dbaccess - create database sample1;
2. Führen Sie die folgenden Befehle aus, um eine Tabelle zu erstellen und zu
löschen:
Gehen Sie wie folgt vor, um eine Tabelle zu erstellen:
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Gehen Sie wie folgt vor, um Zeilen einzufügen und abzurufen:
insert into test values (123, "Hello", "My name is David");
insert into test values (456, "Bonjour", "Je m'appelle David");
select * from test;
a_number 123
a_string Hello
another_string My name is David
a_number 456
a_string Bonjour
another_string Je m'appelle David
Gehen Sie wie folgt vor, um die Tabelle zu löschen und die Verbindung zu
trennen:
drop table test;
disconnect all;
3. Führen Sie den folgenden Befehl aus, um die Datenbank zu löschen:
drop database 'sample1';
Prüfung unter Linux-Betriebssystemen
1. Melden Sie beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
2. Suchen Sie nach der folgenden Datei:
. /etc/profile.d/setInformixEnv.sh
$INFORMIXDIR/bin/dbaccess - >create database sample1;
3. Führen Sie die folgenden Befehle aus, um eine Tabelle zu erstellen und zu
löschen:
Gehen Sie wie folgt vor, um eine Tabelle zu erstellen:
23
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Gehen Sie wie folgt vor, um Zeilen einzufügen und abzurufen:
insert into test values (123, "Hello", "My name is David");
insert into test values (456, "Bonjour", "Je m'appelle David");
select * from test;
a_number 123
a_string Hello
another_string My name is David
a_number 456
a_string Bonjour
another_string Je m'appelle David
Gehen Sie wie folgt vor, um die Tabelle zu löschen und die Verbindung zu
trennen:
drop table test;
disconnect all;
4. Führen Sie den folgenden Befehl aus, um die Datenbank zu löschen:
drop database 'sample1';
WebSphere sMash prüfen
Gehen Sie wie in diesen Anweisungen beschrieben vor, um zu prüfen, ob
WebSphere sMash installiert wurde.
Um zu prüfen, ob WebSphere sMash installiert wurde, überprüfen Sie die Datei
install.log im WebSphere sMash-Installationsverzeichnis.
Um zu prüfen, ob IBM Reliable Transport Extension for WebSphere sMash installiert wurde, überprüfen Sie die Datei rte_install.log im selben Verzeichnis.
Deinstallation
Das IBM WebSphere Remote Server-Deinstallationsscript entfernt die gesamte
WebSphere Remote Server-Lösung, einschließlich IBM WebSphere Application Server, DB2 oder Informix Dynamic Server und IBM WebSphere MQ. Darüber hinaus
entfernt es alle Komponenten, die der Lösung durch Erweiterung von WebSphere
Remote Server möglicherweise hinzugefügt wurden.
WebSphere Remote Server deinstallieren
1. Stoppen Sie die komplette WebSphere Remote Server-Lösung, bevor Sie das
Deinstallationsprogramm ausführen.
Der Deinstallationsprozess ruft das Script wrsstop auf, es kann aber sein, dass
noch einige Komponenten der Lösung aktiv sind, wie z. B. die WebSphere MQWarteschlangenmanager.
2. Navigieren Sie zum Unterverzeichnis bin von SIF_HOME.
3. Führen Sie folgende Befehle aus:
cd %SIF_HOME%\bin
SifRemoveWRS.bat -noprompt [clean]
Der Befehl SifRemoveWRS.bat -noprompt -clean entfernt das Verzeichnis
SIF_HOME unter Windows nicht.
24
cd $SIF_HOME/bin
./SifRemoveWRS.sh -noprompt [clean]
Hinweise:
v -noprompt ist ein erforderlicher Parameter, der verhindert, dass Sie
WebSphere Remote Server unbeabsichtigt deinstallieren. Wird dieser
Parameter übergangen, wird WebSphere Remote Server nicht deinstalliert.
v -clean ist ein optionaler Parameter. Wenn -clean nicht angegeben ist,
werden lediglich die einzelnen Produktdeinstallationsprogramme aufgerufen. Wenn -clean angegeben ist, werden von den Produktdeinstallationsprogrammen zusätzliche Schritte zum Entfernen sämtlicher
Teile jedes Produkts ausgeführt. Es werden z. B. Installationsverzeichnisse gelöscht, erstellte Benutzer werden gelöscht und so
weiter.
Option clean verwenden
Wenn Sie eine vollständige Deinstallation durchführen, werden alle WebSphere
Remote Server-Dateien gelöscht, möglicherweise bleiben jedoch noch einige leere
Verzeichnisse vorhanden. Diese leeren Verzeichnisse können problemlos entfernt
werden.
Anmerkung: Es empfiehlt sich, dass Sie die Option clean verwenden, wenn Sie
Informix Dynamic Server deinstallieren. Jedoch können trotz einer
vollständigen Deinstallation bei der erneuten Installation von Informix Dynamic Server Probleme auftreten. Weitere Informationen finden Sie im Abschnitt „Fehlerbehebung, Tipps” auf Seite 80.
Die Option clean führt die folgenden Tasks aus:
v Windows:
– cmd /c net user MUSR_MQADMIN /DELETE
– cmd /c net localgroup mqm /DELETE
– Löscht den Ordner C:\DB2
– cmd /c net user DB2ADMIN /DELETE
v Linux:
– rpm -qa | grep WSBAA | xargs -i rpm -e {}
– rpm -qa | grep WSBAA | xargs -i rpm -e {} --nodeps --justdb
– rpm -qa | grep WSPAA | xargs -i rpm -e {}
– rpm -qa | grep WSPAA | xargs -i rpm -e {} --nodeps --justdb
– rm -rf /root/.WASRegistry
– rm -rf /opt/.ibm/.nifregistry
– rm -rf /opt/.ibm
– rpm -qa | grep MQSeries | grep -v 7.0.0-1 | xargs -i rpm -e {}
– rpm -qa | grep MQSeries | grep -v Runtime-7.0.0-1 | xargs -i rpm -e {}
– rpm -e MQSeriesRuntime-7.0.0-1
– rm -rf /var/mqm
– rm -rf /opt/IBM/mqm
– rm -rf /opt/mqm
25
–
–
–
–
–
rpm -qa | grep DB2 | xargs -i rpm -e {}
rm -rf /var/db2
rpm -qa | grep DB2 | xargs -i rpm -e {} --nodeps --justdb
userdel db2inst1
userdel db2fenc1
–
–
–
–
–
–
–
userdel dasusr1
userdel mqm
groupdel mqm
groupdel mqbrkrs
groupdel dasadm1
groupdel db2iadm1
groupdel db2fadm1
– rm -rf /home/db2inst1 /home/db2fenc1 /home/dasusr1 /home/mqm
v Windows und Linux:
– Löscht das WRS-Basisinstallationsverzeichnis
– rd /s /q IFMXDATA
– rd /s /q ISM
– Entfernt alle Zeilen, die mit WSBAA, WSPAA oder WHIHS beginnen,
aus Ihrer Datei vpd.properties. Die Windows-Datei befindet sich in
%SYSTEMROOT%\vpd.properties, die Linux-Datei befindet sich in
/root/vpd.properties.
– Löscht das WebSphere Application Server-Installationsverzeichnis.
– Löscht das IBM HTTP Server-Installationsverzeichnis.
– Löscht das WebSphere MQ-Installationsverzeichnis.
– Löscht das DB2-Installationsverzeichnis.
– Löscht das Informix Dynamic Server-Installationsverzeichnis.
Deinstallationsprozess erweitern
Wenn Sie die WebSphere Remote Server-Lösung erweitern, können Sie Deinstallationsbefehle in den Metadaten für die hinzuzufügende Anwendung hinzufügen. Das
Deinstallationsscript führt alle Deinstallationen der Benutzeranwendung aus, bevor
es die WebSphere Remote Server-Middlewareprodukte deinstalliert.
Nach Deinstallation erneut installieren
Wenn Sie WebSphere Remote Server nach einer Deinstallation des Produkts erneut
installieren wollen, ändern Sie die Installationsverzeichnisse für WebSphere Application Server und IBM HTTP Server, um zu verhindern, dass die erneute Installation fehlschlägt.
Die erneute Installation von Informix Dynamic Server nach einer nicht vollständigen Deinstallation wird nicht unterstützt. Weitere Informationen finden Sie im
Abschnitt „Fehlerbehebung, Tipps” auf Seite 80.
26
Kapitel 3. Aktualisierung oder Migration durchführen
In diesem Abschnitt werden die Schritte beschrieben, die Sie für eine erfolgreiche
Aktualisierung oder Migration von IBM WebSphere Remote Server ausführen müssen.
Aktualisierungsstrategie
Es wird empfohlen, dass IBM WebSphere Remote Server mit einer einheitlichen
Aktualisierungslösung aktualisiert wird.
Bei dieser Methode können Sie Programmkorrekturen (Fixes) für die Middleware,
Anwendungen und Betriebssysteme zu einem einzelnen Paket für eine reibungslosere Migration kombinieren. WebSphere Remote Server bietet zwei einheitliche
Lösungen für die Migration von Vorgängerreleases, die lokal über eine grafische
Benutzerschnittstelle installiert werden können. Die Lösungen werden im Abschnitt
„Migration” auf Seite 29 beschrieben.
Wenn Sie Ihre eigene Aktualisierungslösung erstellen wollen, führen Sie die
Schritte für die Erstellung einer Lösung im Abschnitt Kapitel 5, „Erweiterung”, auf
Seite 49 aus. Für die Erstellung der Lösung benötigen Sie die WebSphere Remote
Server-Entwicklungsumgebung. Wenn Sie Aktualisierungen für IBM Produkte
benötigen, die nicht in der WebSphere Remote Server-Entwicklungsumgebung enthalten sind, müssen Sie diese von der Website ’http://www.ibm.com/support’ herunterladen und neue Anwendungsprojekte erstellen. Anwendungsprojekte werden
im Abschnitt Kapitel 5, „Erweiterung”, auf Seite 49 beschrieben.
Halten Sie sich bei der Erstellung einer Aktualisierungslösung an die folgenden
Richtlinien:
v Löschen Sie die nicht benötigten Dateien aus den Paketen. Wenn das Paket für
Windows-Betriebssysteme bestimmt ist, schließen Sie keine ausschließlich für
Linux-Betriebssysteme erforderlichen Dateien ein.
v Beschränken Sie die Eingabeanzeigen der Benutzerschnittstelle. WebSphere
Remote Server stellt Dienstprogramme zur Verfügung, die über das Programm
ermitteln, wo IBM Middleware installiert ist.
WebSphere Remote Server-Fixpacks und vorläufige Fixes
IBM WebSphere Remote Server stellt bei Bedarf Fixpacks oder vorläufige Fixes zur
Verfügung. Fixpacks von WebSphere Remote Server werden normalerweise als
Lösungen bereitgestellt, die mithilfe von Solution Assembly Toolkit entwickelt wurden. Vorläufige Fixes (provisorische Änderungen) werden normalerweise als Dateigruppe und möglicherweise als einfaches Installationsprogramm bereitgestellt.
27
Tabelle 2. Aktualisierungstypen, die von WebSphere Remote Server bereitgestellt werden
Aktualisierungen
Merkmale von jeder Aktualisierung
Release
v Ein neuer WebSphere Remote Server, der
wichtige neue Funktionen enthält (wie
z. B. Version 7.0)
v Ist als Solution Assembly Toolkit-Lösung
gepackt
v Umfassendes Testen aller Anwendungen
mit neuem Release wird empfohlen
v Erfordert Migration, um das Upgrade
durchzuführen
Fixpack
v Standardmäßig werden Aktualisierungen
auf diese Weise bereitgestellt und sind
bereits einem Regressionstest unterzogen
worden
gepackt
v Ein Fixpack ist ein kumulatives Paket mit
Fixes, z. B. Fix Pack 1 unter Version 7.0
(7.0.0.1)
v Jede Bereitstellung eines Fixpacks kann
aus mehreren Fixpacks für die folgenden
Produkte oder Komponenten bestehen:
– DB2
– Informix Dynamic Server
– IBM WebSphere MQ
– IBM HTTP Server
– IBM WebSphere Application Server
Network Deployment
– Java Runtime Environment
– Solution Assembly Toolkit
– WebSphere sMash
– WebSphere Remote Server
– WebSphere Remote ServerEntwicklungsumgebung
v Fixpacks werden über ein Release oder
einen vorherigen Fixpack installiert, wie
z. B. das Anwenden von Version 7.0.0.2
auf Version 7.0.0.1
v Fixpacks sind kumulativ, d. h. Version
7.0.0.2 enthält alle Fixes aus Version 7.0.0.1
v Fixpacks deinstallieren alle vorläufigen
Fixes, die auf das Release seit der Installation des letzten Fixpacks angewendet
wurden. Daher ist es notwendig, die Liste
der bereitgestellten Fixes zu überprüfen,
um festzustellen, ob ein vorläufiger Fix
erneut installiert werden muss.
v Ein kurzer Test der kritischen Funktionen
mit dem neuen Fixpack wird empfohlen
v Prüfen Sie die Liste der Fixes und
Installationsanweisungen, um zu ermitteln, ob eine Migration erforderlich ist.
28
Tabelle 2. Aktualisierungstypen, die von WebSphere Remote Server bereitgestellt
werden (Forts.)
Aktualisierungen
Merkmale von jeder Aktualisierung
Vorläufiger Fix
v Eine einzelne veröffentlichte provisorische
Änderung
v Ein Fix ist ein vorläufiger Fix, der mindestens einen Produktfehler behebt
v WebSphere Remote Server stellt in der
Regel keine vorläufigen Fixes für
WebSphere Remote ServerMiddlewareprodukte bereit. Fixes für
Middlewareprodukte können von der
IBM Unterstützungssite für jedes
Middlewareprodukt heruntergeladen werden. WebSphere Remote Server-Fixes werden für WebSphere Remote ServerKomponenten bereitgestellt.
v Ein Fix kann sowohl auf ein Release als
auch auf ein Fixpack angewendet werden
v Vorläufige Fixes werden erstellt, wenn ein
Standalone-Fix zwischen Fixpacks benötigt wird
v Es wird empfohlen, die Funktionen
zu testen, die von der korrigierten
WebSphere Remote Server-Komponente
betroffen sind
Änderung
gepackt
v Ein Änderungsrelease ist ein optionales
Upgrade
v Änderungsreleases werden über ein
Release oder ein vorheriges Fixpack installiert
v Eine Migration ist möglicherweise erforderlich. Prüfen Sie die Liste der Fixes und
Installationsanweisungen, um zu ermitteln, ob eine Migration erforderlich ist.
Migration
WebSphere Remote Server unterstützt die automatisierte Migration von Filialrechnern (in-store processors, ISPs) von WebSphere Remote Server Starter Edition
Version 6.1 und 6.2.x auf IBM Retail Store Server Starter Edition 7.0. Es sind keine
automatisierten Migrationsoptionen vorhanden, um ein Upgrade auf IBM Retail
Store Server Starter Edition mit Informix Dynamic Server durchzuführen.
Der Migrationsprozess ist in derselben Lösung enthalten, die für Neuinstallationen
verwendet wird, und kann von der DVD ausgeführt werden. .
Die Tabelle listet die unterstützte Migration für unterschiedliche Betriebssysteme
auf. Ist ein Betriebssystem nicht aufgeführt, dann ist für dieses Betriebssystem
keine unterstützte Migration vorhanden.
29
Tabelle 3. Liste mit Betriebssystemen und unterstützter Migration
Betriebssystem
Version von WebSphere Remote Server, die
migriert werden kann
Windows 2003 Server
6.1, 6.2, 6.2.1
SUSE Linux Enterprise Server 10
6.2, 6.2.1
Red Hat Enterprise Linux 5.2
6.2.1
Windows XP mit Service-Pack 2
6.2.1
Anmerkung: Eine Migration der Entwicklungsumgebung ist nicht vorgesehen.
Unterschiedliche Releases von IBM Solution Assembly Toolkit können koexistieren, gleichgeordnete Aktualisierungen oder Fixpacks
jedoch nicht. Sie können z. B. die Versionen 2.1.x, 2.2.x und 3.1 auf
einem Computer installieren, die gleichzeitige Installation der Versionen 2.1.1 und 2.1.2 ist nicht möglich.
Migration auf 7.0
v Stellen Sie sicher, dass Sie den WebSphere MQ-Warteschlangenmanager gestoppt
haben, bevor Sie die Migration ausführen. Anweisungen zum Stoppen des
Warteschlangenmanagers finden Sie unter der Adresse: http://
publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/
com.ibm.mq.amqzag.doc/fa10960_.htm
v Wenn Sie auf das Betriebssystem Windows 2003 migrieren, müssen Sie sicherstellen, dass Sie vor der Migration den Microsoft®-Patch MS08-067 installieren.
Ohne diesen Patch schlägt die Migration auf WebSphere Application Server fehl.
v Wenn Sie von Version 6.1 auf das Betriebssystem Windows 2003 migrieren, für
das die WebSphere Application Server-Sicherheit aktiviert ist, erstellen Sie vor
dem Starten des WebSphere Remote Server-Installationsprogramms eine Datei
C:\temp\WAS_ID_PW.txt, die Ihren WebSphere Application Server-Benutzernamen und Ihr Kennwort enthält. Die Datei sollte z. B. Folgendes enthalten:
MyWasAdminUser
MyWasAdminPw
Remote Server.
30
5. Wählen Sie aus, ob Sie von WebSphere Remote Server 6.1 oder 6.2.x migrieren
wollen.
6. Die Laufzeit und die Middlewarekomponenten sind vorausgewählt. Klicken
Sie auf Next, um fortzufahren.
7. Geben Sie ein Installationsverzeichnis für die Basiskomponente von IBM Retail
Store Server an und klicken Sie auf Next. Dieser Wert ist die Umgebungsvariable SIF_HOME. Sie können für SIF_HOME bedenkenlos dasselbe Verzeichnis verwenden, in dem sich Ihre vorhandene WebSphere Remote ServerInstallation befindet.
Anmerkung: Sie können den Wert von SIF_HOME nicht ändern, wenn Sie
eine Migration durchführen.
8. Geben Sie in den übrigen Anzeigen erforderliche und optionale Installationsparameter an, wenn Sie von Deployment Wizard dazu aufgefordert werden.
Eine detaillierte Beschreibung der Felder finden Sie im Abschnitt „Felder für
die Laufzeitinstallation” auf Seite 10.
Hinweise:
v Das Installationsverzeichnis für WebSphere Application Server
muss sich vom vorhandenen WebSphere Application ServerInstallationspfad unterscheiden.
v Das Installationsverzeichnis, die Administrator-ID und das
Kennwort für DB2 müssen mit denen übereinstimmen, die für
den vorhandenen DB2 angegeben wurden.
v Das Installationsverzeichnis für IBM HTTP Server muss dasselbe
sein, wie der vorhandene IBM HTTP Server-Installationspfad.
9. Implementieren Sie die Installationstasks, nachdem Sie sie im Fenster mit der
10. Wenn die Installation unter einem Windows-Betriebssystem erfolgt ist, führen
Sie Folgendes aus:
v Führen Sie einen Warmstart für Ihren Server aus, damit das Betriebssystem
die Aktualisierungen übernehmen kann.
v Aktualisieren Sie die Portnummer im Direktaufruflink für die WebSphere
Application Server-Verwaltungskonsole in Ihrem Startmenü. Lesen Sie die
folgenden technischen WebSphere Application Server-Hinweise, um weitere
Informationen zu erhalten: http://www.ibm.com/support/
docview.wss?rs=180&uid=swg21385225
31
32
Im Abschnitt zur IBM WebSphere Remote Server-Verwaltung werden verschiedene
Verwaltungstasks beschrieben, die ausgeführt werden müssen, um einen guten
Funktionsstatus von WebSphere Remote Server zu gewährleisten.
WebSphere Remote Server steuern
ISPs, die mit dem IBM WebSphere Remote Server-Middlewarekomponentenstack
konfiguriert wurden, müssen über die Fähigkeit verfügen, die Anwendungen zu
starten, zu stoppen oder diese zu ihrem Ausführungsstatus einzeln oder als Serverstack abzufragen.
Funktionsübersicht
Ab WebSphere Remote Server V6.2.x stehen Scripts zur Verfügung, mit denen die
WebSphere Remote Server-Lösung unter Verwendung unterschiedlicher Granularitätsgrade gesteuert werden kann.
Die WebSphere Remote Server-Middlewarekomponentenanwendungen werden
gestartet, gestoppt oder ihr Ausführungsstatus wird abgefragt, indem die entsprechenden Befehle abgesetzt werden. Die Befehle werden lokal auf dem ISP durch
lokales Aufrufen oder von einer fernen Maschine ausgeführt, die Prozesse auf dem
ISP ausführen kann.
Für das Absetzen der Befehle zum Starten, Stoppen oder Abfragen des Ausführungsstatus für den ISP sind Kenntnisse über ISP-maschinenspezifische Informationen erforderlich, damit die Befehlstask vollständig ausgeführt werden kann.
Das Verwalten der Informationen, die für die vollständige Ausführung der Befehle
auf dem ISP nötig sind, bietet ein Höchstmaß an Flexibilität, wenn die Befehlsanforderungen von fernen Maschinen abgesetzt werden. Wenn Anwendungen hinzugefügt, gelöscht oder modifiziert werden, ist es unter Umständen nicht erforderlich, die aktualisierten Anwendungsinformationen an eine ferne, zentralisierte
Position zurückzusenden.
Wie erhält der ISP die Informationen zum Starten, Stoppen oder Abfragen des Ausführungsstatus der Middleware, die auf den ISP geladen wurde? Zu diesem Zweck
werden in diesem Release von WebSphere Remote Server die maschinenspezifischen Informationen erfasst, wenn die Middlewarekomponenten auf der Maschine
installiert werden. Die erfassten Daten werden in der WebSphere Remote ServerMetadatendatei auf dem ISP gespeichert.
Sobald die maschinenspezifischen Middlewareinformationen erfasst sind, kann eine
Anwendung auf dem ISP starten, stoppen oder den Ausführungsstatus abfragen,
indem das entsprechende Script auf dem ISP aufgerufen wird. Die Scripts verwenden die Middlewareinformationen aus der WebSphere Remote Server-Metadatendatei, um die Befehlstask für das Starten, Stoppen oder Abfragen des Status auszuführen.
Bei der WebSphere Remote Server-Metadatendatei handelt es sich um eine XMLDatei, die die Konfigurations- und Steuerungsinformationen für die auf dem ISP
installierten WebSphere Remote Server-Middlewarekomponenten enthält. Die in
33
dieser Datei enthaltenen Informationen werden anfangs während der WebSphere
Remote Server-Installation abgerufen.
WebSphere Remote Server-Steuerscripts
Die folgenden Scripts stehen zur Steuerung des Middleware-Stacks und der
Anwendungen (Starten, Stoppen bzw. Abfragen des Ausführungsstatus) in
WebSphere Remote Server zur Verfügung; sie befinden sich im Verzeichnis
’SIF_HOME/bin’:
v wrsstart.sh – Startet den Stack oder eine Anwendung
v wrsstop.sh – Stoppt den Stack oder eine Anwendung
v wrsrunstatus.sh: Fragt den Ausführungsstatus des Stacks oder der Anwendung
ab
v wrsstart.bat: Startet den Stack oder eine Anwendung
v wrsstop.bat: Stoppt den Stack oder eine Anwendung
v wrsrunstatus.bat: Fragt den Ausführungsstatus des Stacks oder der Anwendung
ab
Die oben aufgeführten Scripts können für die gesamte WebSphere Remote ServerLösung sowie alle Anwendungen und Unterkomponenten ausgeführt werden, die
in der WebSphere Remote Server-Lösung enthalten sind.
Anmerkung: Führen Sie in einem neuen Befehlszeilenfenster die Befehle zum Starten (start) und Stoppen (stop) sowie die Befehle zum Abfragen des
Ausführungsstatus aus. Die Befehle können nicht von dem Befehlszeilenfenster aus abgesetzt werden, das Sie zum Installieren verwendet haben, da die Umgebung aktualisiert werden muss. Durch Öffnen eines neuen Fensters wird die Umgebung aktualisiert.
Das Format für jeden Befehl ist nachfolgend dargestellt.
wrsstart [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
wrsstop [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
wrsrunstatus [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
Dabei sind die folgenden Parameter optional:
v -silent: Befehlsausgabeinformationen werden nicht in der Anzeige ausgegeben.
v -log: Befehlsausgabeinformationen werden in der Protokolldatei ausgegeben.
v -verbose: Ausführliche Informationen zur Debugbefehlsausgabe werden im
angegebenen Ausgabetyp ausgegeben.
Der Ergebnistext für die Befehlsausgabe wird standardmäßig in der Anzeige ausgegeben.
Bei Operationen des WebSphere Remote Server-Stacks wird nach der Befehlsausführung der folgende Statuscode zurückgegeben:
v 0: Die Befehlsrückkehrcodes geben die erfolgreiche Ausführung aller Befehle an2
v 1: Die Befehlsrückkehrcodes geben an, dass mindestens ein Befehl nicht erfolgreich ausgeführt wurde2
34
v 2: Die Beendigungscodes für die Befehle sind unbekannt, das heißt, es konnten
keine Befehle ausgeführt werden2
Bei Operationen einer einzelnen WebSphere Remote Server-Komponente wird nach
der Befehlsausführung der folgende Statuscode zurückgegeben:
Die Befehle wrsstart und wrsstop:
v 2: Der Beendigungscode für den Befehl ist unbekannt, das heißt beispielsweise,
dass der Befehl nicht ausgeführt werden konnte1
v Beliebiger Wert: Tatsächlicher Code, der nach der Befehlsausführung zurückgegeben wurde (könnte ’2’ lauten, falls ’2’ ein gültiger Code für den Befehl ist)1
Der Befehl wrsrunstatus:
v 0: Abgefragtes Element wird ausgeführt2
v 1: Abgefragtes Element wird nicht ausgeführt2
v 2: Ausführungsstatus für abgefragtes Element ist nicht vollständig bekannt2
1
Der zurückgegebene Code gibt den Beendigungsstatus für den Start- oder Stoppbefehlsprozess an. Der Code gibt nicht an, ob der Stack oder die Anwendung
gestartet oder gestoppt wurden. Überprüfen Sie mithilfe des Befehls wrsrunstatus,
ob der Stack bzw. die Anwendung ausgeführt wird.
2
Die Rückkehrcode(s) der Befehl(e) wird/werden in 0, 1 oder 2 normalisiert.
Wenn die Befehlsprotokollierung für den Befehl mithilfe des Parameters -log aktiviert wurde, wird jeder relevante Rückgabestatus in der Datei ’SIFHOME/logs/
wrscommands.log’ protokolliert.
Die Scripts ’wrsstart’, ’wrsstop’ und ’wrsrunstatus’ nutzen Hilfsscripts, die für die
individuellen Komponenten spezifisch sind. Diese Scripts sind im Folgenden aufgelistet. Sie befinden sich im Verzeichnis ’SIF_HOME/bin’:
wrs_DB2Admin_start.bat/sh
wrs_DB2Admin_stop.bat/sh
wrs_DB2Admin_status.bat/sh
wrs_DB2_start.bat/sh
wrs_DB2_stop.bat/sh
wrs_DB2_status.bat/sh
wrs_IDS_start.bat/sh
wrs_IDS_stop.bat/sh
wrs_IDS_status.bat/sh
wrs_IHSAdmin_start.bat/sh
wrs_IHSAdmin_stop.bat/sh
wrs_IHSAdmin_status.bat/sh
wrs_IHS_start.bat/sh
wrs_IHS_stop.bat/sh
wrs_IHS_status.bat/sh
wrs_MQ_start.bat
wrs_MQ_stop.bat
wrs_MQ_status.bat
wrs_WAS_start.bat/sh
wrs_WAS_stop.bat/sh
wrs_WAS_status.bat/sh
Beispiele für WebSphere Remote Server-Steuerscripts
Die WebSphere Remote Server-Steuerscripts können verwendet werden, um Lösungen, Anwendungen oder Anwendungsunterkomponenten zu starten. In diesem
Abschnitt sind verschiedene Beispiele dargestellt, die die Verwendung der Steuerscripts veranschaulichen.
35
Bei der Installation von WebSphere Remote Server erhält die Lösung den Namen
WRS; sie stellt den gesamten Middleware-Stack dar. Eine Lösung besteht aus
Anwendungen, die die einzelnen Middlewarekomponenten darstellen. Die Standardanwendungen, aus denen die Lösung WRS besteht, sind nachfolgend aufgeführt:
v IBM WebSphere Application Server
v DB2
v Informix Dynamic Server
v IBM HTTP Server
v IBM WebSphere MQ
Lösung
Für die Steuerung auf Lösungsebene können die vorgefertigten Scripts verwendet
werden. Die Syntax für die Steuerung auf Lösungsebene lautet:
v wrsstart - Starten der Lösung
v wrsstop - Stoppen der Lösung
v wrsstatus - Abfragen des Ausführungsstatus der Lösung
Anwendungen und Unterkomponenten
Anwendungen und Unterkomponenten von Anwendungen können mithilfe der
oben aufgeführten WebSphere Remote Server-Steuerscripts gesteuert werden.
Die Syntax für diese Scripts wird nachfolgend aufgeführt:
v -silent: Informationen zur Befehlsausführung werden nicht in der Anzeige ausgegeben.
v -log: Informationen zur Befehlsausführung werden in der Protokolldatei ausgegeben.
v -verbose: Ausführliche Informationen zur Debugbefehlsausführung werden im
Wenn z. B. das WebSphere Application Server-Profil ’WRSProfile’ im Debugmodus
gestartet werden soll, müsste der folgende Befehl verwendet werden: wrsstart WAS
WRSProfile –verbose
Die Debuginformationen werden in der Anzeige angezeigt.
Wenn das WebSphere Application Server-Profil ’WRSProfile’ im Debugmodus
angezeigt werden soll und die Debuginformationen aber nicht in der Anzeige
angezeigt werden sollen, lautet der Befehl: wrsstart WAS WRSProfile -silent -log
–verbose
Die Debuginformationen werden nur in der Protokolldatei ausgegeben.
36
Neben dem Steuern einzelner Anwendungen oder Unterkomponenten könnte auch
eine Auflistung der Elemente auf Anwendungs- und Unterkomponentenebene vorhanden sein. In diesem Fall würde die Liste genau wie die Liste im Lösungsbeispiel oben verarbeitet werden.
Weitere Informationen zum Erweitern der Verwendung der Steuerscripts finden Sie
im Abschnitt „WebSphere Remote Server- und ISP-Anwendungen steuern” auf
Seite 72.
WebSphere MQ-Nachrichtencontroller
Der IBM WebSphere MQ-Nachrichtencontroller (MQ Message Controller) wird
zum Steuern des Nachrichtenflusses vom Sender zum Empfänger verwendet.
Der Controller wurde entwickelt, um eine bestimmte Geschäftsanforderung zu
behandeln, die darin besteht, dass WebSphere MQ nicht die Netzbandbreite für
sich in Anspruch nimmt, wenn der WebSphere MQ-Kanal nach einem anhaltenden
Netzausfall wieder gestartet wird. Für den Fall, dass die Netzbandbreite knapp ist
und die WebSphere MQ-Nachrichten einen beträchtlichen Anteil der Bandbreite
beanspruchen, der sonst von wichtigerem Datenverkehr, wie z. B. Transaktionsprotokollen, verwendet werden würde, können Sie mithilfe dieser Anwendung die
Anzahl der Nachrichten bzw. das ungefähre Volumen der Nachrichtendaten steuern, die über den WebSphere MQ-Kanal gesendet werden.
WebSphere MQ-Nachrichtencontroller installieren
Der Nachrichtencontroller gehört zum Lieferumfang von IBM WebSphere Remote
Server und muss an der richtigen Position installiert werden, wenn WebSphere
Remote Server installiert wird.
Um sicherzustellen, dass der Nachrichtencontroller ordnungsgemäß installiert
wurde, stellen Sie fest, ob sich die Dateien LinSenderChannelController und mqexitprog.properties nach der Installation von WebSphere Remote Server an den folgenden Positionen befinden.
MQ_HOME\exits
SIF_HOME/mqexits
Beachten Sie, dass das Vorhandensein dieser Dateien nicht bedeutet, dass der
Nachrichtencontroller bereits auf dem System installiert ist. Diese Dateien werden
standardmäßig für die Verwendung zur Verfügung gestellt. Ist eine Geschäftsanforderung für die Verwendung des Controllers vorhanden, müssen Sie die im
Abschnitt „WebSphere MQ-Nachrichtencontroller konfigurieren” beschriebenen
Schritte befolgen.
WebSphere MQ-Nachrichtencontroller konfigurieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um den Nachrichtencontroller
für den Einsatz zu konfigurieren.
Sie müssen folgende Schritte ausführen, um die zu steuernde WebSphere MQ-Umgebung zu aktivieren:
v Konfigurieren Sie die Nachrichtenexits für die Zielkanäle.
v Ändern Sie die Datei mqexitprog.properties.
1. Konfigurieren Sie den WebSphere MQ-Kanal für Nachrichtenexits mithilfe von
WebSphere MQ Explorer.
37
a. Navigieren Sie zum richtigen Warteschlangenmanager.
b. Blenden Sie die Registerkarte Advanced → Channels ein.
c. Klicken Sie mit der rechten Maustaste auf den Senderkanal, den Sie konfigurieren wollen.
d. Wechseln Sie zur Registerkarte Exits und blättern Sie abwärts zum
Abschnitt Message Exits Name.
e. Suchen Sie die Datei WinSenderChannelController.dll oder LinSenderChannelController in Ihrem Dateisystem.
f. Geben Sie Folgendes ein: pfad\dateinamen(ChannelExit). Unter Windows beispielsweise wird WebSphere MQ im Verzeichnis C:\Program Files\IBM\MQ
installiert, sodass der Eintrag in diesem Schritt wie folgt aussehen muss:
C:\Program Files\IBM\MQ\exits\WinSenderChannelController(ChannelExit)
g. Klicken Sie auf OK und starten Sie den Kanal erneut.
Anmerkung: Alternativ können Sie den Befehl ’Alter Channel’ in der
MQSC-Shell (zum Benutzer ’mqm’ wechseln und den Befehl
’runmqsc’ ausführen) verwenden, um den Kanal für
WebSphere MQ-Exits zu modifizieren. Diese Änderung muss
auf dem System erfolgen, auf dem der Senderkanal konfiguriert wurde.
Musterbefehle zum Ändern eines Kanals:
alter channel ('channel_name') chltype (SDR)
msgexit ('$SIF_HOME/mqexits/
LinSenderChannelController(ChannelExit)')
alter channel ('channel_name') chltype (SDR)
msgexit ('%MQ_HOME%\exits\
WinSenderChannelController(ChannelExit)')
2. Ändern Sie die Datei mqexitprog.properties. Diese Datei enthält die Variablen,
die die Funktionsweise des Nachrichtencontrollers steuern. Die folgenden Variablen sind in der Datei definiert:
v SLEEP_INTERVAL: Standardwert 0. Bereich: 0 bis 9999. Diese Variable legt
die Dauer in Sekunden fest, die der WebSphere MQ-Kanal vor dem Senden
des nächsten Nachrichtenstapels wartet. Ein Wert 0 bedeutet, dass der Kanalexit inaktiviert ist.
Anmerkung: Wenn Sie den Nachrichtencontroller nicht verwenden wollen
und SLEEP_INTERVAL auf 0 setzen, wird der Controller
erwartungsgemäß ausgeführt, allerdings erhöht sich der
Systemaufwand dadurch. Anstatt den Wert auf 0 zu setzen,
wird empfohlen, die Nachrichtenexits zu entfernen, falls der
Nachrichtencontroller nicht verwendet werden soll.
v MESSAGE_COUNTER: Standardwert 0. Bereich: 0 bis 9999. Diese Variable
legt die Anzahl der Nachrichten fest, die gesendet werden, bevor der Ruhemodus für die Dauer der mit SLEEP_INTERVAL angegebenen Sekunden eintritt. Ein Wert 0 bedeutet, dass diese Variable nicht beim Steuern des Nachrichtenflusses berücksichtigt wird.
v MESSAGE_SIZE_COUNTER: Standardwert 0. Bereich: 0 bis 65000 Byte. Diese
Variable gibt das Datenvolumen an, das gesendet wird, bevor die Ruhemodusfunktion aktiviert wird. Ein Wert 0 bedeutet, dass diese Variable nicht
beim Steuern des Nachrichtenflusses berücksichtigt wird.
38
v EFFECTIVE_BETWEEN: Standardwert 0000:0000. Bereich: 0000:0001 bis
0000:2359. Diese Variable legt die Systemzeit in hhmm bis hhmm fest, während der der Controller für den Ruhemodus ausgeführt wird. Der Controller
steuert den Nachrichtenfluss nicht außerhalb der angegebenen Zeit. Ein Wert
0000:0000 bedeutet, dass der Controller die ganze Zeit über aktiv ist. Die Zeit
sollte im 24-Std-Format angegeben werden.
Der Nachrichtencontroller führt bestimmte Berechnungen durch, um festzustellen, ob er in den Ruhemodus versetzt werden muss.
Wenn Current_Msg_Count (Anzahl aktueller Nachrichten) kleiner als
MESSAGE_COUNTER ist und Effective_Msg_Size (Größe aktiver Nachrichten)
kleiner als MESSAGE_SIZE_COUNTER ist und EFFECTIVE_BETWEEN gültig
ist, dann wird die Nachricht ohne Verzögerung gesendet, andernfalls wird für
die Dauer der in SLEEP_INTERVAL angegebenen Sekunden gewartet, bevor
die Nachricht gesendet wird.
Um dies weiter auszuführen: SLEEP_INTERVAL 20 (wartet 20 Sekunden vor
dem Senden des nächsten Nachrichtenstapels) MESSAGE_COUNTER 10 (wird
nach jeder 10. Nachricht in den Ruhemodus versetzt) MESSAGE_SIZE_COUNTER 20000 (oder bis die Größe der gesendeten Daten diesen Grenzwert erreicht
hat) EFFECTIVE_BETWEEN 0800:2100 (vorausgesetzt, es ist zwischen 8:00 und
21:00 Uhr).
Anmerkung: Es wird empfohlen, das WebSphere MQ-Nachrichtenaufkommen
genau zu überwachen, nachdem Sie den WebSphere MQ-Nachrichtencontroller konfiguriert haben. Es kann sein, dass Sie unter
Umständen für die oben aufgeführten Variablen zu extreme
Werte konfiguriert haben und dass die Rate für die Generierung
der Nachrichten höher ist als die Rate für das Senden der Nachrichten. Zum Vermeiden solcher Situationen wird empfohlen,
dass der Nachrichtencontroller nur während der täglichen Hauptarbeitszeiten aktiviert wird.
Alternativen zum Nachrichtencontroller
Es gibt verschiedene Ansätze für die Simulation der Nachrichtencontrollerfunktion.
Jeder dieser Ansätze hat jeweils Vorteile und Nachteile. Beschäftigen Sie sich eingehend mit diesen Ansätzen, damit Sie eine fundierte Entscheidung auf der Grundlage der Anforderungen und der Geschäftskonfiguration treffen können.
Niedrige Tiefe und häufige Wiederholung einer Kanaloperation
Bei diesem Ansatz kann der WebSphere MQ-Administrator die Warteschlangenlänge der Empfangswarteschlange auf einen sehr niedrigen Wert, z. B. 2, und das
Wiederholungsintervall einer Kanaloperation auf etwa 60 Sekunden setzen. Wenn
nun die Empfangswarteschlange den Überlaufgrenzwert erreicht, geht der
Verbindungskanal in den Wiederholungsmodus, wenn er versucht, die nächste
Nachricht zu senden. Dadurch wird mit dieser Methode indirekt die Rate des
Nachrichtenflusses durch den WebSphere MQ-Kanal gesteuert.
Der Vorteil einer solchen Einstellung ist, dass keine weitere Anwendung für die
Steuerung des Nachrichtenflusses benötigt wird. Dieser Ansatz weist außerdem
günstigere Werte im Hinblick auf die CPU-Belegung und die Speicherauslastung
auf.
Der Nachteil einer solchen Einstellung ist, dass bei diesem Ansatz nicht garantiert
werden kann, dass der Nachrichtenfluss auf eine festgelegte Anzahl der Nachrichten pro Minute beschränkt wird. Der Grund hierfür ist, wenn die Anwendung, die
39
die Nachrichten verarbeitet, auf der Empfangsseite die Nachrichten schnell genug
aufnimmt, bevor die Warteschlange den Überlaufgrenzwert erreicht, ist die Anordnung unbrauchbar.
Nachrichtenkomprimierung
Bei diesem Ansatz aktiviert der WebSphere MQ-Administrator die Komprimierung/Dekomprimierung von WebSphere MQ. Bei Verwendung dieser Option komprimiert die WebSphere MQ-Steuerkomponente den Datenteil der Nachricht, bevor
sie durch den Kanal gesendet wird. Auf der Empfangsseite dekomprimiert die
WebSphere MQ-Steuerkomponente die Nachricht, bevor sie in die Empfangswarteschlange gestellt wird.
Die Vorteile dieses Ansatzes:
v Vollständige Transparenz gegenüber der sendenden/empfangenden Benutzeranwendungen.
v CPU-Belegung/Speicherauslastung sind gering.
v Erhebliche Reduzierung der Nachrichtengröße (bis zu 90 % bei ASCII-Textdaten).
v Erhebliche Reduzierung der Netzauslastung pro gesendeter Nachricht.
v Funktionalität ist durchweg gewährleistet.
Der Nachteil dieses Ansatzes besteht darin, dass er stark vom Typ der Nachrichtendaten abhängt. Die Komprimierung kann gut für textbasierte Nachrichten
angewendet werden. Handelt es sich jedoch um binäre Nachrichtendaten, ist die
Komprimierung kaum wahrnehmbar.
IBM Tivoli License Compliance Manager installieren und aktivieren
Tivoli License Compliance Manager überwacht die Lizenzeinhaltung. Im Grunde
erkennt und überwacht es, welche Produktangebote mit den zugehörigen Versionen, Releases und Fixpacks auf dem System installiert sind und verwendet werden.
WebSphere Remote Server unterstützt die Verwendung von Tivoli License Compliance Manager-Server, um Verwendungsinformationen zu sammeln und zu überwachen.
Zum Installieren und Aktivieren von Tivoli License Compliance Manager müssen
Sie den Tivoli License Compliance Manager-Agenten herunterladen und ihn auf
jedem WebSphere Remote Server installieren. Anweisungen zum Herunterladen
von Tivoli License Compliance Manager finden Sie im Tivoli License Compliance
Manager Information Center.
Die erforderliche WebSphere Remote Server-Signaturdatei für den Tivoli License
Compliance Manager-Agenten wird während der WebSphere Remote Server-Installation auf WebSphere Application Server implementiert. Eine Sicherungsversion
der Datei befindet sich nach der Installation im Verzeichnis SIF_HOME\tivoli.
Zwei Dateien stehen zur Verfügung:
DB2 - RSDSTR0700.SYS2
Informix Dynamic Server - RSISTR0700.SYS2
40
Sicherheitsaspekte
Die Verbesserung der Sicherheit für einzelhandelsorientierte Informationssysteme
sowie für die von diesen Systemen übertragenen und gespeicherten Daten ist zu
einer der zentralen Aufgaben geworden, mit denen sich Einzelhändler auseinandersetzen müssen. Bei vielen großen Unternehmen sind Sicherheitsverstöße aufgetreten, die sie hohe Beträge aufgrund von Rechtsstreits, der erforderlichen Behebung von Sicherheitslücken in ihrer IT-Infrastruktur, des schwindenden
Kundenvertrauens und der Sanktionen durch einflussreiche Kreditkartenunternehmen kosteten.
Um solche Sicherheitsverstöße zukünftig zu verhindern, wurden Sicherheitsstandards wie beispielsweise PCI DSS (Payment Card Industry Data Security Standard) entwickelt, um die für die System- und Datensicherheit eines Unternehmens
verantwortlichen IT-Mitarbeiter bei der Sicherung ihrer Systeme zu unterstützen.
Die Einhaltung des Standards PCI DSS wird von allen Unternehmen verlangt, die
die beim Kartenzahlungsverkehr verwendete PAN (Primary Account Number) verarbeiten und/oder speichern. Selbst für Unternehmen, die nicht mit PANs arbeiten,
dient PCI DSS als gutes Modell für die IT-Infrastruktursicherheit in einem
einzelhandelsorientierten Unternehmen.
Die Informationen im vorliegenden Thema sollen Ihnen als Richtlinie dienen, wenn
Sie sich mit wichtigen Sicherheitsaspekten befassen, die bei der Installation und
Konfiguration einer IBM WebSphere Remote Server-Lösung möglicherweise eine
Rolle spielen. In Anlehnung an die Vorgaben von PCI DSS können die hier aufgeführten Punkte als Basis für die Identifizierung von Problembereichen dienen, die
im Rahmen der Verbesserung Ihrer Systemsicherheit besondere Aufmerksamkeit
erfordern. Zu jeder der zwölf Hauptanforderungen des PCI-Standards sind vorgeschlagene Aktionen für die einzelnen Komponenten der WebSphere Remote ServerInstallation aufgeführt.
Weitere Informationen zum Inhalt des vorliegenden Abschnitts erhalten Sie über
die folgenden Links:
v PCI Security Standards Council – PCI DSS: https://
www.pcisecuritystandards.org
v WebSphere Application Server 7.0 - Abschotten der Sicherheitskonfigurationen
des Systems: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.doc/info/ae/ae/tsec_hardsecconfig.html
v WebSphere Application Server 7.0 - Optimierung, Abschottung und Verwaltung:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/
com.ibm.websphere.nd.doc/info/ae/ae/tsec_tunehardmaintain.html
v WebSphere Application Server 7.0 - Kennwörter in Dateien sichern: http://
publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_securepwds.html
v 1WebSphere Application Server V6 Advanced Security Hardening – Part 1 von
Keys Botzum: http://www-128.ibm.com/developerworks/websphere/
techjournal/0512_botzum/0512_botzum1.html
v 2WebSphere Application Server V6 Advanced Security Hardening – Part 2 von
Keys Botzum: http://www-128.ibm.com/developerworks/websphere/
techjournal/0512_botzum/0512_botzum2.html
v 3Mission: Messaging: WebSphere MQ, PCI DSS, and security standards von T.
Rob Wyatt: http://www.ibm.com/developerworks/websphere/techjournal/
0806_mismes/0806_mismes.html
41
v WebSphere MQ 7.0 security: http://publib.boulder.ibm.com/infocenter/wmqv7/
v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12730_.htm
v 4DB2 Version 9.5 für Linux, UNIX und Windows: Grundlegende Informationen
zu Datenbanken - Sicherheitsaspekte: http://publib.boulder.ibm.com/infocenter/
db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.sec.doc/doc/
c0021061.html
v Sicherheit in IBM Informix Dynamic Server: http://publib.boulder.ibm.com/
infocenter/idshelp/v115/index.jsp?topic=/com.ibm.sec.doc/SEC_wrapper.htm
Anmerkung: Sie erhalten weitere Informationen zu den nachfolgend aufgeführten
Punkten, die mit einem Verweis in Form eines hochgestellten Zeichens versehen sind, indem Sie den angegebenen Links folgen und
nach der in geschweiften Klammern {} angegebenen Referenznummer im betreffenden Artikel suchen. Beispiel: 1 {28} gibt Punkt 28
in dem Artikel an, den Sie über den Link 1 aufrufen, also
″WebSphere Application Server V6 Advanced Security Hardening –
Part 1″ von Keys Botzum.
PCI DSS
PCI DSS besteht aus zwölf Basisanforderungen, die Unternehmen erfüllen müssen,
die Daten des kartengestützten Zahlungsverkehrs speichern, verarbeiten, übertragen und/oder löschen. Jeder dieser zwölf Hauptpunkte ist in eine Reihe von untergeordneten Punkten unterteilt. Dieser Standard wurde im Rahmen einer Kooperation verschiedener Unternehmen, wie zum Beispiel Visa, Mastercard, American
Express und anderen, entwickelt. Die nachfolgenden Informationen beschränken
sich der Kürze halber auf die zwölf Hauptpunkte.
Die zwölf nachfolgend aufgeführten Hauptpunkte können logisch in Themen gruppiert werden, die sich auf die Funktionsbereiche beziehen, die bei der Analyse des
ordnungsgemäßen Betriebs und der Stabilität eines gesicherten Netzes berücksichtigt werden müssen.
Erstellen und Pflegen eines gesicherten Netzes
Sichern Sie möglichst alle Zugänge zu den kritischen Systemen Ihres
Unternehmens, indem Sie unbefugte Zugriffsversuche und unbekannte
Angriffe blockieren. Dies hilft Ihnen dabei, zu gewährleisten, dass die
Daten von Karteninhabern sicher sind und dass Sie über eine zuverlässige
erste Abwehr gegen Sicherheitsverstöße verfügen.
1. Installieren und pflegen Sie eine Firewallkonfiguration zum Schutz der
Daten von Karteninhabern.
2. Verwenden Sie keine Standardeinstellungen des Herstellers für Systemkennwörter und andere Sicherheitsparameter.
Schützen der Daten von Karteninhabern
Schützen Sie die Daten von Karteninhabern, indem Sie das Versetzen, das
Speichern sowie das festnetzgebundene und das festnetzunabhängige
Übertragen von Daten kontrollieren.
3. Schützen Sie gespeicherte Daten von Karteninhabern.
4. Verschlüsseln Sie die Übertragung der Daten von Karteninhabern in offenen bzw. öffentlich zugänglichen Netzen.
Pflegen eines Verwaltungsprogramms zur Überwachung von Schwachstellen
Entwickeln und implementieren Sie effektive Sicherheitsprozeduren für alle
Anwendungen in Ihrer Infrastruktur, um Schwachstellen im Sicherheits-
42
system, wie beispielsweise das Eindringen von zerstörerischem Programmcode und Sicherheitslücken, zu minimieren.
5. Verwenden Sie Virenschutzsoftware bzw. Antivirenprogramme und aktualisieren Sie diese regelmäßig.
6. Entwickeln und pflegen Sie sichere Systeme und Anwendungen.
Implementieren strikter Zugriffskontrollmaßnahmen
Schränken Sie den Zugriff auf Daten von Karteninhabern ein, legen Sie
Berechtigungsregeln und Benutzerberechtigungen fest und schützen Sie die
physische Datenumgebung gegen Sicherheitsverstöße.
7. Beschränken Sie den Zugriff auf Daten von Karteninhabern auf Personen
mit berechtigtem Geschäftsinteresse.
8. Ordnen Sie jeder Person mit Zugriff auf den Computer eine eindeutige
ID zu.
9. Schränken Sie den physischen Zugriff auf die Daten von Karteninhabern
ein.
Regelmäßiges Überwachen und Testen von Netzen
Bewerten Sie Ihre aktuelle Sicherheitssituation und vergewissern Sie sich,
dass Ihr Unternehmen sicher arbeitet, gegen Netz- und Sicherheitslücken
geschützt ist und den erforderlichen Regelungen entspricht.
10. Verfolgen und überwachen Sie den gesamten Zugriff auf Netzressourcen und die Daten von Karteninhabern.
11. Testen Sie die Sicherheitssysteme und -prozesse regelmäßig.
Implementieren einer Informationssicherheitsstrategie
Implementieren, veröffentlichen, verteilen und pflegen Sie eine Sicherheitsstrategie, die die Methoden Ihres Unternehmens zur Einhaltung von
Sicherheitsvereinbarungen definiert und umsetzt.
12. Implementieren Sie eine Strategie für die Informationssicherheit für
Mitarbeiter und Auftragnehmer.
PCI DSS-Anforderungen
Die zwölf Punkte werden nun im Einzelnen erläutert, und es werden Empfehlungen zur Anwendung dieser Richtlinien in Ihrer Einzelhandelsumgebung gegeben.
1. Installieren und pflegen Sie eine Firewallkonfiguration zum Schutz der Daten
von Karteninhabern.
v Das Ziel ist die Kontrolle des Computerdatenverkehrs in das Netz und aus dem
Netz.
v Verwenden Sie eine dreistufige Methode1 {1}:
– Verwenden Sie eine äußere Firewall zum Schutz der DMZ.
– Richten Sie den Web-Server in der DMZ ein.
– Verwenden Sie ein innere Firewall zum Schutz des Produktionsnetzes gegenüber der DMZ.
Trennen Sie Ihr Produktionsnetz von Ihrem Intranet.1
{2}
2. Verwenden Sie keine Standardeinstellungen des Herstellers für Systemkennwörter und andere Sicherheitsparameter.
43
v Richten Sie den Benutzerzugriff auf der Basis von Richtlinien ein und verwenden Sie keine Standardeinstellungen.
v Führen Sie keine Muster, die mit Produkten bereitgestellt werden, in der
Produktionsumgebung aus.1 {13}
v Entfernen Sie JDKs, die vom Web-Server, vom Anwendungsserver und von
Plug-in-Installationsprogrammen stammen.1 {28}
v Definieren Sie keine Standard-Benutzer-ID und kein Standardkennwort für eine
Ressource. 2 {49}
3. Schützen Sie gespeicherte Daten von Karteninhabern.
v Begrenzen Sie das Speichern der Daten von Karteninhabern auf ein Minimum.
v Machen Sie die Daten von Karteninhabern für unbefugt zugreifende Personen
unbrauchbar, indem Sie sicherstellen, dass das Speichern und der Backup von
Daten gesichert und verschlüsselt erfolgen und dass alle gelöschten Daten nicht
wiederherstellbar sind.
v Zeichnen Sie keine sensiblen Informationen in Traces oder Prüfprotokollen auf.
1
{45}
4. Verschlüsseln Sie die Übertragung der Daten von Karteninhabern in offenen
bzw. öffentlich zugänglichen Netzen.
v Verwenden Sie HTTPS im Browser, wenn Sie Authentifizierungen oder sonstige
Vorgänge durchführen, die geschützt ablaufen müssen. 1 {4}
v Konfigurieren Sie eine gesicherte Dateiübertragung. Ein Grund hierfür ist, dass
Knotenagenten Administrationskonfigurationsaktualisierungen über einen nicht
authentifizierten Dateiübertragungsservice abrufen. 1 {5} (WebSphere Application
Server)
v Konfigurieren Sie Zertifikate, um eine angemessene webbasierte Administratorzertifikatsprüfung zu gewährleisten, indem Sie die Standardschlüsselringdatei
aktualisieren. 1 {6} (WebSphere Application Server)
v Ändern Sie die Standardschlüsseldatei (DummyServerKeyFile) und erstellen Sie
einen eigenen privaten Schlüssel und ein eigenes Zertifikat für die Kommunikation. 1 {11} (WebSphere Application Server)
v Verschlüsseln Sie die Standardlinks für die Nachrichtenübertragung, indem Sie
den InboundSecureMessaging-Transport verwenden. 1 {21} (WebSphere Application Server)
v Verschlüsseln Sie die WebSphere MQ-Nachrichtenübertragungslinks, wenn Sie
WebSphere MQ anstelle des Standard-Messaging-Providers verwenden. 1 {22}
(WebSphere Application Server)
v Schützen Sie die Anwendungsserververbindung zur Datenbank, um die Verschlüsselung zwischen dem Client und der Datenbank sicherzustellen. 1 {25}
5. Verwenden Sie Virenschutzsoftware bzw. Antivirenprogramme und aktualisieren Sie diese regelmäßig.
Verwenden Sie stets die neuesten Patches und Programmkorrekturen.
1 {31}
6. Entwickeln und pflegen Sie sichere Systeme und Anwendungen.
v Beheben Sie Schwachstellen bei neuen und vorhandenen Systemen und Anwendungen. Sie müssen gewährleisten, dass kein Zugriff möglich ist, indem Sie
Sicherheitslücken und sicherheitsrelevante Ereignisse in Ihrer Infrastruktur
bewerten, überwachen, verwalten, analysieren und dokumentieren.
44
v Aktivieren Sie die globale Sicherheit. Standardmäßig stellt IBM WebSphere
Application Server keine Sicherheit bereit. 1 {3} (WebSphere Application Server)
v Verschlüsseln Sie die WebSphere Application Server-LDAP-Verbindung. 1 {10}
v Schützen Sie die privaten Schlüssel auf Ihren Dateisystemen vor gemeinsamem
Zugriff. 1 {16}
v Inaktivieren Sie nicht verwendete Ports und Services. 1 {32}
v Stellen Sie sicher, dass alle Servletaliasnamen sicher sind, indem Sie in der Datei
’web.xml’ die entsprechenden Angaben machen. 1 {34}
v Verwenden Sie für die Bereitstellung von Servlets keine Klassennamen. 1 {35}
v Speichern Sie keine sensiblen Informationen im WAR-Stammverzeichnis. 1 {35}
v Definieren Sie eine Standardfehlerbehandlungsroutine, um zu verhindern, dass
Benutzer die unformatierten Nachrichten sehen. 1 {36}
v Ziehen Sie in Betracht, Dateiservices und das Browsing von Verzeichnissen zu
inaktivieren. 1 {37} (WebSphere Application Server)
v Aktivieren Sie die Sitzungssicherheit. 1 {38} (WebSphere Application Server)
v Verwenden Sie die WebSphere Application Server-Sicherheit, um Anwendungen
zu schützen. 1 {40} (WebSphere Application Server)
v Sichern Sie jede Anwendungsebene, vor allem EJBs. 1 {41}
v Überprüfen Sie die gesamte Benutzereingabe, um sicherzustellen, dass sie keine
potenziell gefährlichen Sonderzeichen enthält. 1 {43}
v Sperren Sie inaktive Benutzer, sobald die Sitzung nicht mehr benötigt wird. 1 {46}
v Aktivieren Sie die Java 2-Sicherheit, sodass die J2EE-Spezifikationen umgesetzt
werden, um die internen WebSphere Application Server-APIs vor unbefugtem
Zugriff zu schützen. 2 {49} (WebSphere Application Server)
v Aktivieren Sie die Klasse MQADMIN und definieren Sie die entsprechenden
Profile zum Schutz von Ressourcen in Befehlen. 3 {5} (WebSphere MQ)
v Starten Sie WebSphere MQ nicht über Rootzugriff, sondern über die MQSeriesAdministrator-ID ’mqm’ unter UNIX. (WebSphere MQ)
v Erstellen Sie WebSphere MQ-Objekte nur mit der Benutzer-ID ’mqm’ unter
UNIX. (WebSphere MQ)
7. Beschränken Sie den Zugriff auf Daten von Karteninhabern auf Personen mit
berechtigtem Geschäftsinteresse.
v Schränken Sie den Zugriff auf WebSphere MQ-Nachrichtenwarteschlangen ein,
indem Sie Benutzerauthentifizierung verwenden. 1 {9} (WebSphere Application
Server) (WebSphere MQ)
v Geben Sie in der Befehlszeile keine Kennwörter als Parameter für Tools und
Anwendungen an. 1 {19}
v Erstellen Sie separate IDs für Benutzer mit Verwaltungsaufgaben auf der Basis
der Benutzerrolle. Beispiel: Administrator, Bediener, Überwachungsbeauftragter
und Konfigurationsbeauftragter. 1 {26, 27}
v Wählen Sie die geeignete Prozess-ID auf Betriebssystemebene aus. 1 {29}
v Stellen Sie sicher, dass nur berechtigte Benutzer über Zugriff auf folgende DB2Komponenten verfügen: 4 (DB2)
– Katalogsichten
– Protokoll-Lesefunktionen
45
–
–
–
–
–
Datenreplikation
Ausnahmetabellen
Backup-Tabellenbereich oder -Datenbank
Traces
Speicherauszugsdateien
– db2dart
– db2cat
8. Ordnen Sie jeder Person, die über Zugriff auf den Computer verfügt, eine eindeutige ID zu.
v Stellen Sie sicher, dass Aktionen für kritische Daten und Systeme von bekannten
und berechtigten Benutzern ausgeführt werden und diesen zugeordnet werden
können.
v Definieren Sie keine Standard-Benutzer-ID und kein Standardkennwort für eine
Ressource. 2 {49}
9. Schränken Sie den physischen Zugriff auf die Daten von Karteninhabern ein.
v Kontrollieren Sie den physischen Zugang zu den gespeicherten Daten.
v Schützen Sie den JNDI-Namensbereich durch Einschränkung des Schreib-/
Lesezugriffs. 1 {7, 8}
10. Verfolgen und überwachen Sie den gesamten Zugriff auf Netzressourcen und
die Daten von Karteninhabern.
v Sorgen Sie für Transparenz bei Ihrer Datensicherheit, indem Sie es möglich
machen, Benutzeraktivitäten zu verfolgen und zu überwachen und die Ursachen
von Sicherheitsverstößen zu bestimmen.
v Zeichnen Sie keine sensiblen Informationen in Traces oder Prüfprotokollen auf. 1
{45}
11. Testen Sie die Sicherheitssysteme und -prozesse regelmäßig.
Nutzen Sie Methoden wie das Scannen von Ports, Tests zur Gewährleistung der
Sicherheit vor unbefugtem Zugriff und präventives Hacken, um festzustellen, ob
Ihr Netz und Ihre Systeme die Sicherheitsanforderung erfüllen.
12. Implementieren Sie eine Strategie für die Informationssicherheit für Mitarbeiter und Auftragnehmer.
Stellen Sie sicher, dass die Mitarbeiter über ihre Aufgaben und ihre Verantwortung
hinsichtlich der Informationssicherheit informiert sind.
IBM Sicherheitslösungen für Payment Card Industry Data Security Standard (PCI DSS)
Wenn Sie für Ihr Unternehmen die Kompatibilität mit PCI DSS anstreben, bietet
Ihnen IBM ein umfassendes Lösungsportfolio und ein Gesamtkonzept, mit dem Sie
dieses Ziel erreichen können. Zur IBM PCI DSS-Lösung gehören Beratungsleistungen für die Analyse von Kompatibilitätslücken, Korrektur, Prüfung, kontinuierliches Testen und Dokumentieren sowie eine Reihe von Produkten, die Unternehmen bei den einzelnen Aspekten der Sicherheitsplanung, Verwaltung und der
Kompatibilitätsprotokollierung unterstützen. Darüber hinaus ist IBM eines von
weltweit nur drei Unternehmen, die global zertifiziert sind, PCI-Bewertungen
(PCI Assessment), ein vierteljährliches PCI-Netzscanning (PCI Quarterly Network
46
Scanning), PCI-Zahlungsanwendungsbewertungen (PCI Payment Application
Assessments) und Services zur Reaktion auf Störungen im Zusammenhang mit PCI
(PCI Incident Response Services) auszuführen. Nur IBM bietet Lösungen, die alle
zwölf PCI DSS-Anforderungen berücksichtigen.
Weitere Informationen zur IBM PCI-Lösung finden Sie unter der folgenden
Adresse: http://www.ibm.com/software/tivoli/governance/security/pci.html.
47
48
Kapitel 5. Erweiterung
In diesem Abschnitt werden die Tasks beschrieben, die an der Erweiterung von
IBM WebSphere Remote Server beteiligt sind.
Lösung erweitern
IBM WebSphere Remote Server bietet bei der Implementierung auf einem ISP einen
umfassenden Software-Stack als Basis für serverbasierte Anwendungen, die im
Geschäft (oder in der Filiale) ausgeführt werden.
Der Software-Stack ist für sich genommen erst dann vollständig, wenn mindestens
eine Anwendung für die Ausführung mit WebSphere Remote Server installiert und
konfiguriert ist. Die WebSphere Remote Server-Entwicklungsumgebung stellt die
Tools bereit, die für die Erweiterung von WebSphere Remote Server mit Ihren
Anwendungen erforderlich sind. Express Runtime Developer ist das zentrale Tool
für die Entwicklung einer angepassten Lösung, mit der Ihre Anwendung in den
WebSphere Remote Server-Software-Stack integriert wird. Teil der WebSphere
Remote Server-Entwicklungsumgebung ist ein Arbeitsbereich mit allen Anwendungsprojekten und Musterlösungsprojekten, die Sie für die Entwicklung einer
eigenen Lösung benötigen.
Zur Entwicklung einer angepassten Lösung können Sie die vorhandenen
Anwendungsprojekte, mit denen die Middlewarekomponenten und Fixpacks
installiert werden, wiederverwenden. Darüber hinaus müssen Sie Anwendungsprojekte zur Installation und Konfiguration Ihrer Anwendung entwickeln. Der
WebSphere Remote Server-Arbeitsbereich stellt Musterprojekte zur Verfügung, die
mit keinem oder nur geringem Codeentwicklungsaufwand kopiert und in Ihrer
Lösung wiederverwendet werden können.
Methoden zum Entwickeln von angepassten Lösungen
Es gibt zwei allgemeine Methoden, wie WebSphere Remote Server durch die Entwicklung angepasster Lösungen erweitert werden kann.
Die erste Methode eignet sich am besten für eine J2EE-Anwendung. Die Anwendung ’Plants By WebSphere’ wird mithilfe einer Gruppe von Arbeitsbereichsprojekten als Muster bereitgestellt und bietet eine angepasste Lösung, die etwas
Scripterstellung, aber nur wenig bzw. keine Java-Codierung umfasst.
Die zweite Methode eignet sich am besten für Anwendungen wie Standalone-Server oder Anwendungen, die mithilfe eines Installationsprogramms gepackt wurden. Bei dieser Methode ist im Allgemeinen mehr Java-Codeentwicklung erforderlich. Der WebSphere Remote Server-Arbeitsbereich stellt jedoch auch hierfür
Dienstprogrammklassen zur Verfügung, die die von Express Runtime Developer
bereitgestellte API erweitern und so die Entwicklung beschleunigen.
Musterlösungen
Zu den in der WebSphere Remote Server-Entwicklungsumgebung bereitgestellten
Musterlösungen gehört unter anderem ’Trade Performance Benchmark Sample for
IBM WebSphere Application Server’ (Trade) als Musteranwendung.
49
Im Kontext der Musterlösungen wird Trade in zwei Anwendungsprojekte unterteilt. Das erste Projekt, TradeInstall, kopiert die Anwendungsdateien von Trade auf
den Server. Das zweite Anwendungsprojekt, TradeConfig, konfiguriert Trade für
die Ausführung auf dem Server. Dank diesem zweiphasigen Verfahren zur Installation und Konfiguration der Anwendung kann der Kunde flexibel entscheiden,
wann die Konfigurationsphase beginnt. Die Installation und die Konfiguration können gleichzeitig im Rahmen der Erstinstallation der Lösung erfolgen, oder die Konfiguration kann einige Zeit nach der Erstinstallation der Lösung durchgeführt werden.
Einer der Vorteile bei einer separaten Konfigurationsphase besteht darin, dass die
Konfiguration bei Bedarf wiederholt werden kann, ohne dass die gesamte Lösung
erneut installiert werden muss. Das Zurückstellen der Konfiguration ist auch in
umfangreichen Implementierungsszenarios vorteilhaft, wenn die Server auf einem
zentralen System vorkonfiguriert werden, jedoch nach ihrer Implementierung angepasst werden müssen.
Bei der in den Musterlösungen enthaltenen Anwendung Trade wird ein Großteil
der Arbeit in der Konfigurationsphase ausgeführt. In der Installationsphase werden
die EAR-Datei und die Scripts kopiert, die zum Konfigurieren der Anwendung
benötigt werden. In der Konfigurationsphase werden eine Datenbank mit Tabellen
erstellt, die Anwendung in WebSphere Application Server implementiert, ein Script
zum Konfigurieren der Anwendung ausgeführt und ein Servlet zum Füllen der
Datenbank aufgerufen. Die beiden ersten Schritte der Konfigurationsphase können
in der Installationsphase ausgeführt werden.
Um das zweiphasige Verfahren zur Installation und Konfiguration Ihrer Anwendung nutzen zu können, müssen Sie in Express Runtime Developer zwei
Anwendungsprojekte erstellen. Das Anwendungsprojekt für die Konfigurationsphase wird als Task zum Lösungsprojekt WrsApplicationConfigurator (WebSphere
Remote Server – Anwendungskonfigurationsprogramm) hinzugefügt. Wenn Sie die
Anweisungen zum Erstellen der Musterlösung befolgen, wird die Lösung
WrsApplicationConfigurator als Solution Launcher-Image exportiert. Dies wiederum ist der Inhalt des Implementierungsvorbereitungspakets für das in der
Musterlösung enthaltene Anwendungsprojekt ConfigWrapper (Wrapper für
Anwendungskonfigurationsprogramm). Das Anwendungsprojekt für die
Installationsphase wird einfach als Task zu der Musterlösung hinzugefügt.
Auch wenn die Anwendung auf das zweiphasige Verfahren ausgelegt ist, können
die Installation und die Konfiguration gleichzeitig erfolgen. Dazu müssen die
Anwendungsprojekte für die Installationsphase und die Konfigurationsphase in
derselben Lösung enthalten sein. In diesem Fall kann das Anwendungsprojekt
ConfigWrapper aus der Musterlösung entfernt werden, und die Lösung WrsApplicationConfigurator muss nicht erstellt und exportiert werden.
WebSphere sMash
Das IBM WebSphere sMash-Anwendungsprojekt installiert WebSphere sMash und
IBM Reliable Transport Extension for WebSphere sMash.
Wenn Sie WebSphere sMash installieren, wird das IBM Reliable Transport Extension for WebSphere sMash-Image in einem Unterverzeichnis mit dem Namen
sMashRTE ebenfalls dem WebSphere sMash-Image hinzugefügt. Sie können
WebSphere sMash nicht ohne IBM Reliable Transport Extension for WebSphere
sMash installieren, es sei denn, Sie führen die Installation mithilfe der Produktplatten durch.
50
Details dazu, wie Sie prüfen, dass WebSphere sMash installiert wurde, finden Sie
im Abschnitt „WebSphere sMash prüfen” auf Seite 24.
Anmerkung: Die unter Basic Application Configuration für Smash_1101-Projekte
aufgeführte Versionsnummer lautet 1.1.0; tatsächlich installiert wurde
jedoch Version 1.1.0.1. WebSphere sMash aktualisiert die Versionsnummer des Produkts für ein Fixpack nicht.
Weitere Informationen zur Verwendung von WebSphere sMash finden Sie im
WebSphere sMash Information Center.
Musterlösung erstellen
Dieser Abschnitt enthält Anweisungen zum Erstellen der Lösungsprojekte ’SampleSolutionForWindows’ (Musterlösung für Windows) und ’SampleSolutionForLinux’
(Musterlösung für Linux).
Muster erstellen
Gehen Sie wie folgt vor, um eine DVD der Musterlösung zu erstellen:
1. Öffnen Sie Express Runtime Developer.
2. Generieren Sie die Lösung ’WrsApplicationConfiguratorWithDB2’ oder die
Lösung ’WrsApplicationConfiguratorWithInformix’.
a. Erweitern Sie im Fenster Express Runtime Explorer die Kategorie Configuration Phase.
b. Erweitern Sie die Kategorie Solution Projects.
c. Klicken Sie mit der rechten Maustaste auf das Projekt WrsApplicationConfiguratorWithDB2 oder auf das Projekt WrsApplicationConfiguratorWithInformix.
d. Wählen Sie Generate Solution aus.
e. Klicken Sie im Fenster Solution Generation Successful auf OK.
3. Exportieren Sie die Lösung ’WrsApplicationConfiguratorWithDB2’ oder die
Lösung ’WrsApplicationConfiguratorWithInformix’.
a. Klicken Sie mit der rechten Maustaste auf das Projekt WrsApplicationConfiguratorWithDB2 oder auf das Projekt WrsApplicationConfiguratorWithInformix.
b. Wählen Sie Export... aus.
c. Erweitern Sie im Fenster Export die Option Express Runtime.
d. Wählen Sie Express Runtime Solution Launcher Image aus und klicken Sie
auf Next.
e. Setzen Sie den Wert für Media size (MB) auf 650.
f. Geben Sie im Feld Export files to Folgendes ein:
C:\export\WAC
/tmp/export/WAC
g. Wählen Sie unter Operating systems die Optionen Windows und Linux
aus.
h. Klicken Sie auf Next.
i. Wählen Sie Do not export any deployment packages aus.
j. Klicken Sie auf Next.
k. Wählen Sie die Sprachen (Languages) aus und klicken Sie auf Finish.
51
l. Klicken Sie bei der Eingabeaufforderung Target directory does not exist.
Would you like to create it? auf Yes.
m. Klicken Sie im Fenster Solution Export Successful auf Yes oder No, um die
Frage nach dem Erfolg des Lösungsexports zu beantworten.
4. Generieren Sie das Implementierungspaket ’ConfigWrapperWithDb2’ oder die
Lösung ’ConfigWrapperWithInformix’.
Erweitern Sie die Kategorie Installation Phase.
Erweitern Sie die Kategorie Application Projects.
Erweitern Sie die Kategorie Common.
Klicken Sie mit der rechten Maustaste auf ConfigWrapperWithDb2 oder auf
ConfigWrapperWithInformix und wählen Sie Generate Deployment
Packages aus.
e. Geben Sie im Fenster Specify Location Folgendes ein:
C:\export\WAC\disk1
/tmp/export/WAC/disk1
a.
b.
c.
d.
Anmerkung: Dies ist die Position der zuvor exportierten Lösung
’WrsApplicationConfiguratorWithDB2’ oder ’WrsApplicationConfiguratorWithInformix’ mit dem angehängten Verzeichnis disk1.
f. Klicken Sie auf OK.
g. Klicken Sie im Fenster Deployment Package Generation Successful auf
OK.
5. Generieren Sie das Implementierungspaket TradeInstall.
Anmerkung: Informix Dynamic Server unterstützt die Handelsanwendung
nicht.
a. Erweitern Sie die Kategorie Installation Phase.
b. Erweitern Sie die Kategorie Application Projects.
c. Erweitern Sie die Kategorie Common.
d. Klicken Sie mit der rechten Maustaste auf TradeInstall und wählen Sie
Generate Application aus.
e. Klicken Sie mit der rechten Maustaste auf TradeInstall und wählen Sie
Generate Deployment Packages aus.
f. Geben Sie im Fenster Specify Location Folgendes ein:
C:\Program Files\IBM\SIF\workspace\irss70\TradeInstall\
installpackage
/opt/IBM/SIF/workspace/irss70/TradeInstall/installpackage
g. Klicken Sie auf OK.
h. Klicken Sie im Fenster Deployment Package Generation Successful auf
OK.
6. Generieren Sie die Lösung ’SampleSolutionForWindowsWithDB2’ bzw. ’SampleSolutionForWindowsWithInformix’ oder die Lösung
’SampleSolutionForLinuxWithDB2’ bzw. ’SampleSolutionForLinuxWithInformix’.
a.
b.
c.
d.
52
Erweitern Sie die Kategorie Installation Phase.
Erweitern Sie die Kategorie Solution Projects.
Erweitern Sie die Kategorie Windows oder die Kategorie Linux.
Klicken Sie mit der rechten Maustaste auf das Lösungsprojekt.
’SampleSolutionForWindowsWithDB2’ bzw. ’SampleSolutionForWindowsWithInformix’
’SampleSolutionForLinuxWithDB2’ bzw. ’SampleSolutionForLinuxWithInformix’
e. Wählen Sie Generate Solution aus.
f. Klicken Sie im Fenster Solution Generation Successful auf OK.
7. Exportieren Sie die Lösung ’SampleSolutionForWindowsWithDB2’ bzw. ’SampleSolutionForWindowsWithInformix’ oder die Lösung
’SampleSolutionForLinuxWithDB2’ bzw. ’SampleSolutionForLinuxWithInformix’.
a. Klicken Sie mit der rechten Maustaste auf das Lösungsprojekt.
’SampleSolutionForWindowsWithDB2’ bzw. ’SampleSolutionForWindowsWithInformix’
’SampleSolutionForLinuxWithDB2’ bzw. ’SampleSolutionForLinuxWithInformix’
b. Wählen Sie Export... aus.
c. Erweitern Sie im Fenster Export die Option Express Runtime.
d. Wählen Sie Express Runtime Solution Launcher Image aus und klicken Sie
auf Next.
e. Setzen Sie den Wert für Media size (MB) auf 650, um CD-Medien zu erstellen, oder auf 4482, um DVD-Medien zu erstellen.
Diese Zahl spielt nur dann eine Rolle, wenn Sie vorhaben, die Daten auf
CD- oder DVD-Datenträger zu kopieren.
f. Exportieren Sie die Dateien an folgende Position:
C:\export\SampleSolutionForWindows
/tmp/export/SampleSolutionForWindows
g. Wählen Sie unter Operating systems die Option Windows oder Linux aus.
h. Klicken Sie auf Next.
i. Wählen Sie Export all deployment packages (typical) aus und klicken Sie
auf Next.
j. Klicken Sie auf Next.
k. Wählen Sie die Sprachen (Languages) aus und klicken Sie auf Next.
l. Klicken Sie auf Finish.
m. Klicken Sie bei der Eingabeaufforderung Target directory does not exist.
Would you like to create it? auf Yes.
n. Klicken Sie im Fenster Solution Export Successful auf Yes oder No, um die
Frage nach dem Erfolg des Lösungsexports zu beantworten.
Ändern Sie die Musterlösung.
Musterlösung für unbeaufsichtigte Installation vorbereiten
Eine unbeaufsichtigte Installation wird normalerweise für die Implementierung
über Remotezugriff verwendet. Bei einer unbeaufsichtigten Installation ruft das
Installationsprogramm die Konfigurationsinformationen aus einer Datei ab, nicht
vom Benutzer über eine grafische Benutzerschnittstelle.
Zum Generieren einer Lösung, die unbeaufsichtigt installiert wird, müssen zwei
Schritte ausgeführt werden.
53
1. Erstellen Sie eine Taskdatei, in der die Tasks und Anwendungsprojektinformationen aufgeführt sind, die bei der Installation der Lösung verwendet
werden.
2. Aktivieren Sie beim Export der Lösung die Option Run installation silently.
Mit jeder Musterlösung werden auch Mustertaskdateien bereitgestellt. Die Taskdateien befinden sich im Verzeichnis tasks unterhalb der Musterprojektverzeichnisse.
Der Taskdateiname für jedes der Musterprojekte lautet taskList.xml.
Informationen zu den Taskdateien und zur unbeaufsichtigten Installation finden
Sie im Menü Help von Express Runtime Developer.
Musterlösung ändern
Es empfiehlt sich, die Musterlösung zunächst zu erstellen, bevor Sie sie ändern.
Dadurch wird sichergestellt, dass die Entwicklungsumgebung und die Musterlösung ordnungsgemäß installiert wurden. Es empfiehlt sich, die Erstellung auf
einer geschützten Basis zu starten.
Zum Ändern der Musterlösung müssen Sie die Konzepte von Express Runtime
Developer verstehen. Express Runtime Developer stellt Cheat-Sheets im Menü
Help bereit. Überprüfen Sie folgende Cheat-Sheets:
v Lösungswrapper erstellen
v WebSphere-Anwendungsimplementierungsprojekt erstellen
v Anwendungswrapper erstellen
v Solution Launcher-Image exportieren und implementieren
v Express Runtime Developer verwenden
Sie können die Musterlösung auf unterschiedliche Weise ändern. Folgende Möglichkeiten stehen zur Verfügung:
v Musteranwendung entfernen
v Middlewareprodukt entfernen
v Eigene Anwendung oder Middleware hinzufügen
v Weitere Konfigurationsoptionen für die Anwendungsprojekte bereitstellen
Zum Entfernen der Musteranwendung oder der Middleware müssen Sie das Projekt mit der Musterlösung öffnen. Entfernen Sie auf der Registerkarte Tasks die
Anwendungsprojekte aus der Taskliste.
Wenn Sie eine eigene Anwendung oder ein eigenes Middlewareprodukt hinzufügen wollen, müssen Sie ein Anwendungsprojekt und den für die Installation erforderlichen Quellcode erstellen. Anschließend erstellen Sie eine Task in dem
Lösungsprojekt, das auf das erstellte Anwendungsprojekt verweist.
Sie können im Musterarbeitsbereich die Konfigurationsoptionen für die vorhandenen Anwendungsprojekte ändern. Öffnen Sie dazu ein Anwendungsprojekt und
wählen Sie die Registerkarte Variables aus. Geben Sie die Variablen für zusätzliche
Werte an, die in der Antwortdatei des Installationsprogramms für die Anwendung
verfügbar sind.
54
WebSphere Remote Server mit einer WebSphere-Musteranwendung
erweitern
IBM WebSphere Remote Server enthält eine Musteranwendung, die eine generischere Lösung bietet, für die deutlich weniger Codeentwicklung erforderlich ist.
WebSphere Remote Server stellt eine vollständige Entwicklungsumgebung mit leistungsfähigen Tools zur Verfügung, die Sie bei der Entwicklung von integrierten
Lösungen unterstützen. Diese Lösungen können ohne großen Aufwand in konsistenter Art und Weise implementiert werden. Solution Assembly Toolkit ist das
Haupttool, in dem das Express Runtime Developer-Plug-in für Eclipse enthalten
ist. Darüber hinaus ist ein vollständiger Eclipse-Arbeitsbereich mit allen notwendigen Anwendungs- und Lösungsprojekten enthalten, die für die Entwicklung einer
vollständigen Lösung auf der Basis von WebSphere Remote Server benötigt werden.
’Trade Performance Benchmark Sample for IBM WebSphere Application Server’
(Trade) ist als Musteranwendung in der WebSphere Remote Server-Lösungsentwicklungsumgebung enthalten. Die Anwendung wird von zwei Anwendungsprojekten mit dem Namen TradeInstall und TradeConfig installiert und konfiguriert. Diese Anwendungsprojekte stellen eine Methode dar, mit der eine
WebSphere-Anwendung auf der Basis eines WebSphere Remote Server-Middleware-Stacks implementiert und konfiguriert werden kann. Besonders das Projekt ’TradeConfig’ veranschaulicht die Implementierung einer J2EE-Anwendung und die
Konfiguration der DB2 Workgroup Server Edition-Datenbank mithilfe von Scripts
und anderem Code.
Um dieselbe Methode auf eine andere Anwendung anzuwenden, ist ein beträchtliches Maß an Code- und Scriptentwicklungsarbeit erforderlich, da die verwendeten Scripts speziell auf die Anwendung Trade zugeschnitten sind. WebSphere
Remote Server enthält eine Musteranwendung, die eine generischere Lösung bietet,
für die deutlich weniger Codeentwicklung erforderlich ist. In diesem Abschnitt
wird die Methode beschrieben. Der Arbeitsbereich, der als Teil der WebSphere
Remote Server-Lösungsentwicklungsumgebung installiert wird, enthält mehrere
Express Runtime Developer-Projekte, in denen die Methode veranschaulicht wird.
Bei der Musteranwendung handelt es sich um eine geänderte Version der J2EEMusteranwendung ’Plants By WebSphere’. Diese Anwendung wurde so geändert,
dass sie JMS-Ressourcen einschließt, die eine Kommunikation mit IBM WebSphere
MQ ermöglichen; dadurch verfügen Sie über ein Beispiel, in dem der vollständige
WebSphere Remote Server-Middleware-Stack Anwendung findet.
Erläuterung des Mustercodes
In diesem Abschnitt werden verschiedene Projekte beschrieben, aus denen sich der
Mustercode zusammensetzt. Außerdem erfahren Sie, wie Sie diese Projekte bei der
Entwicklung Ihrer Anwendung verwenden können.
Mustercode - Übersicht
Der Arbeitsbereich enthält die folgenden Projekte, aus denen sich der Mustercode
zusammensetzt:
v Db2Configuration: Dieses Projekt wurde als Schablonenprojekt entworfen, das
Sie in Ihre Lösung kopieren und dort wiederverwenden können. Dieses Projekt
wurde entworfen, um eine einzelne Datenbank und die nötigen Tabellen zu
erstellen sowie um optional die Tabellen zu füllen. Wenn in Ihrer Lösung mehrere Datenbanken erforderlich sind, können Sie mehrere (natürlich umbenannte)
55
Kopien dieses Projekts in Ihrer Lösung verwenden. Sie benötigen dieses Projekt,
wenn in Ihrer Lösung eine DB2-Datenbank verwendet wird.
v IdsConfiguration: Dieses Projekt wurde als Schablonenprojekt entworfen, das
Sie in Ihre Lösung kopieren und dort wiederverwenden können. Dieses Projekt
wurde entworfen, um eine einzelne Datenbank und die nötigen Tabellen zu
erstellen sowie um optional die Tabellen zu füllen. Wenn in Ihrer Lösung mehrere Datenbanken erforderlich sind, können Sie mehrere (natürlich umbenannte)
Kopien dieses Projekts in Ihrer Lösung verwenden. Sie benötigen dieses Projekt,
wenn in Ihrer Lösung eine Informix Dynamic Server-Datenbank verwendet wird.
v MqConfiguration: Bei diesem Projekt handelt es sich um ein weiteres
Schablonenprojekt, das Sie in Ihre Lösung kopieren und dort wiederverwenden
können. Dieses Projekt wurde entworfen, um einen einzelnen Warteschlangenmanager und alle nötigen Kanäle sowie weitere MQ-Objekte zu erstellen. Werden in Ihrer Lösung mehrere Warteschlangenmanager benötigt, können Sie dieses Projekt so oft wie nötig in Ihre Lösung kopieren und dort umbenennen. Sie
benötigen dieses Projekt, wenn in Ihrer Lösung WebSphere MQ verwendet wird.
v WasStandaloneProfileConfiguration: Dieses Projekt ist ein Schablonenprojekt,
das Sie in Ihre Lösung kopieren und dort wiederverwenden können. Es erstellt
einen Standalone-Anwendungsserver. Zu jedem Profil eines Standalone-Anwendungsservers gehört ein Anwendungsserverprozess ’server1’. Jedes Profil
definiert einen separaten Standalone-Anwendungsserver, der über eine eigene
Verwaltungsschnittstelle verfügt.
v PlantsByWebSphereDeployment: Dieses Projekt ist ein Musterprojekt, mit dem
veranschaulicht wird, wie eine J2EE-Anwendung in WebSphere Application Server implementiert und konfiguriert werden kann. Bei diesem Projekt handelt es
sich um ein WebSphere Application Server-Projekt, das von Express Runtime
Developer aus einer vorhandenen Implementierung ’Plants By WebSphere’ generiert wird. Dieses Projekt wurde für die Arbeit mit WebSphere Remote Server
erweitert.
v PlantsByWebSphereSolutionForLinuxWithInformix and PlantsByWebSphereSolutionForLinuxWithDb2: Dieses Musterlösungsprojekt ist ein vollständiges
Beispiel, in dem alle oben genannten Musterprojekte und der komplette Satz
Middlewareprojekte enthalten ist. Dieses Projekt ähnelt den Projekten ’SampleSolutionForLinuxWithInformix’ und ’SampleSolutionForLinuxWithDB2’, die ebenfalls in der Entwicklungsumgebung von WebSphere Remote Server enthalten
sind.
v PlantsByWebSphereSolutionForWindowsWithInformix and PlantsByWebSphereSolutionForWindowsWithDb2: Diese Musterlösung ähnelt den Lösungen
’PlantsByWebSphereSolutionForLinuxWithInformix’ und
’PlantsByWebSphereSolutionForLinuxWithDb2’, schließt darüber hinaus aber die
Windows-spezifischen Projekte für die Middlewarekomponenten mit ein.
Diese Projekte werden in den folgenden Abschnitten detaillierter beschrieben.
Projekt ’Db2Configuration’
Das Projekt ’Db2Configuration’ ist ein Anwendungsprojekt von Express Runtime
Developer, das eine einzelne Datenbank erstellt und Scripts ausführt, die zum
Erstellen und Füllen von Tabellen erforderlich sind. Dieses Projekt ist dazu
gedacht, eine Schablone für angepasste Projekte zur Verfügung zu stellen. Der in
der Anwendung bereitgestellte Java-Code ist so verallgemeinert, dass keine Anpassung erforderlich ist. Die in der Anwendung enthaltenen Scripts führen die für Ihre
56
Lösung spezifische Arbeit aus. Das gesamte Anwendungsprojekt kann innerhalb
des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert
werden.
Variablen
Dieses Projekt weist nur eine Variable namens ’databaseName’ auf. Diese Variable
steht für den Namen der zu erstellenden Datenbank. Sie können die Variable in
Ihrer Lösung mit einem fest codierten Wert überschreiben oder die Benutzereingabe für sie ermöglichen. Diese Variable kann in der Regel mit Variablen im Projekt ’WebSphere Application Deployment’ verknüpft werden, um die nötigen
Datenquellen zu erstellen.
Scriptdateien
Dieses Anwendungsprojekt enthält zwei Scripts:
v tables.ddl: Eine DDL-Datei, die die Tabellen für die Datenbank erstellt. Diese
Datei wird durch Ihre eigene Datei ersetzt, für sie sollte aber derselbe Name beibehalten werden. In der Regel kann eine DDL-Datei von einer vorhandenen
Datenbank mit dem Befehl ’db2look’ erstellt werden. Weitere Informationen
finden Sie im Information Center von DB2 unter der folgenden Adresse:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/
com.ibm.db2.udb.admin.doc/doc/r0002051.htm.
v populate.sql: Eine Scriptdatei mit SQL-Befehlen zum Füllen von Datenbanktabellen. Diese Datei ist optional und die Datenbanktabellen werden nicht
gefüllt, wenn dieses Script im Anwendungsprojekt fehlt. Wenn Sie Ihr eigenes
Script bereitstellen, muss es denselben Namen aufweisen.
Bei den in diesem Projekt enthaltenen Scripts handelt es sich um Musterdateien,
die speziell für die Anwendung ’PlantsByWebSphere’ verwendet werden, und Sie
müssen diese Scripts durch Ihre eigenen Scripts ersetzen.
Projekt ’IdsConfiguration’
Das Projekt ’IdsConfiguration’ ist ein Anwendungsprojekt von Express Runtime
Developer, das eine einzelne Datenbank erstellt und Scripts ausführt, die zum
Erstellen und Füllen von Tabellen erforderlich sind. Dieses Projekt ist dazu
gedacht, eine Schablone für angepasste Projekte zur Verfügung zu stellen. Der in
der Anwendung bereitgestellte Java-Code ist so verallgemeinert, dass keine Anpassung erforderlich ist. Die in der Anwendung enthaltenen Scripts führen die für Ihre
Lösung spezifische Arbeit aus. Das gesamte Anwendungsprojekt kann innerhalb
des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert
werden.
Variablen
Dieses Projekt weist nur eine Variable namens ’databaseName’ auf. Diese Variable
steht für den Namen der zu erstellenden Datenbank. Sie können die Variable in
Ihrer Lösung mit einem fest codierten Wert überschreiben oder die Benutzereingabe für sie ermöglichen. Diese Variable kann in der Regel mit Variablen im Projekt ’WebSphere Application Deployment’ verknüpft werden, um die nötigen
Datenquellen zu erstellen.
57
Scriptdateien
Dieses Anwendungsprojekt enthält zwei Scripts:
v tables.sql: Eine SQL-Datei, die die Tabellen für die Datenbank erstellt. Diese
Datei wird durch Ihre eigene Datei ersetzt, für sie sollte aber derselbe Name beibehalten werden.
v populate.sql: Eine Scriptdatei mit SQL-Befehlen zum Füllen von Datenbanktabellen. Diese Datei ist optional und die Datenbanktabellen werden nicht
gefüllt, wenn dieses Script im Anwendungsprojekt fehlt. Wenn Sie Ihr eigenes
Script bereitstellen, muss es denselben Namen aufweisen.
Bei den in diesem Projekt enthaltenen Scripts handelt es sich um Musterdateien,
die speziell für die Anwendung ’PlantsByWebSphere’ verwendet werden, und Sie
müssen diese Scripts durch Ihre eigenen Scripts ersetzen.
Projekt ’MqConfiguration’
Das Projekt ’MqConfiguration’ ist ein Anwendungsprojekt von Express Runtime
Developer, das einen einzelnen Warteschlangenmanager für WebSphere MQ erstellt
und anschließend ein MQSC-Script ausführt, um verschiedene MQ-Objekte wie
Warteschlangen, Kanäle usw. für diesen Warteschlangenmanager zu erstellen. Dieses Projekt soll als Schablone für angepasste Projekte verwendet werden. Der JavaCode, der mit dem Projekt bereitgestellt wird, ist generisch und darf nicht angepasst werden. Die im Projekt eingeschlossenen Scripts führen die Arbeit aus, die
für Ihre spezifische Lösung notwendig ist. Das gesamte Anwendungsprojekt kann
innerhalb des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert werden.
Variablen
Dieses Projekt weist die folgenden Variablen auf:
v queueMgrName: Dies ist der Name des zu erstellenden Warteschlangenmanagers. Der Name kann auf der Lösungsebene mit einem vorher festgelegten
Wert überschrieben werden oder er kann dem Benutzer zum Ändern verfügbar
gemacht werden.
v isDefaultQueueMgr: Dies ist eine boolesche Variable, die festlegt, ob dieser
Warteschlangenmanager als Systemstandardwert verwendet werden soll. In der
Regel nimmt diese Variable standardmäßig den Wert ’true’ (wahr) an, sofern Ihre
Lösung nicht mehrere Warteschlangenmanager benötigt. Der Wert für diese Variable muss während der Entwurfsphase festgelegt werden. Diese Variable sollte
dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v createDeadLetterQueue: Dies ist eine boolesche Variable, die festlegt, ob die
Systemwarteschlange für nicht zustellbare Nachrichten für diesen Warteschlangenmanager erstellt werden soll. In der Regel nimmt diese Variable
standardmäßig den Wert ’true’ (wahr) an, sofern Ihre Lösung nicht mehrere
Warteschlangenmanager benötigt. Diese Variable muss auch auf der Lösungsebene definiert werden, und sie darf dem Benutzer, der die Lösung installiert,
nicht verfügbar gemacht werden.
v createPubSubQueues: Dies ist eine boolesche Variable, die festlegt, ob JMS Publish/Subscribe-Warteschlangen erstellt werden sollen. Wenn der Wert ‘true’
(wahr) ist, wird standardmäßig die Musterdatei ’MQJMS_PSQ.mqsc’ im
WebSphere MQ-Verzeichnis ausgeführt. Enthält das Anwendungsprojekt jedoch
eine Datei namens pubsub.mqsc, wird diese stattdessen ausgeführt. Wenn der
Wert dieser Variable ’false’ (falsch) lautet, werden keine MQSC-Dateien ausge-
58
führt und keine weiteren Warteschlangen erstellt. Diese Variable muss ebenfalls
auf der Lösungsebene definiert werden, und sie darf dem Benutzer, der die
Lösung installiert, nicht verfügbar gemacht werden.
Scriptdateien
Dieses Projekt enthält eine erforderliche MQSC-Scriptdatei. Eine optionale zweite
MQSC-Scriptdatei kann in das Projekt aufgenommen werden, um ein angepasstes
Script für JMS-Publish/Subscribe-Warteschlangen zur Verfügung zu stellen.
v default.mqsc: Dies ist die Standard-MQSC-Scriptdatei, die nach dem Erstellen
des Warteschlangenmanagers ausgeführt wird. Diese Scriptdatei ist erforderlich
und muss den Namen ’default.mqsc’ aufweisen. In der Regel kann diese MQSCDatei aus einer vorhandenen MQ-Installation mithilfe von ’saveqmgr’ (SupportPac) generiert werden. Weitere Informationen finden Sie unter der folgenden
Adresse: http://www.ibm.com/support/docview.wss?uid=swg24000673.
v pubsub.mqsc: Diese Datei ist optional und sie ist standardmäßig nicht in der
Anwendung enthalten. Wird diese Datei dem Anwendungsprojekt hinzugefügt
und hat ’createPubSubQueues’ den Wert ’true’, wird dieses Script ausgeführt.
Diese Option soll bei Bedarf eine Alternative zu dem mit WebSphere MQ bereitgestellten Muster-JMS-Publish/Subscribe-Script darstellen.
Bei der in diesem Projekt enthaltenen Scriptdatei handelt es sich um eine Musterdatei, die speziell für die Anwendung ’PlantsByWebSphere’ verwendet wird, und
Sie müssen dieses Script durch Ihr eigenes Script ersetzen.
Projekt ’WasStandaloneProfileConfiguration’
Das Projekt ’WasStandaloneProfileConfiguration’ ist ein Anwendungsprojekt von
Express Runtime Developer, das einen Standalone-Anwendungsserver erstellt. Zu
jedem Profil eines Standalone-Anwendungsservers gehört ein Anwendungsserverprozess ’server1’. Jedes Profil definiert einen separaten Standalone-Anwendungsserver, der über eine eigene Verwaltungsschnittstelle verfügt.
Variablen
Dieses Projekt weist die folgenden Variablen auf:
v profileName: Der Name des zu erstellenden Profils. Der Profilname muss für
diese WebSphere Application Server-Installation eindeutig sein.
v nodeName: Der Knotenname für den Anwendungsserver. Der Knotenname
muss innerhalb einer Zelle eindeutig sein.
v enableAdminSecurity: Ein boolescher Wert, den Sie festlegen können, um die
Verwaltungssicherheit zu aktivieren. Wenn dieser Wert auf ’true’ (wahr) gesetzt
ist, müssen Benutzer sich anmelden, um auf die Verwaltungstools von
WebSphere Application Server zugreifen zu können. Der Name eines Benutzers
mit Verwaltungsaufgaben und das zugehörige Kennwort sind erforderlich, wenn
diese Option aktiviert ist.
v wasAdminUser: Benutzer-ID für den Zugriff auf WebSphere Application ServerVerwaltungstools. Diese Variable ist erforderlich, wenn Sie die Verwaltungssicherheit verwenden.
v wasAdminPassword: Das Kennwort eines Benutzers mit Verwaltungsaufgaben.
Diese Variable ist erforderlich, wenn Sie die Verwaltungssicherheit verwenden.
v runAsService: Ein boolescher Wert, den Sie festlegen können, um WebSphere
Application Server für die Ausführung als Service zu aktivieren.
59
Scriptdateien
Zum Projekt gehören zwei Scriptdateien.
v CreateDataSource.py: Erstellt eine JDBC-Datenquelle für Ihre DB2- oder Informix Dynamic Server-Datenbank.
v enableWASSecurityLocalOS.jacl: Aktiviert die Sicherheit für WebSphere Application Server.
v
Projekt ’PlantsByWebSphereDeployment’
Das Projekt ’PlantsByWebSphereDeployment’ ist ein WebSphere Application Deployment-Projekt von Express Runtime Developer. Es handelt sich um ein Projekt, das
automatisch von einer vorhandenen WebSphere Application Server-Implementierung unter Verwendung des Assistenten ’New Project’ innerhalb von Express Runtime Developer generiert wird. Dieses Projekt wird mit einer Wrapperklasse erweitert, um die auf WebSphere Remote Server beschränkten Funktionen zu
verwenden.
Dieses Projekt dient als Mustercode, um die Basiselemente eines Projekts
’WebSphere Application Deployment’ darzustellen. Außerdem zeigt es, wie diese
Elemente mit der besonderen Wrapperklasse interagieren. Wenn es an die Umsetzung geht, werden Sie aber Ihr eigenes Projekt auf der Basis Ihrer WebSphere-Anwendung generieren. Weitere Informationen zur Verwendung des Assistenten
’WebSphere Application Deployment Project’ finden Sie unter der folgenden
Adresse: http://publib.boulder.ibm.com/infocenter/eruinf/v2r2/index.jsp?topic=/
com.ibm.iru.doc/concepts/cerwebap.htm.
Anwendungsprojektdateien
Die folgenden Dateien bilden den Kern des Projekts (diese Liste ist nicht vollständig):
v PlantsByWebSphereEAR-1.1.1.ear: Diese J2EE-Archivdatei enthält die Anwendung ’PlantsByWebSphere’. Sie wird automatisch vom Assistenten generiert.
v DeployWebApplications.java: Dies ist das Hauptprogramm, das die Installation
ausführt, indem es den Befehl ’wsadmin’ mit verschiedenen Python-Scripts aufruft, um die Anwendung zu implementieren und zu konfigurieren. Hierbei handelt es sich um den Standardcode, der vom Assistenten generiert wird.
v DeployWebApplications.py und DeployWebApplicationsProfile.py: Diese
Python-Scripts werden von dem Befehl ’wsadmin’ ausgeführt, um die EAR-Datei
zu implementieren und die Anwendung zu konfigurieren. Diese Scripts werden
automatisch vom Assistenten generiert.
v DeployWebApplications.bat: Mit dieser einfachen Batchdatei wird der Befehl
’wsadmin’ im Windows-Betriebssystem aufgerufen. Diese Datei wird vom Assistenten bereitgestellt.
v DeployWebApplications.properties: Diese Eigenschaftendatei agiert als
“Antwortdatei” für die Installation der Anwendung und wird verwendet, um
Variablen von Deployment Wizard an den Java- und Python-Code zu übergeben.
v WrsDeployWebApplications.java: Hierbei handelt es sich um die Wrapperklasse, die dem Projekt hinzugefügt wird. Diese Klasse stellt das Hauptprogramm für das Anwendungsprojekt dar und erweitert die Klasse ’DeployWebApplications’. Dadurch können die Variablen modifiziert werden, die an die
Anwendung übergeben werden, die auf einer vorherigen Installation von
WebSphere Remote Server basiert. Dies ist besonders nützlich, wenn Sie die
60
Verwendung des zwei Phasen umfassenden Data-Warehouse-Modells der Implementierung und Konfiguration planen (wie in der oben angegebenen Veröffentlichung beschrieben wird) oder wenn Sie eine bereits implementierte Lösung mit
einer neuen Anwendung erweitern wollen. Dieser Code soll als Standard dienen,
er muss aber abhängig von Ihrer Anwendung unter Umständen geringfügig
geändert werden.
Variablen
Die im Anwendungsprojekt verfügbaren Variablen sind teilweise auf die Optionen
zurückzuführen, die Sie bei der Ausführung des Assistenten zum Erstellen des Projekts ausgewählt haben. Das Projekt ’PlantsByWebSphereDeployment’ enthält Variablen, die das Ergebnis der Generierung eines typischen Projekts ’WebSphere
WebSphere Application Deployment’ sind. Einige dieser Variablen werden als
Befehlszeilenparameter an die Klasse ’DeployWebApplications’ übergeben, einige
Variablen werden der Antworteigenschaftendatei ’DeployWebApplications.properties’ zugeordnet und einige Variablen werden von der Wrapperklasse ’WrsDeployWebApplications’ auf der Basis der Werte überschrieben, die von einer vorherigen
(oder aktuellen) Installation einer WebSphere Remote Server-Lösung abgerufen
wurden. Diese Variablen werden nachfolgend detaillierter beschrieben:
v WAS_HOME_AIX: Eine Dateipfadvariable, die auf das WebSphere Application
Server-Installationsverzeichnis auf der AIX-Plattform verweist. Da WebSphere
Remote Server derzeit die AIX-Plattform nicht unterstützt, ist diese Variable
standardmäßig eine Nullzeichenfolge. Diese Variable darf dem Benutzer, der die
Lösung installiert, nicht verfügbar gemacht werden.
v WAS_HOME_LINUX: Eine Dateipfadvariable, die auf das WebSphere Application Server-Installationsverzeichnis auf der Linux-Plattform verweist. Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit dem Wert
der Variablen ’installLocation’ aus dem Anwendungsprojekt ’Was_61013_Lnx’
überschrieben. Folglich darf diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v WAS_HOME_OS400: Eine Dateipfadvariable, die auf das WebSphere Application Server-Installationsverzeichnis auf der iSeries-Plattform verweist. Da
WebSphere Remote Server derzeit die iSeries-Plattform nicht unterstützt, ist
diese Variable standardmäßig eine Nullzeichenfolge. Diese Variable darf dem
Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v WAS_HOME_WINDOWS: Eine Dateipfadvariable, die auf das WebSphere
Application Server-Installationsverzeichnis auf der Windows-Plattform verweist.
Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit
dem Wert der Variablen ’installLocation’ aus dem Anwendungsprojekt
’Was_61013_Win’ überschrieben. Folglich darf diese Variable dem Benutzer, der
die Lösung installiert, nicht verfügbar gemacht werden.
v USER: Der WebSphere Application Server-Benutzer mit Verwaltungsaufgaben.
Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit
dem Wert der Variablen ’wasAdminUser’ aus dem Anwendungsprojekt ’WasStandaloneProfileConfiguration’ (WebSphere Application Server - Konfiguration
des Standalone-Profils) überschrieben. Folglich darf diese Variable dem Benutzer,
der die Lösung installiert, nicht verfügbar gemacht werden.
v PASSWORD: Das Kennwort des WebSphere Application Server-Benutzers mit
Verwaltungsaufgaben. Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit dem Wert der Variablen ’wasAdminPassword’ aus dem
Anwendungsprojekt ’WasStandaloneProfileConfiguration’ überschrieben. Folglich
darf diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar
gemacht werden.
61
v databaseName: Der Name der zu erstellenden Datenbank. Diese Variable muss
auf der Lösungsebene mit der Variablen ’databaseName’ aus dem Anwendungsprojekt ’Db2Configuration’ verknüpft werden.
v dsalias_userId: Die Datenbankbenutzer-ID für den Authentifizierungsaliasnamen
’dsAlias’. Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit dem Wert der Variablen ’instanceUser’ aus den Anwendungsprojekten
’Db2_95_Win’ oder ’Db2_95_Lnx’ überschrieben. Folglich darf diese Variable
dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v dsalias_password: Das Datenbankbenutzerkennwort für den Authentifizierungsaliasnamen ’dsAlias’. Diese Variable wird von der Wrapperklasse ’WrsDeployWebApplications’ mit dem Wert der Variablen ’instancePassword’ aus den
Anwendungsprojekten ’Db2_95_Win’ oder ’Db2_95_Lnx’ überschrieben. Folglich
darf diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar
gemacht werden.
v queueManagerName: Der Name des zu erstellenden Warteschlangenmanagers.
Diese Variable muss auf der Lösungsebene mit der Variablen ’queueMgrName’
aus dem Anwendungsprojekt ’MqConfiguration’ verknüpft werden.
Projekte ’PlantsByWebSphereSolutionForLinuxWithInformix’,
’PlantsByWebSphereSolutionForLinuxWithDb2’, ’PlantsByWebSphereSolutionForWindowsWithInformix’ und
’PlantsByWebSphereSolutionForWindowsWithDb2’
Diese zwei Lösungsprojekte, die den Projekten ’SampleSolutionForLinuxWithInformix’ (Musterlösung für Linux mit Informix), ’SampleSolutionForLinuxWithDB2’
(Musterlösung für Linux mit DB2), ’SampleSolutionForWindowsWithInformix’
(Musterlösung für Windows mit Informix) und
’SampleSolutionForWindowsWithDB2’ (Musterlösung für Windows mit DB2) kombinieren die obigen Anwendungsprojekte mit den Middlewareanwendungsprojekten für die entsprechende Plattform zu vollständigen Lösungen. Da die zwei
Lösungen in ähnlicher Art und Weise erstellt werden, gilt die folgende Beschreibung für beide Lösungsprojekte.
Die Lösung besteht aus zwei Tasks. Die erste übergeordnete Task für die Installation der Lösungsmiddleware (Install Solution Middleware) umfasst die untergeordneten Tasks, die zur Installation des WebSphere Remote Server-Software-Stacks,
einschließlich IBM HTTP Server, WebSphere Application Server, DB2 und
WebSphere MQ, notwendig sind. Die zweite übergeordnete Task für die Installation und Konfiguration der Anwendung (Install and configure Application),
umfasst die Anwendungsprojekte ’Db2Configuration’, ’MqConfiguration’ und
’PlantsByWebSphereDeployment’ als untergeordnete Tasks. Alle Variablen für diese
drei Anwendungsprojekte werden auf der Lösungsebene überschrieben. Die folgende Tabelle enthält die Variablen und eine Erläuterung dazu, wie sie überschrieben werden.
Tabelle 4. Anwendungsvariablen, die auf Lösungsebene überschrieben werden
Anwendungsprojekt
Variablenname
Beschreibung der Überschreibung
Db2Configuration
databaseName
Wird als databaseName gemeinsam genutzt
MqConfiguration
queueMgrName
Wird als queueMgrName gemeinsam genutzt
MqConfiguration
isDefaultQueueMgr
Wird ausgeblendet und nimmt standardmäßig
den Wert ’true’ an
MqConfiguration
createDeadLetterQueue
MqConfiguration
createPubSubQueues
PlantsByWebSphereDeployment
WAS_HOME_AIX
Wird ausgeblendet
62
Tabelle 4. Anwendungsvariablen, die auf Lösungsebene überschrieben werden (Forts.)
Anwendungsprojekt
Variablenname
Beschreibung der Überschreibung
WAS_HOME_LINUX
Wird ausgeblendet
WAS_HOME_OS400
Wird ausgeblendet
WAS_HOME_WINDOWS
Wird ausgeblendet
databaseName
Wird als databaseName gemeinsam genutzt
queueManagerName
Wird als queueMgrName gemeinsam genutzt
USER
Wird ausgeblendet
PASSWORD
Wird ausgeblendet
dsalias_userId
Wird ausgeblendet
dsalias_password
Wird ausgeblendet
Musterlösung ’PlantsByWebSphere’ verwenden
Erstellen und testen Sie anhand dieser Anweisungen die Implementierung der
Musteranwendung ’PlantsByWebSphere’ für IBM WebSphere Remote Server.
Es wird davon ausgegangen, dass die Entwicklungsumgebung von WebSphere
Remote Server auf einer Entwicklungsworkstation installiert ist und dass außerdem
ein Testserver zur Verfügung steht, um die Implementierung zu testen (Testserver
und Entwicklungsworkstation können identisch sein). Führen Sie zum Erstellen
und Testen der Lösung die folgenden Schritte aus:
1. Klicken Sie in Express Runtime Developer abhängig von der Zielplattform, auf
der Sie die Implementierung testen wollen, mit der rechten Maustaste auf
PlantsByWebSphereSolutionForLinuxWithDb2 (PlantsByWebSphere-Lösung
für Linux mit DB2), PlantsByWebSphereSolutionForLinuxWithInformix
(PlantsByWebSphere-Lösung für Linux mit Informix), PlantsByWebSphereSolutionForWindowsWithDb2 (PlantsByWebSphere-Lösung für Windows mit DB2)
oder PlantsByWebSphereSolutionForWindowsWithInformix (PlantsByWebSphere-Lösung für Windows mit Informix).
2. Wählen Sie Generate solution im Popup-Menü aus.
3. Führen Sie die folgenden Schritte aus, wenn Sie die Implementierung auf der
Entwicklungsworkstation testen wollen.
a. Klicken Sie mit der rechten Maustaste erneut auf dasselbe Lösungsprojekt
und wählen Sie die Option Test in Deployment Wizard im Menü aus.
b. Sobald Deployment Wizard angezeigt wird, befolgen Sie den Eingabeaufforderungen, um die Implementierung zu testen.
4. Führen Sie alternativ hierzu die folgenden Schritte aus, wenn Sie die Implementierung auf einem separaten Server testen wollen:
a. Klicken Sie mit der rechten Maustaste auf dasselbe Lösungsprojekt und
wählen Sie Export im Menü aus.
b. Wenn das Dialogfenster Export angezeigt wird, wählen Sie die Optionen
Express Runtime → Express Runtime Solution Launcher Image in der Liste
der Exportziele aus und klicken Sie anschließend auf Next.
c. Geben Sie die Verzeichnisposition To an, an der das Image erstellt werden
soll, und klicken Sie auf Finish. Das Solution Launcher-Image kann auf den
Testserver kopiert oder auf eine DVD gebrannt werden. Deployment Wizard
wird mithilfe der Startprogrammdatei (je nach Plattform WindowsSetup.exe
oder LinuxSetup) aufgerufen. Sobald Deployment Wizard angezeigt wird,
befolgen Sie die Eingabeaufforderungen, um die Implementierung zu testen.
5. Zum Testen der Implementierung der Musterlösung verweisen Sie mit einem
Browser auf die folgende Adresse:
http://server:9080/PlantsByWebSphere/index.jsp.
63
Dabei ist server der Hostname des Servers, auf dem Sie die Lösung implementiert haben. Nun können Sie die Musteranwendung ’PlantsByWebSphere’ anzeigen.
Eigene Lösungen entwickeln
Damit Sie Ihre eigene Lösung mithilfe der in diesem Abschnitt beschriebenen Verfahren entwickeln können, müssen Sie diese Basisrichtlinien befolgen:
Schablonenprojekte kopieren und anpassen
Die Projekte ’Db2Configuration’ (DB2 - Konfiguration) und ’MqConfiguration’
(WebSphere MQ – Konfiguration) sollen als Schablonen verwendet werden: Kopieren Sie die vollständigen Projekte einfach mit einem neuen Namen und ersetzen
Sie die Scriptdateien durch Ihre eigenen. Kopieren Sie nur die Projekte, die in Ihrer
Lösung Anwendung finden. Wenn Ihre Lösung z. B. IBM WebSphere MQ nicht
benötigt, können Sie auf das Projekt ’MqConfiguration’ verzichten. Sie können
andererseits die Projekte so oft wie nötig kopieren, um die Voraussetzungen für
Ihre Lösung zu erfüllen. Wenn Ihre Lösung z. B. zwei oder mehr Datenbanken
benötigt, können Sie die Projekte ’Db2Configuration’ so oft wie nötig kopieren.
Das Projekt ’Db2Configuration’ anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt Db2Configuration in
Express Runtime Developer und wählen Sie im Popup-Menü die Option Copy
aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Teilfenster
Navigator und wählen Sie im Menü die Option Paste aus. Das Dialogfenster
Copy Project wird angezeigt. Geben Sie einen neuen Projektnamen an und klicken Sie auf OK. Das Projekt wird kopiert.
3. Erweitern Sie unter Verwendung des Fensters Navigator die Sicht unterhalb
Ihres neu kopierten Projekts und navigieren Sie abwärts zum Verzeichnis
src|userPrograms. Dort finden Sie zwei Scriptdateien: tables.ddl und populate.sql. Sie müssen diese Dateien durch Ihre eigenen Scripts ersetzen, dabei ist es
allerdings wichtig, dass die neuen Scripts dieselben Namen aufweisen. Obwohl
Sie diese Dateien manuell bearbeiten können, gibt es bessere Methoden, diese
Scripts zu generieren.
4. Der Inhalt der Datei tables.ddl kann von einer vorhandenen Datenbank mithilfe
des Befehls db2look generiert werden. Weitere Informationen finden Sie unter
der folgenden Adresse: http://publib.boulder.ibm.com/infocenter/db2luw/v9/
index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0002051.htm.
5. Die Scriptdatei populate.sql kann aus dem Projekt entfernt werden, wenn die
Tabellen nicht im Voraus gefüllt werden müssen, bevor die Anwendung ausgeführt werden kann. Einige Anwendungen füllen die Datenbank während der
Ausführung mithilfe serverseitigen Codes, wie z. B. mithilfe eines Servlets. In
diesem Fall wird die Datei populate.sql nicht benötigt. Andernfalls fügen Sie
die nötigen INSERT-Anweisungen hinzu, um die Tabellen nach Bedarf zu füllen.
Das Projekt ’IdsConfiguration’ anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt IdsConfiguration in
Express Runtime Developer und wählen Sie im Popup-Menü die Option Copy
aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Fenster
64
Ihres neu kopierten Projekts und navigieren Sie zum Verzeichnis
src|userPrograms, in dem zwei Scriptdateien angezeigt werden: tables.sql und
populate.sql. Ersetzen Sie diese Dateien durch Ihre eigenen Scripts, behalten Sie
jedoch dieselben Scriptnamen bei. Obwohl Sie diese Dateien manuell bearbeiten
können, gibt es bessere Methoden, diese Scripts zu generieren.
4. Die Scriptdatei populate.sql kann aus dem Projekt entfernt werden, wenn die
Tabellen nicht im Voraus gefüllt werden müssen, bevor die Anwendung ausgeführt werden kann. Einige Anwendungen füllen die Datenbank während der
Ausführung mithilfe serverseitigen Codes, wie z. B. mithilfe eines Servlets. In
diesem Fall wird die Datei populate.sql nicht benötigt. Andernfalls fügen Sie
die nötigen INSERT-Anweisungen hinzu, um die Tabellen nach Bedarf zu füllen.
Das Projekt ’MqConfiguration’ anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt MqConfiguration in
Express Runtime Developer und wählen Sie Copy im Menü aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Teilfenster
Ihres neu kopierten Projekts und navigieren Sie abwärts zum Verzeichnis
src|userPrograms. Suchen Sie die Scriptdatei mit dem Namen default.mqsc.
Ersetzen Sie diese Dateien durch Ihre eigenen Scripts, behalten Sie jedoch dieselben Scriptnamen bei. Obwohl Sie diese Datei manuell bearbeiten können,
gibt es bessere Methoden, dieses Script zu generieren.
4. Der Inhalt der Datei default.mqsc kann manuell mit den MQSC-Befehlen
codiert werden, die für das Erstellen der nötigen Warteschlangen, Kanäle und
weiterer Objekte für Ihre Lösung benötigt werden. Es kann jedoch ein Satz von
MQSC-Befehlen automatisch von einer vorhandenen WebSphere MQ-Installation mithilfe von ’saveqmgr’ (SupportPac) generiert werden. Weitere Informationen finden Sie unter der folgenden Adresse: http://www.ibm.com/support/
docview.wss?uid=swg24000673.
5. Das in WebSphere MQ enthaltene JMS-Publish/Subscribe-Beispielscript wird
standardmäßig als Teil dieses Anwendungsprojekts ausgeführt. Wenn Sie stattdessen Ihr eigenes Script ausführen wollen, können Sie es dem Projekt unter
dem Namen pubsub.mqsc hinzufügen. Diese Datei ist im Projekt nicht
standardmäßig enthalten.
Projekt ’WebSphere Application Deployment’ erstellen und erweitern
Der Assistent für das Projekt ’WebSphere Application Deployment’ ist die einfachste Methode für das Erstellen eines Anwendungsprojekts zur Implementierung
und Konfiguration Ihrer WebSphere-Anwendung. Damit Sie diesen Assistenten
verwenden können, muss Ihre Anwendung bereits auf einem Server implementiert
und konfiguriert sein, auf den über ein Netz von der Entwicklungsworkstation aus
zugegriffen werden kann, auf der Express Runtime Developer verwendet wird.
Zuerst muss das Projekt generiert werden. Anschließend wird das Projekt für die
Verwendung mit IBM WebSphere Remote Server erweitert.
65
Projekt ’WebSphere Application Deployment’ erstellen
Vollständige Anweisungen für die Verwendung des Assistenten für das Projekt
’WebSphere Application Deployment’ finden Sie unter der folgenden Adresse:
http://publib.boulder.ibm.com/infocenter/eruinf/v2r2/index.jsp?topic=/
com.ibm.iru.doc/concepts/cerwebap.htm. Die folgenden Schritte bieten eine Übersicht über die grundlegenden Voraussetzungen, die zur vollständigen Ausführung
des Assistenten nötig sind. Es wird vorausgesetzt, dass eine J2EE-Anwendung in
diesem Projekt verwendet wird. Einige der unten beschriebenen Anzeigen können
von den Anzeigen abweichen, die Sie am Bildschirm sehen, da sie von dem Typ
der Anwendung und den Spezifikationen ihrer Konfiguration abhängen.
1. Wählen Sie in Express Runtime Developer die Optionen File → New →
WebSphere Application Deployment Project aus. Der Assistent für das Projekt ’WebSphere Application Deployment’ wird angezeigt.
2. Geben Sie einen Projektnamen an und klicken Sie auf Next.
3. Wählen Sie in der Anzeige Locate Source Profile das Optionsfeld Remote
directory aus und klicken Sie auf Browse. Wenn das Dialogfenster Connect
angezeigt wird, geben Sie den Host, den Benutzernamen und das Kennwort
an, die für das Herstellen einer Verbindung zu dem Server benötigt werden,
auf dem die Anwendung derzeit installiert ist. Klicken Sie auf Connect. Ein
Dialogfenster für einen Dateibrowser wird angezeigt. Navigieren Sie zum Verzeichnis ’config’ des WebSphere Application Server-Profils, das die Anwendung ausführt, und klicken Sie auf OK. Die Konfigurationsdaten für das Profil werden anschließend analysiert. Nach Abschluss dieses Vorgangs können
Sie auf Next klicken.
4. Wählen Sie die Anwendungen in der Liste aus, die Sie in dieses Projekt aufnehmen wollen. Klicken Sie auf Next.
5. Klicken Sie in der Anzeige Review Configuration Summary auf Next.
6. Wählen Sie in der Anzeige General Options Ihre Optionen aus und klicken
Sie anschließend auf Next.
7. In der nächsten Anzeige werden Sie zur Angabe der Sicherheitsrollenbenutzernamen für die Anwendung aufgefordert. Geben Sie die entsprechenden Werte ein und klicken Sie auf Next.
8. In der nächsten Anzeige werden Sie zur Angabe der Position der JAR-Dateien
aufgefordert, die für “DB2 Universal JDBC Driver Provider (XA)” erforderlich
sind. Suchen Sie mit der Schaltfläche Add die Position der entsprechenden
JAR-Dateien und klicken Sie auf Next.
Anmerkung: Diese Anzeige steht Ihnen, je nachdem wie die JDBC-Provider
für Ihre Anwendung konfiguriert wurden, unter Umständen
nicht zur Verfügung.
9. In den übrigen Anzeigen werden Sie zur Angabe von Daten aufgefordert, die
für verschiedene für Ihre Anwendung konfigurierten Ressourcen spezifisch
sind. In der Regel werden die Standardwerte bereitgestellt, die aktuell für Ihre
Anwendung konfiguriert sind. Wenn Sie mindestens eine dieser Variablen
zugänglich machen wollen, sodass sie während der Installation angegeben
werden kann, wählen Sie das Markierungsfeld Enable modifying this value
during deployment neben der in Frage kommenden Variablen aus. Die meisten Variablen übernehmen die Standardwerte. Zu den Variablen, die Sie modifizieren wollen, könnten der Datenbankname und der Name des Warteschlangenmanagers gehören.
10. Wenn Sie die letzte Anzeige erreicht haben, klicken Sie auf Finish. Das Projekt
wird automatisch für Sie generiert.
66
Projekt ’WebSphere Application Deployment’ erweitern
Das Projekt ’WebSphere Application Deployment’, das Sie soeben erstellt haben,
kann direkt in einem WebSphere Remote Server-Lösungsprojekt verwendet werden, vor allem wenn Sie vorhaben, Ihre Lösung gleichzeitig zu installieren und zu
konfigurieren. Wenn Sie aber das zwei Phasen umfassende Data-Warehouse-Modell
der Installation und Konfiguration anwenden wollen, müssen Sie an diesem Projekt einige wichtige Änderungen vornehmen. Diese Änderungen müssen Sie auch
vornehmen, wenn Ihre Lösung die Anwendung in vorhandenen WebSphere
Remote Server-Instanzen implementieren soll und die Middleware nicht in der
Lösung enthalten ist.
1. Navigieren Sie im Teilfenster Navigator von Express Runtime Developer
zum folgenden Unterverzeichnis: PlantsByWebSphereDeployment/src/
PlantsByWebSphereDeployment/userPrograms. Suchen Sie an dieser Position
die Datei WrsDeployWebApplications.java und kopieren Sie diese in das entsprechende Unterverzeichnis userPrograms des Arbeitsbereichs Ihres neuen
Projekts.
2. Öffnen Sie in Express Runtime Developer die Datei application.axml für das
neue Projekt. Wählen Sie über die Registerkarte Programs die Registerkarte
Main Program aus. Ändern Sie den Wert von ’Program’ in WrsDeployWebApplications. Entfernen Sie aus dem Listenfenster Arguments alle Argumente,
indem Sie jedes Argument der Reihe nach auswählen und auf Remove klicken.
3. Speichern Sie die Änderungen in der Datei application.axml.
4. Die Klasse ’WrsDeployWebApplications’ schließt die Standardklasse ’DeployWebApplications’ mit ein und ermöglicht, dass bestimmte Variablenwerte mit
den aus der WebSphere Remote Server-Metadatendatei abgerufenen Werten
überschrieben werden. (Hierbei handelt es sich um Variablenwerte und andere
Systemmetadaten, die während der Erstinstallation von WebSphere Remote Server erstellt wurden.)
Anmerkung: Diese Klasse muss die wichtigsten Variablen handhaben und darf
in den meisten Fällen keine Änderungen anfordern. Es ist jedoch
wichtig, dass Sie den Code überprüfen, damit Sie die Vorgänge
verstehen, sodass Sie bei Bedarf am Code Änderungen vornehmen können.
Lösung erstellen
Im Lösungsprojekt werden alle Anwendungsprojekte zu einer einzelnen Lösung
vereinigt. Eine vollständige WebSphere Remote Server-Lösung enthält alle Middlewareanwendungsprojekte. Die folgende Tabelle enthält die verschiedenen
Anwendungsprojekte, die für jede Plattform aufgenommen werden können.
Obwohl Sie die Anwendungsprojekte in dieser Liste aus Ihrer Lösung entfernen
können, ist die Reihenfolge wichtig, in der sie aufgeführt sind.
Tabelle 5. WebSphere Remote Server-Anwendungsprojekte
Linux-Projektname
Windows-Projektname
Kommentare
IrssBase_70_Lnx
IrssBase_70_Win
WebSphere Remote ServerBasiscode Erforderlich.
Db2_953a_Lnx
Db2_953a_Win
DB2 Workgroup Server Edition
Ids_1150_Lnx
Ids_1150_Win
Informix Dynamic Server
Mq_7001_Lnx
Mq_7001_Win
WebSphere MQ
67
Tabelle 5. WebSphere Remote Server-Anwendungsprojekte (Forts.)
Linux-Projektname
Windows-Projektname
Kommentare
Was_7003_Lnx
Was_7003_Win
WebSphere Application Server Network Deployment
WasStandaloneProfileConfiguration
WasStandaloneProfileConfiguration
WebSphere Application Server-Profil
Ihs_70_Lnx
Ihs_70_Win
IBM HTTP Server
Smash_1101_Lnx
Smash_1101_Win
WebSphere sMash
’ConfigWrapperWithDb2’
’ConfigWrapperWithDb2’
WebSphere Remote Serveroder
oder
Anwendungskonfigurations’ConfigWrapperWithInformix’ ’ConfigWrapperWithInformix’ programm. Dieses Programm
ist optional.
Alle Middlewareanwendungsprojekte sind vom technischen Standpunkt aus
betrachtet optional. In der Praxis werden jedoch WebSphere Remote Server und
DB2 wahrscheinlich benötigt, IBM WebSphere MQ und IBM HTTP Server dagegen
möglicherweise nicht. Dies ist von den Voraussetzungen für Ihre Anwendung
abhängig.
Zusätzlich zu den oben aufgeführten Projekten müssen Sie das Projekt
’Db2Configuration’ bzw. Ihre Kopie davon, das Projekt ’MqConfiguration’ bzw.
Ihre Kopie davon und das Projekt ’WebSphere Application Deployment’, das Sie
im Abschnitt „Projekt ’WebSphere Application Deployment’ erstellen und
erweitern” auf Seite 65 erstellt haben, hinzufügen.
Die folgenden Anweisungen zeigen die Schritte auf, die nötig sind, um ein
Lösungsprojekt zu erstellen, das den Projekten ’PlantsByWebSphereForLinux’ oder
’PlantsByWebSphereForWindows’ ähnelt, aber Ihre eigenen Anwendungsprojekte
enthält.
1. Wählen Sie über das Menü File die Optionen New → Solution project aus.
Der Projektassistent New wird angezeigt.
2. Geben Sie in der ersten Anzeige den Projektnamen an. Wählen Sie einen aussagekräftigen Namen aus. Wenn Sie für beide von WebSphere Remote Server
unterstützten Betriebssystemplattformen (Linux und Windows) Lösungen entwickeln möchten, empfiehlt es sich, den Namen der Plattform im Projektnamen anzugeben. Klicken Sie auf Next.
3. Geben Sie in der nächsten Anzeige die Lösungs-ID und den Lösungstitel entsprechend an. Klicken Sie auf Finish. Das Lösungsprojekt wird erstellt. Sie
müssen zuerst Tasks erstellen, damit Sie einem Lösungsprojekt Anwendungsprojekte hinzufügen können. Für dieses Beispiel können Sie zwei Tasks erstellen: eine Task zum Installieren sämtlicher Middleware von WebSphere Remote
Server und eine weitere Task zum Implementieren und Konfigurieren Ihrer
Anwendung.
4. Wechseln Sie zur Registerkarte Tasks. Klicken Sie neben dem Listenfenster
Solution Tasks auf Add. Wenn der Taskassistent Add angezeigt wird, wählen
Sie das Optionsfeld Create an empty install task aus und klicken Sie auf
Next.
5. Geben Sie einen Wert in das Feld Task Description ein und klicken Sie auf
Finish.
6. Klicken Sie auf Add, um dieser Task Anwendungsprojekte hinzuzufügen.
Wenn der Assistent Add angezeigt wird, behalten Sie die Auswahl des
Optionsfelds Add applications bei und klicken Sie auf Next.
68
7. Wählen Sie im Listenfenster Applications alle Anwendungsprojekte für die
Middlewarekomponenten aus. Die obige Tabelle führt die Projekte auf, die Sie
jeweils für Ihre Plattform auswählen können. Wenn Sie die entsprechenden
Projekte ausgewählt haben, klicken Sie auf Finish.
8. Ändern Sie die Reihenfolge der Anwendungen, sodass sie mit der Reihenfolge
der Projekte übereinstimmt, die in der oben stehenden Tabelle 5 auf Seite 67
aufgeführt sind. Wählen Sie eine Anwendung in der Liste aus und verwenden
Sie die Schaltflächen Up und Down zum Ändern der Reihenfolge. Wiederholen Sie diesen Prozess, bis die Reihenfolge korrekt ist.
9. Erstellen Sie eine zweite Task für das Implementieren und Konfigurieren Ihrer
Anwendung, indem Sie die Schritte 4 und 5 wiederholen.
10. Klicken Sie auf Add, um dieser zweiten Task Anwendungsprojekte hinzuzufügen. Wenn der Assistent Add angezeigt wird, behalten Sie die Auswahl des
Optionsfelds Add applications bei und klicken Sie auf Next.
11. Wählen Sie im Listenfenster Applications nur die Anwendungsprojekte aus,
die Sie in den obigen Abschnitten erstellt haben. Wenn Sie die entsprechenden
Projekte ausgewählt haben, klicken Sie auf Finish.
12. Ändern Sie die Reihenfolge der Anwendungen, sodass das Projekt ’WebSphere
Application Deployment’ am Ende der Liste aufgeführt wird. Sie ändern die
Reihenfolge der Anwendungen auf dieselbe Weise, wie sie in Schritt 8
beschrieben wird.
13. Überschreiben Sie die Variablen. Verwenden Sie die oben aufgeführte Tabelle 5
auf Seite 67 als Referenz beim Überschreiben der Anwendungsvariablen. Die
meisten Variablen sollten ausgeblendet sein. Einige Variablen sollten gemeinsam genutzt werden. Wählen Sie zum Überschreiben einer Anwendungsvariablen eine Anwendung im Listenfenster Solution Tasks aus und klicken
Sie anschließend auf Add rechts neben dem Listenfenster Overridden application variables. Ein Assistent wird angezeigt. Wählen Sie die Variablen in der
Liste aus. Beim Durcharbeiten der übrigen Seiten des Assistenten können Sie
angeben, wie jede Variable überschrieben werden soll (ob sie ausgeblendet,
gemeinsam genutzt usw. werden soll).
14. Erstellen und testen Sie die Lösung mithilfe der Schritte, die im Abschnitt
„Musterlösung ’PlantsByWebSphere’ verwenden” auf Seite 63 beschrieben
werden.
WrsApplicationConfigurator verwenden
In den obigen Anweisungen wird beschrieben, wie Ihre WebSphere-Anwendung
als separate Task in einem einzelnen Lösungsprojekt implementiert und konfiguriert werden kann. Beide Tasks können gleichzeitig von Deployment Wizard oder
während separater Aufrufe von Deployment Wizard ausgeführt werden vorausgesetzt, dass das Solution Launcher-Image noch auf der Zielmaschine verfügbar ist.
Durch diese Art des Entwurfs kann dieses Lösungsprojekt auch im zwei Phasen
umfassenden Data-Warehouse-Modell für Installation und Konfiguration verwendet werden, wie in der Veröffentlichung zur Implementierung von WebSphere
Remote Server (Deploying WebSphere Remote Server) beschrieben wird, die Ihnen
unter der folgenden Adresse zur Verfügung steht: http://www.ibm.com/support/
docview.wss?rs=2193&context=SSUNCX&dc=DA480&uid=swg27012849
&loc=en_US&cs=utf-8&lang=en.
In dieser Veröffentlichung wurde die Konfigurationsphase allerdings als separates
sekundäres Lösungsprojekt mit dem Namen ’WrsApplicationConfigurator’
(WebSphere Remote Server – Anwendungskonfigurationsprogramm) entworfen,
das anschließend in das Anwendungsprojekt ’ConfigWrapper’ (Wrapper für
69
Anwendungskonfigurationsprogramm) eingeschlossen wird, das dann wiederum
in das primäre Lösungsprojekt aufgenommen wird. Das Anwendungsprojekt ’ConfigWrapper’ verwendet die Ausgabe des Solution Launcher-Images aus der Lösung
’WrsApplicationConfigurator’ als Eingabe zum Erstellen des Implementierungspakets.
Die in dieser Veröffentlichung beschriebenen Methoden können auch mit dem
Muster ’WrsApplicationConfigurator/ConfigWrapper’ verwendet werden. Die
unten aufgeführten Anweisungen bieten einen kurzen Überblick über die wichtigen Unterschiede:
1. Fügen Sie die Anwendungsprojekte, die Sie in den Abschnitten „Schablonenprojekte kopieren und anpassen” auf Seite 64 und „Projekt ’WebSphere Application Deployment’ erstellen und erweitern” auf Seite 65 erstellt haben, zu dem
Lösungsprojekt ’WrsApplicationConfigurator’ hinzu.
2. Generieren Sie die Lösung und exportieren Sie das Solution Launcher-Image
für ’WrsApplicationConfigurator’.
3. Generieren Sie das Implementierungspaket für das Anwendungsprojekt ’ConfigWrapper’. Stellen Sie dabei sicher, dass das Quellenverzeichnis auf das Verzeichnis verweist, wohin im vorherigen Schritt das Solution Launcher-Image
exportiert wurde.
4. Nehmen Sie das Anwendungsprojekt ’ConfigWrapper’ in Ihr WebSphere
Remote Server-Lösungsprojekt auf.
Anwendung erstellen
Bei dieser Methode wird davon ausgegangen, dass Sie nicht über eine WebSphereAnwendung verfügen, für die ein WebSphere-Anwendungsimplementierungsprojekt als Wrapper verwendet werden kann. In diesem Fall wird angenommen, dass
Sie ein Anwendungsprojekt neu erstellen. Die Erstellung eines Anwendungsprojekts umfasst die Definition von Variablen, die Zuordnung von Variablen zu
Eigenschaften in einer Antwortdatei und das Schreiben von Code, der zum Aufrufen des Installationsprogramms für Ihre Anwendung erforderlich ist.
IBM Solution Assembly Toolkit stellt eine vollständige API bereit, die Sie bei der
Entwicklung von Java-Code unterstützt, der zur Verwaltung der Installation benötigt wird. Der IBM WebSphere Remote Server-Arbeitsbereich erweitert diese API
zusätzlich mit Harness-Klassen, die den Arbeitsablauf vor und nach der Installation optimieren, sowie mit einer Reihe von Dienstprogrammklassen, die eine Vielzahl nützlicher Funktionen bereitstellen.
Harness-API
Die folgenden Klassen erweitern die SupportBase-Klassen der Solution Assembly
Toolkit-API:
v com.ibm.wrs.solution.utils.SoftwareWindowsHarness
v com.ibm.wrs.solution.utils.SoftwareLinuxHarness
v com.ibm.wrs.solution.utils.SoftwareConfigHarness
Die Software-Harness-Klasse teilt den Installationsprozess in drei einfache Schritte
auf: preInstall, doInstall und postInstall. Die Methoden preInstall und postInstall
müssen außer Kraft gesetzt werden, damit die benötigte Funktion zur Verfügung
steht, bieten jedoch ein angemessenes Standardverhalten, falls keine speziellen
Tasks erforderlich sind. Die Methode doInstall führt den Installationsbefehl für Ihre
Anwendung aus. Die zeitaufwendigen Aufgaben des Interpretierens von Rückkehr-
70
codes und der Nachrichtenübertragung werden durch die Basisklasse in der
Installationsmethode durchgeführt. Normalerweise muss diese Methode nicht
außer Kraft gesetzt werden.
Die Klasse SoftwareConfigHarness stellt einen ähnlichen, aus drei Schritten bestehenden Prozess zur Verfügung: die Methoden preConfigure, doConfigure und
postConfigure. Wie bei der Software-Harness-Klasse müssen Sie lediglich den Code
für diese drei Schritte schreiben. Die Basisklasse übernimmt die Bearbeitung der
Rückkehrcodes etc.
Es ist nicht unbedingt erforderlich, diese Klassen zu verwenden. Sie können eine
Erweiterung auf der Basis der von SAT bereitgestellten Klassen SupportWindowsBase und SupportLinuxBase vornehmen. Durch die Harness-Klasse wird die Entwicklung jedoch vereinfacht.
Darüber hinaus bieten die Harness-Klassen eine weitere wichtige Funktion: die im
Folgenden beschriebene Aktualisierung der WebSphere Remote Server-Metadatendatei.
WebSphere Remote Server-Metadatendatei
Die WebSphere Remote Server-Metadatendatei ist ein Repository für Systemkonfigurationsdaten. Genauer ausgedrückt handelt es sich um eine XML-Datei, die
unter SIF_HOME/solution/WRSMetadata.xml gespeichert ist. In der Metadatendatei werden Konfigurationsdaten zu den einzelnen Middlewarekomponenten
gespeichert, wie beispielsweise die Installationsposition, Installationsparameterwerte sowie Methoden zum Starten, Stoppen und Überwachen der Komponente.
Diese Daten werden zum Starten und Stoppen des gesamten Software-Stacks verwendet. .
Die Metadaten bestehen aus fünf zentralen XML-Elementen. Das Lösungselement
stellt die gesamte Lösung auf dem System dar. Standardmäßig ist ihm das
Namensattribut ’WRS’ zugeordnet. Die Anwendungselemente stellen einzelne
Softwarekomponenten dar und weisen die entsprechenden Benennungen auf:
’WAS’, ’DB2’ etc. Diese Elemente sind stets untergeordnete Elemente eines
Lösungselements. Die Unterkomponentenelemente stellen eine zentrale Entität
innerhalb einer Softwarekomponente dar, z. B. ein IBM WebSphere Application Server-Profil. Diese Elemente sind stets untergeordnete Elemente von Anwendungselementen. Die Berechtigungsnachweiselemente stellen Benutzernamen und Kennwörter innerhalb des Systems dar. Diese Elemente werden für das System als
global betrachtet und befinden sich auf derselben Ebene wie das Lösungselement.
Alle anderen Elemente in den Metadaten (mit Ausnahme des Stammelements) stellen Eigenschaften des übergeordnetes Elements dar.
Die meisten der in der WebSphere Remote Server-Metadatendatei enthaltenen
Daten stammen direkt von den im Anwendungsprojekt definierten Variablen.
Einige Informationen, wie zum Beispiel die Start-/Stoppbefehle oder die Deinstallationsbefehle, dürfen jedoch nicht bei den Benutzern der Anwendung abgefragt
werden. Diese zusätzlichen Informationen müssen über eine für diesen Zweck
erstellte API in die Metadaten aufgenommen werden; es gibt jedoch eine einfachere
Methode, für die keine Codeentwicklung erforderlich ist.
Die oben beschriebenen Software-Harness-Klassen stellen eine weitere wichtige
Funktion bereit - nach der erfolgreichen Installation wird ein XML-Snippet in die
WebSphere Remote Server-Metadatendatei aufgenommen. Das XML-Snippet ist
eine Datei mit dem Namen metadata.xml, die sich im Anwendungsprojekt befinKapitel 5. Erweiterung
71
det. Die Datei metadata.xml entspricht in ihrer Form einer Untermenge der gesamten Metadatendatei mit denselben, oben beschriebenen Elementen. Wenn Sie eine
Datei metadata.xml in Ihr Projekt aufnehmen und Ihre Hauptklassen auf der Basis
von einer der Software-Harness-Klassen erweitern, wird die Metadatensnippetdatei
zum Zeitpunkt der Installation in die WebSphere Remote Server-Metadatendatei
aufgenommen.
Beispiele für die Datei metadata.xml finden Sie in den Anwendungsprojekten im
Arbeitsbereich.
WebSphere Remote Server speichert codierte Kennwörter für einige der IBM Middlewareprodukte in der Datei SIF_HOME/solution/WRSMetadata.xml. Die Codierung und Verschlüsselung von Kennwörtern verhindert die zufällige Beobachtung
von Kennwörtern; die Codierung ist jedoch nicht ausreichend, um Kennwörter
vollständig zu schützen. Die systemeigene Sicherheit ist der primäre Mechanismus
zum Schützen der in WebSphere Application Server-Konfigurations- und
Eigenschaftendateien verwendeten Kennwörter. Die folgenden Links bieten Unterstützung bei der Festlegung von Dateiberechtigungen für das jeweilige Betriebssystem:
v Windows 2008 Server: http://msdn.microsoft.com/en-us/magazine/
cc982153.aspx
v Windows 2003 Server: http://support.microsoft.com/kb/325361
v Windows XP: http://support.microsoft.com/default.aspx/kb/308419
v SUSE Linux Enterprise Server: http://www.novell.com/documentation/sled10/
sled_deployment_sp2/index.html?page=/documentation/sled10/
sled_deployment_sp2/data/sect1_chapter_sled_deployment_sp2.html
v Red Hat Enterprise Linux: http://www.redhat.com/docs/manuals/linux/RHL9-Manual/getting-started-guide/s1-navigating-ownership.html
WebSphere Remote Server- und ISP-Anwendungen steuern
Das IBM WebSphere Remote Server-Befehlsprozessordienstprogramm ist eine
Klassendatei, die in der Datei SifUtility.jar enthalten ist. Diese Datei befindet sich
im Verzeichnis SIF_HOME/utility.
Der WebSphere Remote Server-Befehlsprozessor führt Befehle auf Betriebssystemebene aus, die in der WebSphere Remote Server-Metadatendatei definiert sind. Die
Befehle werden durch die Übergabe von Parametern an den WebSphere Remote
Server-Befehlsprozessor aufgerufen. Diese Parameter ermöglichen dem Prozessor,
die Befehle in der WebSphere Remote Server-Metadatendatei zu finden und den
entsprechenden Befehl auszuführen.
WebSphere Remote Server enthält vorgefertigte Scripts für das Steuern der Anwendungen, aus denen sich die WebSphere Remote Server-Lösung zusammensetzt.
72
Die Syntax für diese Scripts wird nachfolgend aufgeführt:
v silent: Informationen zur Befehlsausführung werden nicht in der Anzeige ausgegeben.
v log: Informationen zur Befehlsausführung werden in der Protokolldatei ausgegeben.
v verbose: Ausführliche Informationen zur Debugbefehlsausführung werden im
Die zuvor genannten Scripts können nur für die WebSphere Remote Server-Lösung
sowie für alle Anwendungen und Unterkomponenten ausgeführt werden, die in
der WebSphere Remote Server-Lösung enthalten sind. Sie können jedoch die
Standardsteuerparameter für Anwendungen und Unterkomponenten ändern, die
sich in der WebSphere Remote Server-Metadatendatei befinden, oder Sie können
neue, in WebSphere Remote Server nicht enthaltene Lösungen, Anwendungen und
Unterkomponenten hinzufügen. Für diesen Fall ist der WebSphere Remote ServerBefehlsprozessor so erweiterbar, dass diese Änderungen und zukünftigen Anwendungen gesteuert werden können. In dem folgenden Abschnitt wird gezeigt, wie
der WebSphere Remote Server-Befehlsprozessor für diese Szenarios verwendet werden kann.
Neue Anwendungen oder Unterkomponenten ändern bzw. diese
zur WebSphere Remote Server-Lösung hinzufügen
Die einfachste Methode, neue Anwendungen oder Unterkomponenten zu ändern
bzw. diese zur WebSphere Remote Server-Lösung hinzuzufügen, ist, mit den in der
WebSphere Remote Server-Lösung vorhandenen Scripts eine Ausgangsbasis zu
erstellen.
Beispiel: Hinzufügen einer neuen Anwendung zur WebSphere Remote ServerLösung
Diese Anwendung verfügt über Start- und Stoppfunktionen.
1. Fügen Sie die Anwendungsinformationen zur Metadatendatei in der
WebSphere Remote Server-Lösung hinzu. In diesem Beispiel wird die Anwendung TestApplication mit Start- und Stoppinformationen hinzugefügt:
<solution name="WRS">
<application name="TestApplication">
<start>wrs_TestApplication_start.bat </start>
<stop>wrs_TestApplication_stop.bat </stop>
</application>
<solution>
2. Handelt es sich bei den gewünschten Befehlen um Scriptaufrufe, erstellen Sie
die nötigen Scripts. In diesem Beispiel sind die Befehle Aufrufe für die Scripts
wrs_TestApplication_start.bat und wrs_TestApplication_stop.bat. Die Datei
wrs_DB2_start.bat (diese Datei wird bei der Installation von DB2 installiert)
wird als Schablone verwendet; die hieraus resultierende Datei wrs_TestApplication_start.bat ist unten dargestellt:
@echo off
set SUCCESS=0
set FAILURE=1
set UNKNOWN=2
@CALL "%SIF_HOME%\bin\SifSetupCmdLine.bat"
set BINDIR"%SIF_HOME%\bin
73
set TEMPLOG="%SIF_HOME%\logs\%~nx0.log"
set rc=%UNKNOWN%
@call "%BINDIR%\TestApplication.exe start" > %TEMPLOG% 2>&1
if "%ERRORLEVEL%" EQU "1" (
@REM Couldn't start, but may already be started
goto checkifstarted
)
@REM Command succeeded
set rc=%SUCCESS%
goto end
)
:checkifstarted
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "Already started"
set rc=%SUCCESS%
goto end
)
set rc=%FAILURE%
goto end
)
:end
type %TEMPLOG%
del /s /q %TEMPLOG%
exit /b %rc%
Dieses Beispielscript stellt die folgende Verarbeitung dar:
v Initialisieren benötigter lokaler Variablen.
v Aufrufen der Datei SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das
Script ’SifSetupCmdLine’ muss immer aufgerufen werden, sodass die im
Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der
Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
v Aufrufen des Befehls für die Anwendung. In diesem Beispiel lautet der
Befehl: TestApplication.exe start
v Bewerten der Ausgabe des Befehlsaufrufs. In diesem Beispiel ist der
Rückkehrcode auf %SUCCESS% gesetzt, falls TestApplication ordnungsgemäß gestartet wurde. Wenn allerdings in diesem Beispiel das Starten von
TestApplication nicht die Rückgabe 0 ergibt, kann die Anwendung bereits
aktiv sein und der hieraus resultierende Text, der in der Anzeige angezeigt
wird, enthält die Wörter Already started (Bereits gestartet). Der Inhalt des
Ausgabefensters wird in die benannte Protokolldatei geschrieben, die sich in
%TEMPLOG% befindet. Diese Datei kann wie oben gezeigt mithilfe von
com.ibm.sif.utility.FindString nach dem Text Already started durchsucht
werden. Wird der gesuchte Text gefunden, wird der Rückkehrcode der
Anwendung auf %SUCCESS% gesetzt, andernfalls wird der Rückkehrcode
auf %FAILURE% gesetzt.
v Anzeigen der Ausgabe des Befehlsaufrufs.
v Löschen der temporären Datei, in der die Befehlsausgabe enthalten ist.
v Zurückgeben des Rückkehrcodes des Befehlsaufrufs.
3. Rufen Sie den WebSphere Remote Server-Befehlsprozessor auf, um die Anwendung ’TestApplication’ zu starten; verwenden Sie hierzu bei Bedarf optionale
Parameter: wrsstart TestApplication [-silent -log -verbose]
74
Neue Anwendungen oder Unterkomponenten zu anderen Lösungen außer der WebSphere Remote Server-Lösung hinzufügen
Die einfachste Methode, neue Anwendungen oder Unterkomponenten zu anderen
Lösungen außer der WebSphere Remote Server-Lösung hinzuzufügen, ist, mit den
in der WebSphere Remote Server-Lösung vorhandenen Scripts eine Ausgangsbasis zu erstellen.
Beispiel: Hinzufügen einer neuen Anwendung zu einer neuen Lösung
Diese Anwendung verfügt über Start- und Stoppfunktionen.
1. Fügen Sie die Lösung zur WebSphere Remote Server-Metadatendatei hinzu. Die
neuen Lösungstags werden auf derselben Ebene hinzugefügt wie die Lösung
WRS. In diesem Beispiel wird die Lösung NewSolution hinzugefügt.
.... Tags für die WRS-Lösung sind hier
</solution>
<solution name="NewSolution">
</solution>
2. Fügen Sie die Anwendungsinformationen zur WebSphere Remote Server-Metadatendatei unter der Lösung ’NewSolution’ hinzu. In diesem Beispiel wird die
Anwendung NewApplication mit Start- und Stoppinformationen hinzugefügt:
.... Tags für die WRS-Lösung sind hier
</solution>
<solution name="NewSolution">
<application name="TestApplication">
<start>wrs_NewApplication_start.bat </start>
<stop>wrs_NewApplication_stop.bat </stop>
</application>
</solution>
3. Handelt es sich bei den gewünschten Befehlen um Scriptaufrufe, erstellen Sie
die nötigen Scripts. In diesem Beispiel sind die Befehle Aufrufe für die Scripts
wrs_NewApplication_start.bat und wrs_NewApplication_stop.bat. Die Datei
wrs_DB2_start.bat (diese Datei wurde bei der Installation von DB2 installiert)
wird als Schablone verwendet; die hieraus resultierende Datei wrs_NewApplication_start.bat ist unten dargestellt:
@echo off
set SUCCESS=0
set FAILURE=1
set UNKNOWN=2
@CALL "%SIF_HOME%\bin\SifSetupCmdLine.bat"
set BINDIR"%SIF_HOME%\bin
set TEMPLOG="%SIF_HOME%\logs\%~nx0.log"
set rc=%UNKNOWN%
@call "%BINDIR%\NewApplication.exe start"
> %TEMPLOG% 2>&1
@REM Couldn't start, but may already be started
goto checkifstarted
)
@REM Command succeeded
set rc=%SUCCESS%
goto end
)
:checkifstarted
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "Already started"
set rc=%SUCCESS%
goto end
)
set rc=%FAILURE%
goto end
)
75
:end
type %TEMPLOG%
del /s /q %TEMPLOG%
exit /b %rc%
v Initialisieren benötigter lokaler Variablen.
v Aufrufen der Datei SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das Script
’SifSetupCmdLine’ muss immer aufgerufen werden, sodass die im Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
v Aufrufen des Befehls für die Anwendung. In diesem Beispiel lautet der Befehl:
NewApplication.exe start
v Bewerten der Ausgabe des Befehlsaufrufs. In diesem Beispiel ist der Rückkehrcode auf %SUCCESS% gesetzt, falls NewApplication ordnungsgemäß gestartet
wurde. Wenn allerdings in diesem Beispiel das Starten von NewApplication
nicht die Rückgabe 0 ergibt, kann die Anwendung bereits aktiv sein und der
hieraus resultierende Text, der in der Anzeige angezeigt wird, enthält die Wörter
Already started (Bereits gestartet). Der Inhalt des Ausgabefensters wird in die
benannte Protokolldatei geschrieben, die sich in %TEMPLOG% befindet. Diese
Datei kann wie oben gezeigt mithilfe von com.ibm.sif.utility.FindString nach dem
Text Already started durchsucht werden. Wird der gesuchte Text gefunden,
wird der Rückkehrcode der Anwendung auf %SUCCESS% gesetzt, andernfalls
wird der Rückkehrcode auf %FAILURE% gesetzt.
v Anzeigen der Ausgabe des Befehlsaufrufs.
v Löschen der temporären Datei, in der die Befehlsausgabe enthalten ist.
v Zurückgeben des Rückkehrcodes des Befehlsaufrufs.
v Rufen Sie den WebSphere Remote Server-Befehlsprozessor auf, um die Anwendung ’TestApplication’ zu starten; verwenden Sie hierzu bei Bedarf optionale
Parameter:
Die einfachste Methode, den WebSphere Remote Server-Befehlsprozessor für eine
neue Lösung aufzurufen, ist, neue Scriptdateien mithilfe der Scriptdateien zu
erstellen, die für die WebSphere Remote Server-Lösung als Ausgangsbasis bereitgestellt werden. Das Script wrsstart.bat wird als Beispiel dafür verwendet, wie
das Startscript für eine neue Lösung erstellt wird:
@ECHO OFF
@REM setup environment to run the WRSCommandProcessor
CALL "%SIF_HOME%\bin\SifSetupCmdLine.bat"
@REM process the input parameters
IF (%1)==() (GOTO NewSolutionStack) ELSE (GOTO PARAMETERS)
@REM use WRSCommandProcessor to start NewSolution stack
:NewSolutionStack
%JAVACMD% -classpath %CP% com.ibm.wrs.solution.utils.WRSCommandProcessor.class start NewSolution
GOTO END
@REM use WRSCommandProcessor to start item specified by parameters
:PARAMETERS
%JAVACMD% -classpath %CP% com.ibm.wrs.solution.utils.WRSCommandProcessor.class start NewSolution %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO END
@REM exit the batch file
:END
GOTO:EOF
1. Aufrufen des Scripts SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das
Script ’SifSetupCmdLine’ muss immer aufgerufen werden, sodass die im
Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der
Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
2. Aufrufen des WebSphere Remote Server-Befehlsprozessors auf der Basis der
Eingabeparameter. Wenn keine Eingabeparameter vorhanden sind, gehen Sie
davon aus, dass der Stack ’NewSolution’ gestartet werden soll. Wenn Ein-
76
gabeparameter vorhanden sind, starten Sie die Anwendung/Unterkomponente, die sich auf der von den Eingabeparametern angegebenen Ebene
befindet.
Es sind zwei wichtige Punkte zu beachten, wenn Sie den WebSphere Remote
Server-Befehlsprozessor aufrufen:
– Der Name des Tags für den Befehlstyp, der in der WebSphere Remote Server-Metadatendatei vorhanden ist, muss als Parameter nach dem Parameter ’WRSCommandProcessor.class’ aufgeführt werden. In diesem Beispiel
hat der Tag den Namen start.
– Der Name der Lösung ist der nächste Parameter, der auf den Tag für den
Befehlstyp folgt. In diesem Beispiel hat die Lösung den Namen NewSolution.
77
78
Kapitel 6. Fehlerbehebung und Unterstützung
Dieser Abschnitt enthält Informationen zu Fehlerbehebungstools, Unterstützung
sowie Problemen mit der Installation.
IBM Support Assistant installieren und verwenden
IBM Support Assistant (ISA) ermöglicht es Ihnen, die Produktdokumentation zu
durchsuchen, Produktmanagementberichte (PMRs) zu erstellen und Protokolldateien zu paketieren.
ISA ist eine eigenständige Anwendung, die Sie auf jeder Workstation installieren
und anschließend erweitern können, indem Sie Plug-in-Module für die von Ihnen
verwendeten IBM Produkte installieren. Weitere Informationen zu ISA und den
bereitgestellten Funktionen finden Sie auf der ISA-Unterstützungsseite. WebSphere
Remote Server unterstützt Version 4.0.2 oder höher von ISA.
Sie finden eine Liste der für ISA unterstützten Plattformen unter folgender
Adresse: http://www.ibm.com/support/docview.wss?rs=3455&uid=swg27012685
Anmerkung: Wenn ISA nicht auf dem Unternehmensserver installiert wird, der
zum Verwalten der IBM WebSphere Remote Server-Filialrechner
(ISPs) verwendet wird, müssen die Protokollerfassungsscripts, die
von ISPs gesammelt werden, manuell auf die ISA-Maschine verschoben werden.
Die folgenden Schritte zeigen, wie ISA installiert und ausgeführt wird.
1. Installieren Sie ISA.
2. Verwenden Sie die integrierte ISA-Aktualisierungskomponente, um das
WebSphere Remote Server-Plug-in zu installieren. Alternativ können Sie das
WebSphere Remote Server-Plug-in und alle zusätzlichen Produkt-Plug-ins aus
der Liste der unterstützten ISA-Plug-ins herunterladen und installieren.
a. Öffnen Sie ISA und navigieren Sie zu Update → Find new ... → Product Addons.
b. Erweitern Sie den WebSphere-Produktordner und wählen Sie WebSphere
Remote Server V7.0 aus.
c. Klicken Sie auf Next.
d. Klicken Sie erneut auf Next.
e. Akzeptieren Sie die Lizenzvereinbarung (License Agreement).
f. Klicken Sie auf Next.
g. Zeigen Sie die Zusammenfassung an und klicken Sie auf Finish, um die
Installation zu starten.
h. Wenn das Ergebnisfenster angezeigt wird, klicken Sie auf Finish.
i. Starten Sie ISA erneut, wenn Sie dazu aufgefordert werden.
3. Bereiten Sie den Einsatz der ISA-Funktionalität zum Analysieren von Problemen für WebSphere Remote Server vor.
a. Vor der Ausführung der Datenerfassung und PMR-Übergabe im ISA-Framework müssen Sie sicherstellen, dass das Log Collector-Tool auf dem Filialrechner (In-store processor, ISP) vorhanden ist. Dies ist erforderlich, da das
79
ISA-Plug-in Dateien erfasst, indem es automatisch das Log Collector-Tool
aufruft. Weitere Informationen finden Sie im Abschnitt „Log Collector”.
b. Navigieren Sie zu Analyze Problem → Collect Data und klicken Sie auf
Select Collectors.
c. Erweitern Sie die Produktbaumstruktur und suchen Sie nach WebSphere
Remote Server 7.0.
d. Fügen Sie den General Collector unter WebSphere Remote Server 7.0 der
Collector Queue hinzu und klicken Sie auf Collect All, um mit der Erfassung von WebSphere Remote Server-Protokollen zu beginnen.
Während der Erfassung erfragt der Datenkollektor den Namen der Ausgabedatei der Erfassung und die Position des WebSphere Remote ServerAusgangsverzeichnisses. Wenn die Erfassung abgeschlossen ist, fragt der
Datenkollektor, ob Sie die Protokolle per FTP-Verbindung an die IBM Unterstützungsfunktion senden wollen.
4. Ausführliche Anweisungen zur Verwendung von ISA erhalten Sie über die
Links auf der ISA-Unterstützungsseite.
Log Collector
Das Tool ’Log Collector’ erleichtert das Abrufen von Protokolldateien aus den
Filialrechnern (ISP). .
Protokolldateien archivieren
Nach der Installation der WebSphere Remote Server-Lösung auf dem ISP befindet
sich dort ein Script, mit dem Sie Protokolldateien in einer JAR-Datei Hostname_Logs_zeitmarke.jar archivieren können und zwar im folgenden Pfad:
SIF_HOME/bin/archivelogs.bat
SIF_HOME/bin/archivelogs_linux.sh
Wenn Sie das Log Collector-Tool ausführen, werden die Protokolldateien im folgenden Verzeichnis erfasst:
SIF_HOME\logs\collectedlogs\logs
SIF_HOME\logs\collectedlogs\logs
Wenn WebSphere Application Server installiert ist, erfasst das Log Collector-Tool
diese Dateien in einer JAR-Datei, die sich in folgendem Verzeichnis befindet:
SIF_HOME\logs\collectedlogs\archivelogs
SIF_HOME\logs\collectedlogs\archivelogs
Anmerkung: Wenn Sie die vorhandenen Protokolldateien aufbewahren wollen,
müssen Sie sie vor Ausführen des Log Collector-Tools sichern.
Fehlerbehebung, Tipps
In diesem Abschnitt werden einige Fehlermöglichkeiten mit den zugehörigen
Lösungen aufgeführt.
v „Das Launchpad wird nicht ordnungsgemäß geladen und zeigt den Fehler nicht
definiert an” auf Seite 81
v „Deinstallation schlägt fehl” auf Seite 81
80
v „Nach einer erfolgreichen Deinstallation sind weiterhin Dateien vorhanden” auf
Seite 82
v „WebSphere Remote Server-Deinstallationsprogramm erkennt bestimmte Produkte nicht ” auf Seite 82
v „DB2-Installation schlägt fehl” auf Seite 82
v „IBM HTTP Server zeigt einen Fehler bezüglich des vollständig qualifizierten
Domänennamens an” auf Seite 82
v „Installation eines Softwarepakets schlägt fehl” auf Seite 83
v „WebSphere Application Server-Ausnahmebedingung nach Installation” auf Seite
83
v „WebSphere Application Server-Ausnahmebedingung zur Handelsanwendung”
auf Seite 83
v „Ausnahmebedingung SRVE0255E” auf Seite 84
v „Informix Dynamic Server erneut installieren” auf Seite 84
v „Linux-Server mit aktivierter WebSphere Application Server-Sicherheit erneut
starten” auf Seite 84
Das Launchpad wird nicht ordnungsgemäß geladen und zeigt
den Fehler nicht definiert an
Das Launchpad kann nicht von einem fernen Laufwerk aus ausgeführt werden.
Gehen Sie wie folgt vor, um das Launchpad ordnungsgemäß auszuführen:
1. Kopieren Sie die IBM WebSphere Remote Server-Lösung in ein lokales Laufwerk und führen Sie das Launchpad aus.
2. Ordnen Sie das Netzlaufwerk einem lokalen Laufwerk zu und führen Sie das
Launchpad aus.
Deinstallation schlägt fehl
Die komplette WebSphere Remote Server-Lösung muss gestoppt werden, bevor das
Deinstallationsprogramm ausgeführt wird. Der Deinstallationsprozess ruft das
Script ’wrsstop’ auf, es kann aber sein, dass noch einige Komponenten der Lösung
aktiv sind (wie z. B. die WebSphere MQ-Warteschlangenmanager). Stoppen Sie alle
Komponenten von WebSphere Remote Server, bevor Sie die Deinstallation ausführen.
Wenn die Deinstallation eines Teils von WebSphere Remote Server nicht erfolgreich
ist, wird die WebSphere Remote Server-Basiskomponente nicht deinstalliert. Wenn
Sie das bei der Deinstallation aufgetretene Problem manuell korrigieren, reparieren
Sie Ihre WebSphere Remote Server-Metadatendatei (siehe unten) und führen Sie die
Deinstallation erneut aus.
WebSphere Remote Server-Metadatendatei reparieren: Die WebSphere Remote
Server-Metadatendatei verwaltet die Informationen zur WebSphere Remote ServerLösung. Tritt während des Deinstallationsprozesses ein Fehler auf, ist die
WebSphere Remote Server-Metadatendatei möglicherweise nicht mehr auf dem
aktuellsten Stand. In diesem Fall müssen Sie die WebSphere Remote Server-Metadatendatei aktualisieren, nachdem Sie das Deinstallationsproblem behoben haben.
Die Datei befindet sich in ’SIF_HOME/solution/WRSMetadata.xml’. Zum Aktualisieren der Datei entfernen Sie die Abschnitte, die sich auf die deinstallierten Produkte beziehen. Wenn Sie z. B. WebSphere MQ manuell entfernt haben, entfernen
Sie den Abschnitt <application name="MQ"...</application>.
81
Nach einer erfolgreichen Deinstallation sind weiterhin Dateien
vorhanden
Tritt während des Deinstallationsprozesses ein Fehler auf, führt die Anwendung
mit dem Fehler nicht die Schritte für eine vollständige Deinstallation aus. Sie müssen diese Schritte manuell ausführen. Die erforderlichen Schritte sind im Abschnitt
Die Option ’clean’ verwenden von „Deinstallation” auf Seite 24 aufgeführt.
WebSphere Remote Server-Deinstallationsprogramm erkennt
bestimmte Produkte nicht
Wenn das WebSphere Remote Server-Deinstallationsprogramm bestimmte Produkte
nicht erkennt, können Sie diese manuell mit den folgenden Befehlen deinstallieren:
WAS: /opt/IBM/SIF/WebSphere/AppServer/uninstall/uninstall -silent
IHS: /opt/IBM/SIF/HTTPServer/uninstall/uninstall -silent
DB2: /opt/IBM/SIF/db2/V9.5/install/db2_deinstall -a
MQ: /opt/IBM/SIF/bin/uninstallMQ.sh
WRSBASE: /opt/IBM/SIF/_uninst/uninstall -silent
WAS: "C:\Program Files\IBM\SIF\WebSphere\AppServer\uninstall\uninstall.exe" -silent
IHS: "C:\Program Files\IBM\SIF\HTTPServer\uninstall\uninstall.exe" -silent
MQ : msiexec.exe /x{5A2B3A23-0999-4D7E-BAAC-3B158C5FF003} /q
DB2: msiexec.exe /x{D7F20946-5D4B-4EF1-92E4-B3A1D54B7052} /q
WRSBASE: "c:\Program Files\IBM\SIF\_uninst\uninstall.exe" -silent
DB2-Installation schlägt fehl
Wenn DB2 bereits auf dem ISP installiert war, sind die DB2-Benutzer-IDs möglicherweise noch vorhanden. Die Installation kann nicht ausgeführt werden, wenn
das von Ihnen angegebene Kennwort nicht mit dem Kennwort für die vorhandenen DB2-Benutzer-IDs übereinstimmt.
Zur Behebung dieses Problems stehen zwei Möglichkeiten zur Verfügung:
v Löschen Sie die DB2-Benutzer-IDs (Windows: db2admin, Linux: db2inst1,
dasusr1, db2fenc1) und installieren Sie DB2. Stellen Sie sicher, dass Sie alle
Kennwortwerte in der Datei für unbeaufsichtigte Tasks ändern.
v Löschen Sie die DB2-Benutzer-IDs nicht. Installieren Sie DB2 und geben Sie das
Kennwort für die vorhandenen DB2-Benutzer-IDs an.
IBM HTTP Server zeigt einen Fehler bezüglich des vollständig
qualifizierten Domänennamens an
IBM HTTP Server erwartet einen vollständig qualifizierten Domänennamen und
gibt möglicherweise einen Fehler ähnlich dem folgenden zurück:
httpd: Could not determine the server's fully qualified domain name, using
9.42.121.61 for ServerName (httpd: Der vollständig qualifizierte Domänenname konnte
unter Verwendung von 9.42.121.61 für ServerName nicht festgestellt werden)
Die Problemlösung hierfür besteht darin, die Datei ’hosts’ des Computers mit dem
vollständig qualifizierten Domänennamen zu aktualisieren. Die Datei befindet sich
im Verzeichnis /etc/hosts unter Linux bzw. im Verzeichnis %SYSTEMROOT%\
System32\drivers\etc\hosts unter Windows. Beispiel: 9.42.121.61
wrslinisp2.rtp.raleigh.ibm.com wrslinisp2 wrsalias.
82
Installation eines Softwarepakets schlägt fehl
Wenn ein Softwarepaket nicht installiert werden kann, liegt dies möglicherweise an
fehlendem Speicherplatz im Bereitstellungsbereich. Als Bereitstellungsbereich wird
bei den Accelerators-Softwarepaketen standardmäßig das Verzeichnis /var/tmp/
SIF/staging verwendet. Sie können das als Bereitstellungsbereich verwendete Verzeichnis ermitteln, indem Sie die Quellendatei für das jeweilige Softwarepaket öffnen und darin die Variable stage_area suchen. Fehler bei Datenpaketen, die durch
fehlenden Plattenspeicherplatz ausgelöst werden, können Sie auf verschiedene
Arten beheben:
v Bei Unternehmensservern mit AIX können Sie versuchen, weiteren Plattenspeicherplatz für die Partition mit dem Bereitstellungsbereich verfügbar zu
machen.
v Sie können die Variable bereitstellungsbereich in allen Quellendateien für die
Softwarepakete (im Verzeichnis (serverDir/packages) aktualisieren. Aktualisieren
Sie die Variable so, dass eine Partition verwendet wird, auf der ausreichend
Plattenspeicherplatz verfügbar ist.
v Wenn zurzeit keine Softwarepakete installiert werden, können Sie den Inhalt des
Bereitstellungsbereichs (Standardverzeichnis: /var/tmp/SIF/staging) löschen.
WebSphere Application Server-Ausnahmebedingung nach Installation
Nach einer erfolgreichen Installation des Produkts wird möglicherweise die folgende Ausnahmebedingung in der Datei SystemOut.log angezeigt:
[3/19/09 13:23:03:810 PDT] 00000000 JMSRegistrati E WMSG1623E: The WebSphere MQ messaging
provider installed at C:\PROGRA~1\IBM\SIF\WEBSPH~1\APPSER~1\installedConnectors\wmq.jmsra.rar
has been updated and an application server restart is required to pick up this update. The
WebSphere MQ messaging provider has been disabled.
Sie können diese Ausnahmebedingung einfach ignorieren.
WebSphere Application Server-Ausnahmebedingung zur
Handelsanwendung
Nach einer erfolgreichen Installation der Middleware und der Anwendungen wird
möglicherweise die folgende Ausnahmebedingung zur Handelsanwendung in der
Datei SystemOut.log angezeigt:
[3/28/09 1:26:57:797 PDT] 0000000b WSServerImpl E WSWS1002E: An error occurred while
processing the Web services deployment descriptor for module: tradeWeb.war with error:
java.lang.NullPointerException
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:449)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
at com.ibm.ws.webservices.component.WSServerImpl.setupWsddPort(WSServerImpl.java:1150)
at com.ibm.ws.webservices.component.WSServerImpl.warMetaDataCreated(WSServerImpl.java:2089)
at com.ibm.ws.webservices.component.WSServerImpl.metaDataCreated(WSServerImpl.java:633)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.fireMetaDataCreated(MetaDataMgrImpl.java:189)
at com.ibm.ws.webcontainer.metadata.WebMetaDataFactory.createMetaData(WebMetaDataFactory.java:205)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaDataFromFactories(MetaDataMgrImpl.java:173)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaData(MetaDataMgrImpl.java:307)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:605)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:938)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:721)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2062)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:437)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:122)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:380)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300(CompositionUnitMgrImpl.java:108)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:935)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)
Sie können diese Ausnahmebedingung einfach ignorieren.
83
Ausnahmebedingung SRVE0255E
Nach einer erfolgreichen Installation des Produkts wird möglicherweise die folgende Ausnahmebedingung zur Datei favicon.ico in der Datei SystemOut.log angezeigt:
[5/4/09 22:57:27:759 PDT] 0000002b webcontainer E com.ibm.ws.webcontainer.WebContainer
handleRequest SRVE0255E: A WebGroup/Virtual Host to handle /favicon.ico has not been defined.
Diese fehlende Datei favicon.ico wird in der WebSphere Application ServerVerwaltungskonsole verwendet, um im Browser ein Symbol für ein Lesezeichen
oder auf einer Browserregisterkarte anzuzeigen, die in der Anwendung geöffnet
ist. Sie können diese Ausnahmebedingung einfach ignorieren.
Informix Dynamic Server erneut installieren
Wenn Sie Informix Dynamic Server installieren und anschließend deinstallieren,
ohne dabei die Option clean zu verwenden, wird die erneute Installation von
Informix Dynamic Server nicht unterstützt.
Die erneute Installation nach einer Deinstallation, bei der die Option clean nicht
verwendet wurde, wird für DB2 unterstützt.
Linux-Server mit aktivierter WebSphere Application Server-Sicherheit erneut starten
Wenn Sie die WebSphere Application Server-Sicherheit auf einem Linux-Betriebssystem aktiviert haben, müssen Sie sicherstellen, dass WebSphere Application Server heruntergefahren ist, bevor Sie einen Warmstart für den Server ausführen.
84
Kapitel 7. Referenzinformationen
Die nachstehenden Themen werden als zusätzliche Referenzinformationen zu Ihrer
Unterstützung bereitgestellt.
Allgemeine Produktinformationen
In diesem Dokument sind Informationen für den Zugriff auf die Downloadinformationen, die Produktunterstützungssite, die Hardware- und Softwarevoraussetzungen sowie die Dokumentation von IBM WebSphere Remote Server enthalten.
Auf die Website für die Produktunterstützung zugreifen
Rufen Sie die folgende URL-Adresse auf, um nach den neuesten technischen Hinweisen, Downloads, Programmkorrekturen und anderen Unterstützungsinformationen zu suchen: http://www.ibm.com/software/webservers/
remoteserver/support/.
Auf Hardware- und Softwarevoraussetzungen zugreifen
Informationen zu den Hardware- und Softwarevoraussetzungen finden Sie im
Information Center unter der folgenden Adresse: „Hardware- und
Softwareanforderungen” auf Seite 5.
Betriebssystemen.
Zusätzliche Produktdokumentation
Zusätzlich zu diesem Information Center sind auf einer separaten CD mit der
Bezeichnung Quick Start Handbücher für den Schnelleinstieg verfügbar.
Sie können auch über die Bibliotheksseite des Produkts unter der Adresse http://
www.ibm.com/software/webservers/remoteserver/library.html auf Produktdokumentation zugreifen.
Kontaktaufnahme mit der IBM Softwareunterstützung
Wenn Sie ein Problem mit WebSphere Remote Server feststellen, führen Sie
zunächst die folgenden Aktionen aus:
v Führen Sie die in der Produktdokumentation beschriebenen Schritte aus.
v Suchen Sie nach Referenzliteratur in der Onlinehilfe.
Wenn Sie Ihr Problem mit keiner dieser Methoden lösen können, wenden Sie sich
an die technische Unterstützungsfunktion von IBM.
Wenn Sie WebSphere Remote Server beziehen, erhalten Sie ein Jahr lang telefonische Unterstützung im Rahmen des Programms Passport Advantage. Details zu
Passport Advantage finden Sie auf der Seite für Passport Advantage.
85
Mitglieder von Passport Advantage erhalten Unterstützung zu WebSphere Remote
Server unter der Telefonnummer +49-7032-15-49201. Halten Sie die folgenden Informationen bereit:
v Ihre Vertrags- oder Passport Advantage-Nummer
v Ihre Version und Änderungsstufe von WebSphere Remote Server sowie alle
installierten Programmkorrekturen
v Name und Version des verwendeten Betriebssystems
v Typ und Version der verwendeten Datenbank
v Basisdaten zur Topologie: Anzahl der verwendeten Maschinen, Anzahl der
Anwendungsserver etc.
v Fehlernachrichten oder Warnungen (falls vorhanden) zum betreffenden Problem
White Papers
Dieser Abschnitt enthält einen Link zu für den Download verfügbaren White
Papers, die Ihnen Unterstützung bei der Installation, Konfiguration und Verwaltung der Komponenten Ihrer IBM WebSphere Remote Server-Lösung bieten.
Unter der folgenden URL finden Sie eine Liste der für WebSphere Remote Server
verfügbaren White Paper: http://www.ibm.com/support/search.wss?rs=2193
&tc=SSUNCX&rank=8&dc=DA480+DB100&dtm
Bemerkungen und Marken
Bemerkungen
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die
auf dem deutschen Markt angeboten werden.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte,
Services oder Funktionen in anderen Ländern nicht an. Informationen über die
gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim
zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme
oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder
Services von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Services können auch andere, ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder
anderen Schutzrechte von IBM verletzen. Die Verantwortung für den Betrieb von
Produkten, Programmen und Services anderer Anbieter liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM
Patente oder Patentanmeldungen geben. Mit der Auslieferung dieser Dokumentation ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind
schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf
Englisch formuliert werden):
IBM Director of Licensing
IBM Europe, Middle East & Africa
Tour Descartes
2, avenue Gambetta
92066 Paris La Defense
France
86
Der Inhalt dieser Dokumentation dient nur zu Informationszwecken. Diese Informationen basieren auf der aktuellen Produktplanung und -strategie von IBM, die
sich jederzeit ohne Vorankündigung ändern kann. IBM haftet nicht für Schäden,
die durch Verwendung oder im Zusammenhang mit dieser Dokumentation entstehen. Aus dem Inhalt dieser Dokumentation können kein Gewährleistungsanspruch
oder andere Anforderungen an IBM (oder seine Lieferanten oder Lizenzgeber)
abgeleitet werden, noch kann der Inhalt eine Änderung der Bedingungen der geltenden Lizenzvereinbarung, der die Nutzung der IBM Software unterliegt, bewirken.
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die hier enthaltenen
Informationen werden in regelmäßigen Zeitabständen aktualisiert und als Neuausgabe veröffentlicht. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen
und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten
und/oder Programmen vornehmen.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich
als Service für den Kunden bereitgestellt und stellen keinerlei Billigung des Inhalts
dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites
geschieht auf eigene Verantwortung.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern
der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen
allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann
daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen
machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind
an den jeweiligen Anbieter zu richten.
Diese Veröffentlichung dient nur zu Planungszwecken. Die in dieser Veröffentlichung enthaltenen Informationen können geändert werden, bevor die beschriebenen Produkte verfügbar sind.
Marken
Folgende Namen sind Marken der IBM Corporation in den USA und/oder anderen Ländern:
AIX
DataBlade
DB2
Express
IBM
Informix
iSeries
MQSeries
Passport Advantage
SupportPac
Tivoli
Tivoli Enterprise Console
Kapitel 7. Referenzinformationen
87
WebSphere
Intel, das Intel-Logo, Intel Inside®, das Intel Inside-Logo, Intel® Centrino®, das Intel
Centrino-Logo, Celeron®, Intel® Xeon®, Intel SpeedStep®, Itanium® und Pentium
sind Marken oder eingetragene Marken der Intel Corporation oder deren Tochtergesellschaften in den USA oder anderen Ländern.
Java und alle auf Java basierenden Marken und Logos sind Marken von Sun
Microsystems, Inc. in den USA und/oder anderen Ländern.
Linux ist eine eingetragene Marke von Linus Torvalds in den USA und/oder
anderen Ländern.
Microsoft, Windows, Windows NT® und das Windows-Logo sind Marken der
Microsoft Corporation in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen
Ländern.
Weitere Unternehmens-, Produkt- oder Servicenamen können Marken anderer
Hersteller sein.
88
Antwort
WebSphere® Remote Server
IBM® WebSphere® Remote Server Information Center Version 7.0
Version 7.0
Anregungen zur Verbesserung und Ergänzung dieser Veröffentlichung nehmen wir gerne entgegen. Bitte informieren Sie uns über Fehler, ungenaue Darstellungen oder andere Mängel.
Zur Klärung technischer Fragen sowie zu Liefermöglichkeiten und Preisen wenden Sie sich bitte entweder an Ihre
IBM Geschäftsstelle, Ihren IBM Geschäftspartner oder Ihren Händler.
Unsere Telefonauskunft ″HALLO IBM″ (Telefonnr.: 0180 3 313233) steht Ihnen ebenfalls zur Klärung allgemeiner Fragen zur Verfügung.
Kommentare:
Danke für Ihre Bemühungen.
Sie können ihre Kommentare betr. dieser Veröffentlichung wie folgt senden:
v Als Brief an die Postanschrift auf der Rückseite dieses Formulars
v Als E-Mail an die folgende Adresse: [email protected]
Name
Adresse
Firma oder Organisation
Rufnummer
E-Mail-Adresse
򔻐򗗠򙳰
Antwort
IBM Deutschland GmbH
SW TSC Germany
71083 Herrenberg

WebSphere Remote Server Information Center Version 7.0

Transcrição

Documentos relacionados

Architekturbüro "Architekturwert"

visionapp Platform Management Suite Most Recently Used List

Insights from the Global C-suite Study - The CHRO

So sichern Sie Ihren Datenschatz

IBM Flex System p260 und p460 Rechenknoten

AutoView - Bechtle

August-Ausgabe

Systemanforderungen Systemanforderungen für Sage WINCARAT

ESWC LF8 Counter-Strike 1

105SL™ - Zebra Drucker

step-by-step instruction

Diesen Artikel als pdf downloaden

5. Woche - Informationssysteme

LAME - - CHIP Online http://www.chip.de/downloads