[php] SOAP / XML-RPC / Web Services

[Dr. Volker Göbbels]

Hallo,

da reg ich an, mich zu löchern und dann kommt mir jemand zuvor ;o))

>> > Vor allem die Frage: "Braucht man sowas wie SOAP oder XML wirklich?"
>> > ist interessant. Und einfach oder pauschal sind die Antworten darauf
>> > ja auch nicht ;)
>>
>> Rein Marketingmaessig sind XML und SOAP natuerlich Spitze, aber mich
>> interessiert nur die technische Seite...  Wie waere es denn mal mit
>> einem ernsthaften Versuch ?  z.B. irgendwo auf einer Messe ...

Das mit dem Marketing ist ein Problem. XML ist schon lange so sehr
Schlipsträgers Lieblings-Buzzword ... da sehen viele die Technik dahinter
nicht mehr oder nur noch mit gewissen Vorbehalten.

>> 1. Lasst >1000 vorbeilaufende Leute eine Irgendwas.INI und eine
>> Irgendwas.xml ohne Hilfe ausfuellen oder aendern und schaut, welches

[...]

>> Format hinterher weniger Fehler aufweist.  Die benoetigte Zeit sollte
>> auch erfasst werden.

Erfaßt du auch die Zeit die das Entwicklerteam dazu brauchte, einen
fehler-resistenten Parser für deine selbst erfundenen Dateiformate
und das zugehörige Protokoll zu entwicklen?
Den XML-Parser jeder Couleur gibts mittlerweile an jeder Ecke, und
glaubs mir: die Dinger sind SCHNELL. Die sind schneller wie preg_match
Geschichten zum Finden von Informationen im Text.
Und Regexe würdest du benutzen müssen, um ein Mindestmaß an "Pattern-
Intelligenz" in deinen Parser zu bekommen.
Ich weiß deswegen so genau wovon ich rede, weil wir exakt das schon mal
an einem XML-File ausprobiert haben:
Das Argument meiner Seite war: "Ach was, um ein XML-Tag zu lesen und zu
ersetzen bau ich mir keinen XML-Parser zusammen, das mach ich mit
preg_replace!"
Jo, schade nur, daß ein kompletter Parser, der ja 98% des XML nur
durchreicht
und nur 2% davon bearbeitet trotz des angeblichen XML-Overheads jedes Tag
lesen und zerlegen zu müssen knapp 5-10 mal so schnell war wie der
Pattern-Matcher ;)
Und jetzt sag nicht: "Ach das lag am XML, nimm ein reines Textfile oder
ein ini-Format und alles geht fix"
Textfile ist Textfile für eine Regex. Der stört sich nicht an XML-Tags.
Und das Datenformat war nicht besonders redundant oder geschwätzig.

> Wie trage ich denn in die .ini Datei vernünftig mehrdimensionale Arrays,
> Verknüpfungen, verschiedene Datentypen, Strukturen, usw. ein, ohne mir
> _noch_ ein weiteres Format ausdenken (und es dann implementieren (und
> warten)) zu müssen?

Das kommt noch hinzu. Zudem kann man die XML-Chunks, die man übers Netz
schickt
auch geschickterweise zippen. Dann sind sie sehr klein, ASCII ist gut und
gerne
um den Faktor 6 oder noch besser komprimierbar.

>> Damit meine ich nicht, dass es nicht moeglich ist, sondern nur, dass
>> es vom notwendigen Aufwand her keinen Sinn macht.

Prima, das ist das wichtigste Argument FÜR XML. Der Aufwand. Der ist nämlich
geringer. Sowhol bei der Software-Erstellung wie auch beim Abarbeiten. Wie
gesagt, du würdest staunen, wie schnell gute XML-Parser sind. Die wurden
nämlich meist von Leuten gebaut, die im Parserbau etc. um Längen mehr
Erfahrung wie wir haben. Und dagene würd ich keine eigene
Parserimplementierung
von mir setzen. Egal, wie das Datenformat aussieht oder heißt.

>> Da der Endkunde von dem alles nichts mitbekommt, kann das einzige
>> Kriterium IMHO nur die verschwendete Bandbreite sein.  Das gilt fuer
>
> Und das sagt jemand, der Word und Excel Dateien auf seiner Homepage
> anbietet. Na bravo.

Da geb ich dir Recht.
Word- und Excel-Dateien haben auf einem Web-Server nix zu suchen. Im Sinne
von Bandbreite udn Accessability macht man das in PDF und gut ist ;)

> Wenn man auch Windows als Server benutzt ... ;-)

Wer nutzt Windows als Server? Norbert? Huch. Das ist eines der
"Don't ever, never ever try this" Dinge. IIS kenn ich da nicht
mal so genau, aber einen Apache möchte ich auf Windows nicht produktiv
betreiben, da hab ich schon zuviel Müll gesehn. Und das liegt
wohlgemerkt nicht am Apache :->

> Hm, und was hat das jetzt genau mit XML zu tun? Es gibt weitaus
> schlimmere Bandbreitenverschwendung, um die man sich vorher kümmern
> sollte. z.B. unkomprimierte Postscript-Dateien, BMP-Dateien, oder 40k
> grosse HTML-Dateien, die ohne _irgendwas_ am _Inhalt_ zu ändern auf 2k
> runtergeschrumpft werden können, weil sie 38k sinn- und nutzlose MS
> Office-Tags enthalten. Siehe auch

Jo, da gibts geniale Sachen. Oder dieser typische Macromedia-Javascript-
Header mit all dem mm_XXX Functions, die dann nirgends in der Page benutzt
werden ...

Viele Grüße,
Volker Göbbels
---
Arachnion GmbH & Co. KG                  Dr. Volker Göbbels
Business Communication                     vmg_(at)_arachnion.de
Gouleystr. 59                     Tel. +49 (0) 2405 42477-0
52146 Würselen                     Fax +49 (0) 2405 42477-2
 Web Application Development, Consulting, Linux HA Cluster
        Kompetenz in Unix: http://www.arachnion.de