Reverse Proxy Apache im laufenden Betrieb umkonfigurieren

[Pikachu]

Was ist mit euren produktiven Daten in der Datenbank.
Wie ziehen die mit um bei so einem Wechsel?
Oder habt ihr sowas nicht? :confused:

[dschroeder]

Ach so. Der Begriff "Testserver" war von mir vielleicht etwas unglücklich gewählt. Ich meine damit schon einen Server, der Webservice für die echten Datenbanken bereitstellt. Nur ist er für die Clients nicht erreichbar und damit nicht im produktiven Einsatz. Das heißt, wir können Programmänderungen auf diesen (zur Zeit nicht im Echteinsatz befindlichen) Server ausrollen. Wenn das Ausrollen erledigt ist, soll der reverse proxy die Requests aller Client auf diesen Server (der jetzt ja die neuesten Versionen der Programme hat) umleiten.

Dieter

[Pikachu]

Auf welchem Server liegen denn die (aktuellen produktiven) Daten auf die diese Programme zugreifen?

[dschroeder]

Die Daten liegen bei uns immer auf der iSeries.

Vielleicht nochmal als Grobskizzierung unserer Idee:

- Unsere Daten liegen alle auf unserer zentralen iSeries
- Unsere Kernanwendung (Individualprogrammierung) besteht aus RPG-Programmen
- Wir haben auch viele, immer wichtiger werdende, Java-Anwendungen für die PCs.
- Die Java-Anwendungen benötigen Daten aus der iSeries Datenbank.
- Um die im Laufe der Jahre entstandenen diversen Zugriffswege (ODBC, JDBC, SQL-UDF, SQLUDTF, ...) zu vereinheitlichen, möchten wir in Zukunft alles über Webservices abbilden.
- Die Webservices sollen in Java geschrieben werden. Die Java-Programme, aus denen diese Webservices bestehen, sollen ihrerseits ihre Daten mithilfe von SQL und von RPG-Programmen ermitteln.

Wenn das so klappt, hätten wir eine saubere Webservice-Schicht, die alle "PC-Anwendungen" von der iSeries abkapselt. Die Implementierung der Webservices soll in der Hand der iSeries Programmierer liegen.
Auf der iSeries sind wir es im RPG gewohnt, Programme auch mal im laufenden Betrieb kurzfristig auszutauschen. Das wollen wir natürlich auch mit unseren Webservices machen, bzw. mit den RPG-Programmen machen, die unsere Webservices bedienen.

Vielleicht hat der eine oder andere ja auch schon mal so eine Umgebung errichtet. Wir sind für jeden Tipp dankbar.

Dieter

[Rainer Ross]

Hallo Dieter,

ich war beim Bau meiner Hotelsuchmaschine mit einer ähnlichen Aufgabenstellung konfrontiert.

- Daten liegen auf der i
- RPG-Programme greifen auf die Daten per SQL zu und sollen sie über den Webserver dem Webfrontend (HTML5, CSS3, JavaScript, jQuery) per Webservice zur Verfügung stellen. Die geeignete Methode sind AJAX-Requests, die browserseitig mit JavaScript generiert werden.

Für den Datentransport vom Server zum Browser hat man zwei Formate zur Verfügung: XML oder JSON. Anfangs habe ich zu XML tendiert, habe mich aber nach umfangreichen Tests für JSON entschieden.

Das bedeutet, dass ich die RPG Programme grundsätzlich webservicefähig gebaut habe. Sie nehmen die Requests mit den Parametern vom Browser entgegen, lesen die Daten aus der Datenbank, dann erzeugen sie einen JSON-Datenstrom, den sie an den Browser zurücksenden. Das Ganze ist sehr performant. Die Antwortzeiten liegen im lokalen Umfeld im Schnitt bei 20ms - siehe Grafik. Wenn es über das Internet läuft, kommt noch die Latenzzeit von 100-200ms dazu.

Gestern hatte ich 90.000 Zugriffe auf meinen Webserver gemessen. Die Antwortzeit für die Bereitstellung einer Website an den Browser liegt bei 0,46s im Durchschnitt, die Internet-Latenzzeit ist mit eingerechnet. Die Prozessorauslastung der IBM i liegt bei ca. 3%. Mir scheint, da ist noch richtig Luft nach oben.

Noch eine kleine Anmerkung zum Thema RPG-Programmaktualisierung. Wenn ein RPG Programm, das als Webservice fungiert geändert und ins Echtsystem eingespielt wird, ist es sofort scharf, ohne dass der Webserver neu gestartet werden muss.

Ein kleines Beispiel soll dieses Vorgehen transparenter machen. Die Aufgabenstellung ist, die Spools eines Anwenders im Browser darzustellen und jede Spalte sortierbar zu machen. Hierfür habe ich ein RPG-Programm erstellt, dass die Spooldaten per API ausliest, daraus JSON-Daten erstellt und sie an den Browser sendet.

Dieses Programm kann per JavaScript über einen AJAX-Request aufgerufen werden:
http://www.myhofi.com/devhtm/spoolsorter.htm


function readJsonSpoolData() {
ajaxRequest01.send("POST", xmdomain + "expcgip/lstspl04.pgm",
requestHandlerSpoolData, xmcontent);
}
oder wenn es direkt über
http://www.myhofi.com/expcgip/lstspl04.pgm
aufgerufen wird, dann ist es ein Webservice

Wenn man zusätzlich Parameter übergeben möchte, dann im folgenden Format:
test.com/programm.pgm?kundennr=4711&ort=muenchen&strasse=lindenstr&user=test&password=geheim (http://www.test.com/prgramm.pgm?kundennr=4711&ort=muenchen&strasse=maximilianstr&user=test&password=geheim)

Mit V7R2 und dem kostenlosen OpenSource Lizenzprogramm 5733OPS kann man Node.js auf der IBM i installieren und mit serverseitigen JavaScript Anwendungen schreiben. Node.js nutzt die V8 JavaScript Engine von Google, die für den Chrome-Browser entwickelt worden ist.

Ich habe es installiert und es genügen wenige Zeilen Code, um auf die DB/2 zuzugreifen und die Daten im JSON-Format an den Browser zu senden


var http = require('http');
var db = require('/QOpenSys/QIBM/ProdData/Node/os400/db2i/lib/db2');
var conf = {"port": 8020};

http.createServer(function(request,response) {
db.init();
db.conn("*LOCAL");
db.exec("SELECT CUSNUM, LSTNAM, CITY, BALDUE FROM QIWS.QCUSTCDT", function(rows) {
response.writeHead(200, {'Content-Type': 'application/json'});
response.end(JSON.stringify(rows));
});
db.close();
}).listen(conf.port,'your ip');

console.log('Server running at http://your ip:' + conf.port + '/');


Herzliche Grüße

Rainer

www.myhofi.com (http://www.myhofi.com)
Hotels finden leicht gemacht - powered by IBM i
www.powerwire.eu/speedy-websites-a-winner-with-power-i-and-watson (http://powerwire.eu/speedy-websites-a-winner-with-power-i-and-watson)

[dschroeder]

Hallo Rainer,
vielen Dank für deinen ausführlichen Beitrag. Ich denke, wir haben da ähnliche Problemstellungen. Wir haben uns ebenfalls für JSON als Datenformat entschieden. Mit Node.js haben wir vor einer Woche auch experimentiert. Bei Node.js haben wir jedoch den Nachteil gesehen, es im Kern nicht multithread-fähig ist. Wir haben da ein paar Experimente gemacht und festgestellt, dass man den Webserver mit einigen Javascript-Operationen schnell lahmlegen kann. Zwar sind die I/O-Operationen asynchron, aber der Aufruf (besser gesagt, die Aufrufvorbereitung) eines RPG-Programms kostet bei uns knapp 10ms. Wir haben die Sorge, dass das nicht so gut skaliert. Deshalb sind wir jetzt auf dem Weg, die Webservice-Schicht mit Java zu machen.

Dieter