Workload-Management |
Technische Informationen zum Beispiel BeenThere |
Quellcode |
Codierungshinweise |
Sie finden den Quellcode für die Anwendung BeenThere im Verzeichnis
Anmerkung für z/OS-Benutzer: Die Quellcodestruktur für die Beispiele wird unter z/OS nicht bereitgestellt, weil auf der z/OS-Plattform keine Beispielanwendungen erstellt werden.
Die Anwendung BeenThere veranschaulicht die WLM-Funktionen (Workload Management) von IBM WebSphere Application Server Network Deployment Edition. Die Anwendung BeenThere umfasst Servlet BeenThere und die Stateless-Session-Bean BeenThere. Das Servlet BeenThere demonstriert den Anwendungsserver in einem Cluster, an den eine HTTP-Anforderung gesendet wird. Die Enterprise-Bean BeenThere demonstriert den Anwendungsserver in einem Cluster, an den eine EJB-Anforderung gesendet wird. Die Enterprise-Bean BeenThere wird vom Servlet BeenThere aufgerufen.
Das Servlet BeenThere zeigt die folgenden Informationen an:
Außerdem kann das Servlet BeenThere die folgenden Aktionen ausführen:
Die Beispielumgebung, die zur Veranschaulichung des Lastausgleichs für Webcontainer und EJB-Container verwendet wird, ist in der folgenden Abbildung dargestellt:
Abbildung 1 Die Beispielumgebung
Die Umgebung enthält die folgenden Maschinen:
Die Konfiguration umfasst zwei Server-Cluster, MyWebCluster und MyEJBCluster. Ein Server-Cluster setzt sich aus einer Gruppe von Application Servern zusammen. Falls einer der Member-Server ausfällt, werden die Anforderungen an die anderen Member des Cluster weitergeleitet. Jeder der Beispiel-Cluster enthält zwei Cluster-Member. Der Cluster MyWebCluster setzt sich aus den Cluster-Membern WebServer1 und WebServer2 und der Cluster MyEJBCluster aus den Cluster-Membern EJBServer1 und EJBServer2 zusammen.
Diese konfigurierte Umgebung ist ein Beispiel, das lediglich zeigt, wie die Anwendung BeenThere ausgeführt wird. In einer Produktionsumgebung müssen Sie den Einsatz der Ressourcen sorgfältig planen, um festzustellen, wie viele Application-Server-Member für eine bestimmte Anzahl von Maschinen zu erstellen sind. Zur Planung muss die erwartete Anforderungslast der Clients herangezogen werden.
WebSphere Application Server Network Deployment Edition unterstützt das Workload Management (WLM) für HTTP-Anforderungen und EJB-Anforderungen.
Das Workload Management von HTTP-Anforderungen wird vom Webserver-Plug-in durchgeführt.
Sehen Sie sich die Konfiguration in Abbildung 1 an. Auf der Maschine web wird ein IBM HTTP Server ausgeführt, der HTTP-Anforderungen an die Application Server WebServer1 und WebServer2 verteilt, die Member des Cluster MyWebCluster sind und das Servlet BeenThere ausführen. Diese Application Server sind auf den Maschinen app1 bzw. app2 konfiguriert. Außerdem ist das Plug-in für den IBM HTTP Server so konfiguriert, dass WebServer1 die WLM-Gewichtung 2 und WebServer2 die WLM-Gewichtung 3 hat. Sie können sich die Gewichtungen als Zähler vorstellen, die bei einem konfigurierten Wert beginnen und mit jeder bedienten Anforderungen um 1 verringert werden. Anforderungen können im Round-Robin-Verfahren an jeden Application Server verteilt werden, dessen Gewichtungszähler größer als 0 ist. Hat ein Application Server einen Gewichtungswert von 0, wird er übergangen. Wenn alle Gewichtungszähler bei 0 angekommen sind, werden sie auf die konfigurierten Werte zurückgesetzt, und der Verteilungsprozess beginnt von vorn.
Das Workload Management von EJB-Anforderungen wird intern vom WLM-Controller in WebSphere Application Server durchgeführt.
Sehen Sie sich die Konfiguration in Abbildung 1 an. Der definierte Cluster MyEJBCluster umfasst die Application-Server-Member EJBServer1 und EJBServer2, die für die Ausführung der Stateless-Session-EJB BeenThere zuständig sind. Das Servlet BeenThere setzt einen Aufruf an die Enterprise-Bean ab, um Ausführungsinformationen zu dem Application Server zu erhalten, in dem die Enterprise-Bean ausgeführt wird. Außerdem sind diese Server mit den Gewichtungen 1 bzw. 3 konfiguriert.
Auf der Plattform "z/OS" werden Wertigkeiten für eine gleichmäßige Verteilung von HTTP-Anforderungen verwendet, jedoch nicht für die gleichmäßige Verteilung von IIOP-Anforderungen (Internet Inter-ORB Protocol).
Die Anwendung BeenThere verwendet die Administrations-APIs (Application Programming Interfaces) von WebSphere Application Server. Über diese Schnittstellen können Anwendungen auf die Konfigurationsdaten für die Laufzeit und die Umgebung zugreifen:
Bietet serverseitige Schnittstellen, über die Informationen zu den Attributen des Application Server abgerufen und Standardverwaltungsfunktionen für JMX-MBeans ausgeführt werden können.
Bietet clientseitige Schnittstellen zu einem fernen AdminService-Objekt. Die Klasse AdminClient stellt über einen der unterstützten JMX-Connector (Java Management Extensions) einen Proxy zum fernen AdminService-Objekt bereit.
Bietet Schnittstellen zum lokalen oder fernen Abfragen oder Ändern von Konfigurationsdaten und verwaltet Position und Inhalt der Konfigurationsdokumente des Application Server.
Zur Veranschaulichung der Stärke und Flexibilität, die Anwendungen durch den Einsatz der Administrationsschnittstellen von WebSphere Application Server erlangen, verwendet die Anwendung BeenThere all diese Schnittstellen wie folgt:
Die Schnittstelle AdminService wird sowohl vom Servlet als auch von der Enterprise-Bean BeenThere verwendet, um den Knotennamen, den Namen des Application Server und die Prozess-ID des Application Server zu ermitteln, in dem sie ausgeführt werden. Das folgende Codesegment zeigt, wie die Serverattribute abgerufen werden:
// WebSphere AdminService abrufen. AdminService adminService = AdminServiceFactory.getAdminService(); // Instanz von WebSphere Admin Local Server MBean abrufen. ObjectName localServer = adminService.getLocalServer(); // Knotennamen abrufen. nodeName = (String) adminService.getAttribute(localServer, "nodeName"); // Namen des Application Server abrufen. serverName = (String) adminService.getAttribute(localServer, "name"); // Prozesss-ID des Application Server abrufen serverPid = (String) adminService.getAttribute(localServer, "pid");
Mit der Schnittstelle AdminClient wird eine Verbindung zum Deployment-Manager-Prozess hergestellt, um die Gewichtungen aller Application-Server-Member des Cluster abzurufen, in dem die Enterprise-Bean BeenThere ausgeführt wird. Das folgende Codesegment veranschaulicht, wie eine Instanz der Schnittstelle AdminClient angefordert wird:
// WebSphere AdminService abrufen. AdminService adminService = AdminServiceFactory.getAdminService(); // AdminClient-Instanz für den Deployment Manager abrufen. adminClient = adminService.getDeploymentManagerAdminClient();
Die Schnittstelle ConfigService liest das WAS-Konfigurationsdokument cell.xml, um festzustellen, ob die Anwendung BeenThere in einer Umgebung mit WebSphere Application Server Base Edition oder Network Deployment Edition ausgeführt wird. Das folgende Codesegment veranschaulicht, wie die Umgebung bestimmt wird, in der eine Anwendung ausgeführt wird:
// Neue WebSphere-Verwaltungssitzung erstellen. Session session = new Session(); // WebSphere-ConfigService-Instanz für den Anwendungsserver abrufen, // der dieses Servlet ausführt. ConfigService configService = ConfigServiceFactory.getConfigService(); if (configService != null) { // Dokument cell.xml lesen. ObjectName cellObj = ConfigServiceHelper.createObjectName(null, "Cell"); ObjectName[] cellObjs = configService.queryConfigObjects(session, null, cellObj, null); if (cellObjs.length != 0) { cellObj = cellObjs[0]; String cellName = (String) configService.getAttribute(session, cellObj, "name"); String cellType = (String) configService.getAttribute(session, cellObj, "cellType"); if (cellType.equals("DISTRIBUTED")) { websphereND = true; } } // Sitzung freigeben. configService.discard(session);Wenn eine Network-Deployment-Umgebung ermittelt wird, wird die Option "Display bean cluster member weights" aktiviert und angezeigt, weil diese Option nur in dieser Art von Umgebung gültig ist. Andernfalls ist diese Option nicht auswählbar.