Webservice Performance

[BenderD]

... zu Net.Data kann ich mich nicht äußern, da fehlt mir sowohl Kenntnis als auch erst recht Erfahrung. Aber vielleicht nochmal ein paar Grundlagen zu WebServices und deren Implementierung.
Bei einem WebService git es eine Kette von Schichten, die von der Implementierung bis zur WSDL reicht. Der Punkt, wo sich die Spreu vom Weizem teilt ist: Top down oder Bottom up und das ist in erster Linie ein Problem der verfügbaren Tools!!! Die volle Bandbreite hat man, wenn man mit der WSDL anfängt, natürlich kann man jetzt mit CGI Programmen sich ein XML um die Ohren hauen lassen und das mit was auch immer auseinanderfusseln und da was zusammen basteln, wenn die Schnittstelle einfach genug ist, kriegt man das auch hin. Genau bei den Fragen wie hier - variable Anzahlen von Wiederholungsgruppen - fangen dann die Probleme an, die hier keineswegs aufhören, eine WSDL Schnittstelle kann weit komplizierter sein!
Dann gibt es Zauberkästen, vergleichbar mit Zauberkästen, die man für 20 € kauft und 8 jährigen zu Weihnachten schenkt, die können ganz einfache WebServic Schnittstellen erstellen, meist bottom up, da steckt man oben einen RPG Prototyp rein und bekommt unten einen WebService raus, die können dann soviel, wie ein RPG Prototyp kann - und der kann nicht soviel, wie hier ja gerade diskutiert wird.
Macht man das z.B. mit Java, dann gibt es in Eclipse plugins, die einem da viel abnehmen; da kann man aus der WSDL eine Dummy Implementierung (einen Skeleton) generieren, den man dann nur noch füllen muss. Das ist einfach und frei verfügbar, nicht zuletzt dadurch Mainstream, was einigermaßen sicherstellt, dass das in 5 Jahren auch noch so geht und einigermaßen zuverläsig funktioniert. Bei .Net ist die Lage ähnllich, da kauft man das alles zusammen für eine überschaubare Gebühr von Herrn Gates und befindet sich dann auch da im Mainstream.

D*B

PS: Bei der Verwendung sieht das wieder ganz ähnlich aus, aber das ist ein anderes Thema.

[ThomasSprenger]

Vielen Danke an alle,
dann werde ich wohl meine WSDL nehmen und mal alles TOP-Down mit Java erstellen. Dort dann die benötigten RPG- Programme aufrufen.
Kann ja dann meine Erfahrungen hier dazu posten.

[BenderD]

... dazu noch ein paar Tipps:
- das PCML Geraffel für Aufrufe würde ich generell vermeiden
- wenn die genug können dann die RPG Programme als stored Procedures einpacken
- die List Problematik kann man dann auch durch mehrfach aufrufen mit einem more Flag als zusätzlichem Parameter abbraten, wenn man nicht gleich EInzelaufrufe draus macht und den Rest der Logik ins Java schiebt.
- immer überlegen, ob der RPG Einsatz überhaupt Sinn macht; meist mangelt es an einsetzbaren Komponenten, die diesen Namen verdient haben und beim neuprogrammieren bricht man sich im RPG oft die Finger ab, für Dinge die in Java einfacher, mit weniger Aufwand und besser zu erledigen gewesen wären.

D*B

[ThomasSprenger]

Das sind RPG-Module die die Verfügbarkeit von Artikeln ermitteln oder bei Produktion berechnen, + den Preis Incl. Konditionen und Fracht.

Das nach zu programmieren, würde dann den Rahmen sprengen ;-).

[BenderD]

... wenn das Komponenten sind, ist das völlig in Ordnung, In diesem Fall ist es ja auch so, dass das alles politisch abgenickt ist und jede Änderung des Wahrheitsgehaltes (egal ob richtiger oder falscher) bei Neuprogrammierung problematisch ist.
Da sollte nur dann in der neuen Anwendung die technologische Seite der (Alt) Komponenten gekapselt werden.
(in Java: komplett eigenes Package für die Bedienung der Komponenten und Facade Objekte als Proxy in der Java Applikation).

D*B

[Fuerchau]

Nur so eine Idee:

Da die Struktur ja übergeben wird ist sie ggf. nicht initialisiert.
Auf Grund der numerischen Felder kommt es bei der Umwandlung in das XML-Format zu Dezimalfehlern und damit zu ggf. zeitaufwändigem Fehlerhandling.

Bevor du die Struktur also befüllst, mach mal vorher einen CLEAR, so dass alle Felder initialisiert werden.

[ThomasSprenger]

Gelöst-erst mal.
Sollte wer das gleiche Problem haben:
Da ich nicht alles komplett neu programmieren wollte habe ich mir erst mal die Java Sourcen von der AS/400 für diesen Webservice unter IFS-Root/www/WSSERVICE/webservices/services/NameService auf ein lokales Laufwerk kopiert (sind verständlich und ich finde die sehen nicht mal so schlecht aus). Projekt drüber erstellt, die NameWbservice.config angepasst und in den Classpath kopiert und eine Serverklasse dazugeschrieben. Dies dann als Webservice mit Zugriff auf die AS/400 lokal laufen lassen.
Siehe da die Antwortzeiten waren beim gleichen Service (nach der einmaligen Anmeldung von ca. 2 Sek.) bei nur 0,1 – 0,3 Sekunden.
Da eine 520 nicht soviel langsamer sein kann habe ich noch mal nach allgemeinen Tuning maßnahmen gesucht und unter WebSphere Application Server for iSeries Information Center -> Performance -> Tune Performance gefunden. Nach dem ich alle Punkte durch hatte, war mein erster Aufruf bei ca.3 Sek (erstes Laden-da dann persistent) danach bei 0,3-0,7 Sekunden, also ganz brauchbare Zeiten.
Im Endeffekt glaube ich, dass das Logging mein größtes Problem war.

[Fuerchau]

Mit dem Logging erklärt sich das auch.
Häufig wir da jedesmal die Datei geöffnet, ans Ende positioniert, geschrieben und dann geschlossen.
Schließlich will man die Info ja auch im Falle eines Absturzes, da macht es wenig Sinn die Logfile zu cachen.
Je länger dann das Log, desto langsamer das Programm.