nicht angemeldet
SOAP - Dienst, WebServices und XML : W-A-R-U-M XML???
Halihallo
Ich möchte mal kurz Feuer entzünden (bestimmt kommen rege Antworten) und starte eine sehr *kritische* Frage.
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol) programmieren, d. h. SOAP für ein Intranet und somit die Kommunikation zwischen firmeninternen Diensten. Hab aber, frech wie ich bin, kurzerhand XML durch ein (besseres ;) ) Format ersetzt. Einen solchen SOAP-Dienst kann man nämlich viel einfacher umsetzen. Etwa so wie das HTTP-Protokoll aufgebaut ist (das wurde ja noch nicht XML-ifiziert).
Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa 40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben etwas grösser).
Ich frage mich warum? - Nur dem Standard willen? - Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet erreichbar sein soll, verstehe ich den Vorteil von XML, aber in einem Intranet, wo man die Standards selber festlegt? - Ich weiss nicht.
Was haltet ihr von dieser XML-ifizierung? - Also ich bin ein Freund der "alten Schule".
Viele Grüsse
Philipp
-
Hallo Philipp
Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa 40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben etwas grösser).
Nichts spricht dagegen, dass du deine eigenen Formate schaffst. Es spricht auch nichts dagegen, dass dein Nachbar, dein Kollege oder sonst wer auf der Welt das tut. Feel free! Und solltet ihr dann irgendwann durcheinander reden wie die Buerger von Babel, euch um das beste Format kloppen und das siebzehnte Metaprotokoll zur Kommunikation zwischen A un B implementiert habt ... dann wird wahrscheinlich irgendso ein Historiker daherkommen und sagen: "Halt! Die alten Neuzeitler um die Wende des 3. Jahrtausends hatten doch schon eine Loesung fuer all diese Datenaustauschprobleme gefunden! Lasst uns doch diese wieder aufgreifen! Ich lehre sie euch gerne - sie heisst XML..."
viele Gruesse
Stefan Muenz-
Halihallo Stefan
Nichts spricht dagegen, dass du deine eigenen Formate schaffst. Es spricht auch nichts dagegen, dass dein Nachbar, dein Kollege oder sonst wer auf der Welt das tut. Feel free! Und solltet ihr dann irgendwann durcheinander reden wie die Buerger von Babel, euch um das beste Format kloppen und das siebzehnte Metaprotokoll zur Kommunikation zwischen A un B implementiert habt ... dann wird wahrscheinlich irgendso ein Historiker daherkommen und sagen: "Halt! Die alten Neuzeitler um die Wende des 3. Jahrtausends hatten doch schon eine Loesung fuer all diese Datenaustauschprobleme gefunden! Lasst uns doch diese wieder aufgreifen! Ich lehre sie euch gerne - sie heisst XML..."
Oh, jeh, jetzt bin ich sprachlos! - Ja, du hast natürlich recht. Es ist natürlich schön einen solchen Standard zu haben. Alle verstehen alle, oder? - Nix da! - XML ist nichts anderes als eine Vorgabe, wie der Inhalt eines Dokumentes auszusehen hat (eine DTD eben), oder eine Ansammlung von Daten mit einer gewissen Struktur.
Aber was heisst das? - Dass man ein Programm schreiben kann, welches ein XML Dokument einliest und dann weiss wie es den Inhalt darstellen muss, bzw. welchen Befehl es ausführen muss?<glossar>
<record>
<name>bla1</name>
<link>#bla1</link>
</record>
<record>
<name>bla2</name>
<link>#bla2</link>
</record>
</glossar>ist das besser als ... ?
[record]
name=bla1
link=#bla1[record]
name=bla2
link=#bla2schön und gut, aber ein Kunde muss trotzdem wissen, wie das Dokument aufgebaut ist. Also kann man doch gleich eine eigene Definition bringen. Natürlich kann man dann nicht auf gemeinsame Ressourcen wie XML::DOM oder SAX, ... zugreifen, aber XML kann nie die Kommunikation zwischen Serviceanbieter und -benutzer ersetzen. Die Kommunikation muss vorhanden sein, und durch dieses "Grundaxiom" ist es doch auch nicht falsch, wenn ich sage: "Warum nicht ein eigenes Format, dass der Anwendung angepasst ist?" - Ich meine, um nun XML oder ein eigenes Format zu implementieren macht doch keinen Unterschied, nicht?
Auch mal ganz abgesehen davon, dass die Verwendung eines XML basierten Dienstes die Netzwerkaktivität enorm erhöht, da das Format eben nicht der Anwendung angepasst ist.Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Viele Grüsse
Philipp
-
Hallo Philipp
XML ist nichts anderes als eine Vorgabe, wie der Inhalt eines Dokumentes auszusehen hat (eine DTD eben), oder eine Ansammlung von Daten mit einer gewissen Struktur.
Korrekt. Deshalb ist es ja auch besser als ein Standard direkt auf Datenebene. Es ist ein Standard, der eine Ebene dahinter ansetzt. "Meta..." eben.
Aber was heisst das? - Dass man ein Programm schreiben kann, welches ein XML Dokument einliest und dann weiss wie es den Inhalt darstellen muss, bzw. welchen Befehl es ausführen muss?
Wie XML-Daten bei der Ausgabe/Darstellung (wo eigentlich? Drucker? Bildschirm? Stimme im dunklen Raum? Voellig egal!) auszusehen haben, steht in den XML-Daten nicht drin - das ist ja der Trick. Dazu gibt es Techniken wie XSL oder XSLT. Klar, irgendein Programm muss es dann mal geben, mit dessen Hilfe man irgendwas irgendwo ausgeben kann. Es muss einen z.B. einen Browser geben, der HTML-Daten ausgeben kann, die durch mit XSLT-uebersetztes XML zustande gekommen sind, oder ein Programm, das ein separates Audio-Stylesheet interpretieren kann, mit dem die XML-Elemente fuer eine akustische Ausgabe "formatiert" werden.
schön und gut, aber ein Kunde muss trotzdem wissen, wie das Dokument aufgebaut ist.
Muss er das? Dann kann er ja einen schicken XML-Editor verwenden, wie X-MetaL oder so was. Und wenn er keine Angst vor spitzen Klammern hat, wird es auch Notepad tun.
Also kann man doch gleich eine eigene Definition bringen.
Klar, das war ja auch ernst gemeint, als ich das gesagt habe in meinem vorigen Posting. Wenn du definitiv weisst, dass die Datenschnittstelle nie von etwas anderem verwendet wird als dem, was du da jetzt bastelst, dann spricht nichts dagegen, etwas moeglichst Einfaches zu nehmen, wie z.B. eine reine INI-Datei. Aber wenn irgendwann mal noch andere Software-Module oder Anwendungen auf diese Datenschnittstelle zugreifen sollen, die nicht von dir stammen, sondern von irgendwem - soll dann der gezwungen werden, sich mit deinem INI-Format rumzuschlagen? Viel einfacher ist es dann, wenn er eine XML-DTD hat, wo steht, wie die Daten aufgebaut sind. Da braucht er dann nur noch einen XML-Parser zum Einlesen, den ja jede moderne Programmiersprache als Modul zur Verfuegung stellt, und schwupps, schon hat er die Daten, und zwar nicht nur eingelesen, sondern auch inhaltlich strukturiert.
Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Naja, die falsche Euphorie, die mit solchen Sachen seit jeher verbunden wird, verfliegt halt irgendwann wieder. Was dann bleibt, ist ein Standard, der sicher viele Probleme loesen wird - wenn auch nicht alle. Aber dafuer wurde er wohl auch nicht gemacht ;-)
viele Gruesse
Stefan Muenz-
Halihallo Stefan
Aber was heisst das? - Dass man ein Programm schreiben kann, welches ein XML Dokument einliest und dann weiss wie es den Inhalt darstellen muss, bzw. welchen Befehl es ausführen muss?
Wie XML-Daten bei der Ausgabe/Darstellung (wo eigentlich? Drucker? Bildschirm? Stimme im dunklen Raum? Voellig egal!) auszusehen haben, steht in den XML-Daten nicht drin - das ist ja der Trick.
Stimmt. Das war ja auch die Kritik. Da XML nur ein "Datenträger" ist und somit den Daten ein gewisses Format aufzwingt; hat es mir eben einen schlechten Eindruck hinterlassen, da man ja passende Formate einfach selber erstellen kann (die eben der Anwendung angepasst sind). XML alleine bringt mir einfach zu wenig.
Dazu gibt es Techniken wie XSL oder XSLT.
Deswegen auch das Beispiel mit dem Glossar. Glossare lassen sich ja perfekt mit XSLT erstellen; das ist genau die Stärke von XSLT.
schön und gut, aber ein Kunde muss trotzdem wissen, wie das Dokument aufgebaut ist.
Muss er das? Dann kann er ja einen schicken XML-Editor verwenden, wie X-MetaL oder so was. Und wenn er keine Angst vor spitzen Klammern hat, wird es auch Notepad tun.
Halt, ich glaube ich habe mich schlecht ausgedrückt:
Wenn ich z. B. einen SOAP-Service auf XML-basis programmiere, muss ich dem Kunden (trotz XML) eine Beschreibung des Datentyps liefern (oder ein IDL-Dokument, welches die Ein- und Ausgabe des Interfaces definiert), welcher über das XML-Interface versendet wird.
Meine Meinung:
Ob ich nun sage, dass Befehle zwischen <envelope> und </envelope> stehen und das Dokument-Tag <SOAP><REQUEST> und </REQUEST></SOAP> heisst. Oder ob ich sage: Einzelne Befehlsblöcke werden durch Leerzeilen getrennt und die Parameter werden so übergeben:
<name>=<wert>\nspielt doch keine Rolle was man anwendet. Es gibt beides etwa den selben Arbeitsaufwand. Die zweite (meine) Methode, ist aber beim parsen schneller und das Dokument kleiner. Also fragte ich mich, warum XML? - Nur dem Standard zuliebe? - Nur den anderen zuliebe? - Oder hat es soviele Vorteile, dass ich es auch mir zuliebe machen kann?
Bisher sehe ich nur den Vorteil, dass sich jeder (Kunde sowie Serviceprovider) derselben Module (XML-Parser Module) bedienen kann und somit keine Zeit verschwenden muss, um selbst einen passenden Parser für meine Formate zu schreiben.Also kann man doch gleich eine eigene Definition bringen.
soll dann der gezwungen werden, sich mit deinem INI-Format rumzuschlagen?
Ja, das ist in der Tat eine positive Kritik, welche ich mir merken werde. Aber bisher ist das der einzige Nachteil.
Viel einfacher ist es dann, wenn er eine XML-DTD hat, wo steht, wie die Daten aufgebaut sind. Da braucht er dann nur noch einen XML-Parser zum Einlesen, den ja jede moderne Programmiersprache als Modul zur Verfuegung stellt, und schwupps, schon hat er die Daten, und zwar nicht nur eingelesen, sondern auch inhaltlich strukturiert.
Wenn der Inhalt strukturiert sein soll, macht XML natürlich Sinn, denn jeder Versuch ein eigenes Format zu basteln, was diesen Anforderungen entspricht, wird wohl etwa gleich enden wie XML. XML ist einfach, logisch und strukturiert. Braucht man diese Kriterien soll man sich gleich XML bedienen. Aber für eine einfache Schnittstelle taugt ein "lineares Format", dieses muss nicht inhaltlich strukturiert sein.
Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Naja, die falsche Euphorie, die mit solchen Sachen seit jeher verbunden wird, verfliegt halt irgendwann wieder. Was dann bleibt, ist ein Standard, der sicher viele Probleme loesen wird - wenn auch nicht alle. Aber dafuer wurde er wohl auch nicht gemacht ;-)
Ja, da wirst du recht haben. In den meisten Artikeln, welche ich zu diesem Thema gelesen habe, wird XML einfach als "Gott der Datenkommunikation" dargestellt. Das mag auch stimmen, aber solange ich lebe haben wir Polytheismus!
Viele Grüsse
Philipp
-
-
Moin
Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Wenn der Datenaustausch nicht nur zwischen 2 Teilnehmern, sondern mehreren passieren soll und man auch noch Timelines einzuhalten hat, dann ist Standard schon fein. Wenn man dann auch noch Informationen aus mehreren Datenquellen auf einem Ausgabemedium (z.B. HTML Seite) zusammen präsentieren will, wird das ohne Standard nie fertig.
Man nehme: Buchtipps, WWW Links, Veranstaltungstipps, Adressen und präsentiere alle nicht als genannte Gruppen, sonder jeweils unterschiedlichen Themen zugeordnet, also alle jeweils Buchtipps, WWW Links, Veranstaltungstipps, Adressen zu Reise, zu Computer, zu Musik, oder sonstwas. Vielleicht auch noch einen Fernsehtipp? Jede Datenquelle, zb. Veranstaltungen ist aber ein anderer Datenlieferant.
Mit Standard und XSL geht das in 2-3 Monaten, ohne in 2-3 Jahren...
XML ist schon klasse, wenn man mal über den eigenen Tellerrand der eingenen Aufgaben guckt... Und wenn man dann nicht alles neu erklären muss, sondern auf eine Standarddoku verweisen kann, spart man auch noch Nerven. ;-)Beispiel siehe unten
gruss, Stefan Karzauninkat
-
Halihallo
Ich frage mich: "Ist der XML-boom gerechtfertigt? - Ist XML wirklich das Ende aller kommunikativen Probleme???" - Ich sage, dass XML überbewertet wird! - Meine Meinung, man möge mich dafür lünchen.
Wenn der Datenaustausch nicht nur zwischen 2 Teilnehmern, sondern mehreren passieren soll und man auch noch Timelines einzuhalten hat, dann ist Standard schon fein. Wenn man dann auch noch Informationen aus mehreren Datenquellen auf einem Ausgabemedium (z.B. HTML Seite) zusammen präsentieren will, wird das ohne Standard nie fertig.
Zugegeben. Ausgangslage der Diskussion waren SOAP-Anwendungen für WebServices und da fand ich die Anwendung von XML schlicht für übertrieben, performanceschluckend und speicherfressend ;)
Nein, für SOAP Anwendungen würde ein einfaches Protokol föllig ausreichen (Beispiel HTTP).Man nehme: Buchtipps, WWW Links, Veranstaltungstipps, Adressen und präsentiere alle nicht als genannte Gruppen, sonder jeweils unterschiedlichen Themen zugeordnet, also alle jeweils Buchtipps, WWW Links, Veranstaltungstipps, Adressen zu Reise, zu Computer, zu Musik, oder sonstwas. Vielleicht auch noch einen Fernsehtipp? Jede Datenquelle, zb. Veranstaltungen ist aber ein anderer Datenlieferant.
Mit Standard und XSL geht das in 2-3 Monaten, ohne in 2-3 Jahren...
Bin ich mir nicht sicher. Aber wenn die Applikation stark skalierbar sein soll, wirst du recht haben.
XML ist schon klasse, wenn man mal über den eigenen Tellerrand der eingenen Aufgaben guckt... Und wenn man dann nicht alles neu erklären muss, sondern auf eine Standarddoku verweisen kann, spart man auch noch Nerven. ;-)
Du Armer! - brauchst ja nicht zu antworten ;)
Aber ich gebe dir recht und lese mich mal durch SelfHTML 8.0, OK? ;)Grüsse
Philipp
-
Moin
XML ist schon klasse, wenn man mal über den eigenen Tellerrand der eingenen Aufgaben guckt... Und wenn man dann nicht alles neu erklären muss, sondern auf eine Standarddoku verweisen kann, spart man auch noch Nerven. ;-)
Du Armer! - brauchst ja nicht zu antworten ;)
Aber ich gebe dir recht und lese mich mal durch SelfHTML 8.0, OK? ;)Dsas kann sicher nicht schaden ;-) Auch wenn ich was ganz anderes meinte: nämlich Kooperationspartner, die vorhaben, Daten auszutauschen. Wir haben festgestellt, dass es für viele gar nicht so einfach ist, selbst einen so (relativ) simplen Standard wie XML einzhalten...
Gruss, Stefan Karzauninkat
-
Hallihallo
XML ist schon klasse, wenn man mal über den eigenen Tellerrand der eingenen Aufgaben guckt... Und wenn man dann nicht alles neu erklären muss, sondern auf eine Standarddoku verweisen kann, spart man auch noch Nerven. ;-)
Du Armer! - brauchst ja nicht zu antworten ;)
Aber ich gebe dir recht und lese mich mal durch SelfHTML 8.0, OK? ;)Dsas kann sicher nicht schaden ;-) Auch wenn ich was ganz anderes meinte: nämlich Kooperationspartner, die vorhaben, Daten auszutauschen. Wir haben festgestellt, dass es für viele gar nicht so einfach ist, selbst einen so (relativ) simplen Standard wie XML einzhalten...
Ach so, ich entschuldige mich! - Ich dachte, dass es dir leid ist immer vom selben Zeug zu reden.
Viele Grüsse
Philipp
-
-
-
-
-
-
Halihallo
Und warum habe ich diese Frage überhaupt gestellt? - Ist bestimmt wieder so ein Thema, worüber sich schon tausende unterhalten haben, oder?
Vielleicht liegt es daran, dass ich mich einfach mal outen musste. Ich mag XML nicht! - Kenne jedoch auch dessen Vorteile (und Nachteile).
Ich nehme es niemandem übel, wenn er sich zu diesem Thread nicht äussern will, da ich weiss, dass das Thema etwas überdiskutiert ist.
Viele Grüsse
Philipp
PS: Vergebt mir.
-
Hi Philipp,
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol)
programmieren, d. h. SOAP für ein Intranet und somit die Kommunikation
zwischen firmeninternen Diensten. Hab aber, frech wie ich bin,
kurzerhand XML durch ein (besseres ;) ) Format ersetzt.Nach welchen Kriterien "besser"?
Einen solchen SOAP-Dienst kann man nämlich viel einfacher umsetzen.
Etwa so wie das HTTP-Protokoll aufgebaut ist (das wurde ja noch nicht
XML-ifiziert).Was haben Protokoll und Syntax der darin verwendeten Anweisungen
miteinander zu tun?
HTTP ist m. E. vor allem eine semantische Definition, erst in zweiter
Linie eine syntaktische.Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen
von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa
40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben
etwas grösser).Ich denke, Du vermischst da mehrere Aspekte, die ich in unterschiedlichen
Ebenen ansiedeln würde - so wie beispielsweise Content-encoding eine Schale
um HTTP herum legt, um das 'platzverschwendende' Klartextformat HTML band-
breitenschonend zum HTTP-Client zu transportieren.Ich frage mich warum? - Nur dem Standard willen?
XML erlaubt es, in standardisierter Weise Formate zu definieren.
Diese Idee ist uralt - denk mal an die Backus-Naur-Form für formale
Syntaxen, an reguläre Ausdrücke oder auch an Edifact.XML geht aber viel weiter:
- Es outsourced wesentliche Aspekte wie etwa die Visualisierung der Daten
in einer ebenfalls standardisierten Weise. - Es bietet fertige APIs für die Analyse solcher Dokumente.
Was glaubt Du, wie viele Dateiformat-Parser ich schon geschrieben habe?
Es vergeht kein Monat, in dem ich nicht wieder irgend ein neues, obskures
Format vorgesetzt bekomme, das irgend jemand erfunden hat, der von XML
nichts weiß. Ohne Perl und seine regulären Ausdrücke wäre es entsetzlich.
Klar, XML-parsing-Software ist heute noch ziemlich langsam - die Last,
welche das Forum auf das Self-Portal bringt, zeigt das deutlich.
Aber für die Analyse einer 100-Zeilen-Datei nehme ich das gerne in Kauf,
wenn ich dafür nicht zum allerzweiundvierzigsten Male ein ähnliches und
doch in entscheidenden Aspekten wieder abweichendes Skript schreiben muß.Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet
erreichbar sein soll, verstehe ich den Vorteil von XMLDarum geht es mir gar nicht. Ich würde nicht in erster Linie meine CGI-
Skripte zur Generierung von HTML-Seiten ablösen. Ich würde mich gerne
mehr auf die Analyse der Semantik konzentrieren als auf die Analyse der
Syntax.Und wellformedness sicherzustellen wäre doch auch mal ein echter Fort-
schritt für unzählige Formate, für die bislang niemand einen Validator
geschrieben hat, weil es "den Aufwand nicht lohnte".
(Ich muß heute schon wieder genau so etwas bauen, weil jemand drei se-
mantisch zusammengehörige Informationsklassen in drei unterschiedlich
formatierten Dateien abgelegt hat und in deren Kommentarzeilen! erwähnt,
daß er sich darauf verläßt, daß diese drei Dateien inhaltlich zusammen
passen - geprüft wird das bisher nirgendwo, aber ich muß jetzt die Ober-
menge dieser drei Dateien in ein relationales Datenbankschema übernehmen.)aber in einem Intranet, wo man die Standards selber festlegt?
Ich weiss nicht.Deine Anwendung _mag_ ein Sonderfall sein. Aber wie sicher kannst Du Dir
sein, daß Du es nicht eines Tages irgendwo anders brauchst?
Vor allem: Wenn Du mal fit bist im Erstellen von DTDs usw., dann wird es
beim zehnten Format dieser Art schneller gehen als beim ersten.Was haltet ihr von dieser XML-ifizierung?
Man kann alles übertreiben. Aber die Idee ist so richtig, wie sie alt ist.
In Deinem Fall mag Deine Lösung tatsächlich die bessere sein ...Also ich bin ein Freund der "alten Schule".
Ich habe auch noch kein XML selbst verwendet - aber ich wäre froh, wenn
ich _nichts_ anderes mehr zu verarbeiten hätte als XML. Leider ist die
reale Welt nicht so ... noch nicht ...Viele Grüße
Michael-
Halihallo Michael
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol)
programmieren, d. h. SOAP für ein Intranet und somit die Kommunikation
zwischen firmeninternen Diensten. Hab aber, frech wie ich bin,
kurzerhand XML durch ein (besseres ;) ) Format ersetzt.Nach welchen Kriterien "besser"?
Mit "besser" meinte ich: Angepasst an die Aufgabenstellung und platzsparend (Netzwerk soll nicht gleich ausgelastet sein).
In der Aufgabenstellung beschrieben war auch das Performanceproblem. Da hab ich schon mal gute Karten mit dem eigenen Format.Einen solchen SOAP-Dienst kann man nämlich viel einfacher umsetzen.
Etwa so wie das HTTP-Protokoll aufgebaut ist (das wurde ja noch nicht
XML-ifiziert).Was haben Protokoll und Syntax der darin verwendeten Anweisungen
miteinander zu tun?
HTTP ist m. E. vor allem eine semantische Definition, erst in zweiter
Linie eine syntaktische.Ja, ich meinte die einfache, "lineare" Struktur.
Set-Cookie: ...
Server: ...
das ist ja eigentlich nichts anderes als ein assoziatives Array (oder Hash). Genau das brachte ich eben für meinen SOAP-Dienst.
Mir ist klar (das habe ich auch im Posting zu Stefans Post geschrieben), dass XML Sinn macht, wenn das Datenset nicht mehr so einfach ist.Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen
von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa
40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben
etwas grösser).Ich denke, Du vermischst da mehrere Aspekte, die ich in unterschiedlichen
Ebenen ansiedeln würde - so wie beispielsweise Content-encoding eine Schale
um HTTP herum legt, um das 'platzverschwendende' Klartextformat HTML band-
breitenschonend zum HTTP-Client zu transportieren.Kannst du diese Analogie etwas anders formulieren? - Ich habe die Aussage nicht mitbekommen. Was willst du mir damit sagen? - Content-Encoding steigert die Bandbreite. Was sprichst du von bandbreitenschonend?
Ich frage mich warum? - Nur dem Standard willen?
XML erlaubt es, in standardisierter Weise Formate zu definieren.
Diese Idee ist uralt - denk mal an die Backus-Naur-Form für formale
Syntaxen, an reguläre Ausdrücke oder auch an Edifact.Das ist auch lobenswert! - Die Idee gefällt mir auch, nur sehe ich nicht's göttliches hinter XML ;)
- Es bietet fertige APIs für die Analyse solcher Dokumente.
Was glaubt Du, wie viele Dateiformat-Parser ich schon geschrieben habe?
Es vergeht kein Monat, in dem ich nicht wieder irgend ein neues, obskures
Format vorgesetzt bekomme, das irgend jemand erfunden hat, der von XML
nichts weiß. Ohne Perl und seine regulären Ausdrücke wäre es entsetzlich.
;)
Ja, da hast du recht.
b.t.w : Mein Mitgefühl ;)
Ich habe das Glück, dass ich eben der bin, welcher eigene Formate definiert, mit denen du dich dann beschäftigen darfst ;)
Aber keine Sorge: Bei mir geht's _immer_ ohne reguläre Ausdrücke!Klar, XML-parsing-Software ist heute noch ziemlich langsam - die Last,
welche das Forum auf das Self-Portal bringt, zeigt das deutlich.Ich mag mich an die Diskussion erinnern, ja.
Aber für die Analyse einer 100-Zeilen-Datei nehme ich das gerne in Kauf,
wenn ich dafür nicht zum allerzweiundvierzigsten Male ein ähnliches und
doch in entscheidenden Aspekten wieder abweichendes Skript schreiben muß.Ja und nein. Aber ich stimme dir eher zu ;)
Es entsteht schon eine gewisse Redundanz, wenn man eigene Formate entwirft. Redundanz in dem Sinne, dass man das selbe immer wieder auf eine andere Weise implementiert.Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet
erreichbar sein soll, verstehe ich den Vorteil von XMLDarum geht es mir gar nicht. Ich würde nicht in erster Linie meine CGI-
Skripte zur Generierung von HTML-Seiten ablösen. Ich würde mich gerne
mehr auf die Analyse der Semantik konzentrieren als auf die Analyse der
Syntax.Das ist eine neue Sichtweise für mich. Aus dieser Perspektive habe ich noch nie überlegt.
[...Analyse der Semantik...]
Wie gesagt, ist dies für mich eine neue Perspektive des Problems. Bisher hat sich mir nie das Problem gestellt, dass eine Datei nicht meiner Semantik entsprach, da dafür genaue Definitionen vorlagen. Deshalb machte auch ein Validator keinen Sinn.
Man muss sich eben an die Vorgaben halten, dann ist ja alles OK, nicht?aber in einem Intranet, wo man die Standards selber festlegt?
Ich weiss nicht.Deine Anwendung _mag_ ein Sonderfall sein. Aber wie sicher kannst Du Dir
sein, daß Du es nicht eines Tages irgendwo anders brauchst?
Vor allem: Wenn Du mal fit bist im Erstellen von DTDs usw., dann wird es
beim zehnten Format dieser Art schneller gehen als beim ersten.Nun, wie mir scheint, fehlt mir einfach die Praxis. Ich denke, dass sich meine Meinung zu XML ziemlich grundlegend ändern könnte, wenn ich diese Technik endlich verstehen würde. Ich muss mich einfach mal dahinter setzen und mir diese Parser vornehmen. Ich meine, das grobe (Grundidee und alles Grundlegende) an XML habe ich ja verstanden, nur an der Umsetzung habe ich noch Schwierigkeiten.
Viele Grüsse
Philipp
PS: Danke für die neue "Perspektive"/Sichtweise
-
Hi Philipp,
Content-Encoding steigert die Bandbreite.
Was sprichst du von bandbreitenschonend?Das, was es diesem Forum hier ermöglicht, die HTML-Seiten um Faktor 10 komprimiert an die Clients zu übertragen, ist eine Realisierung von "Content-Encoding: gzip".
Und so eine Schale kannst Du natürlich um jedes eigene Format drum herum legen.
Performante Übertragung gehört für mich in eine tiefere Protokoll-Schicht (4-5?) als Semantik (6).Viele Grüße
Michael-
Hallo Michael,
Performante Übertragung gehört für mich in eine tiefere Protokoll-Schicht (4-5?) als Semantik (6).
Ach, die guten, alten 7 Schichten ... da kommt Nostalgie auf an Umschulungsunterrichtsstunden vor zwoelf Jahren, wo man versuchte, uns die Grundlagen des Internet beizubringen. Der Dozent ritt immerzu auf diesen 7 Schichten rum, aber wir konnten ihm nicht so recht folgen dabei, was den daran so wichtig und toll sei, dass man diese Schichten unterscheidet. Es kam uns eher vor wie ein nachtraeglich aufgepfropftes philosophisches Erklaerungsmodell fuer das Wirrwarr an Datenuebertragungsprotokollen, die man da gleichzeitig im Einsatz hatte.
Heute denkt glaube ich kaum einer in der Praxis an den Sinn dieser Schichten. Ich waere jedenfalls nie auf die Idee gekommen, beim Gedanken an Bandbreiteneinsparung daran zu denken, auf welcher dieser Schichten dies am besten zu geschehen habe ... ein interessanter Gedankenanstoss!
viele Gruesse
Stefan Muenz-
Hi Stefan,
Performante Übertragung gehört für mich in eine tiefere
Protokoll-Schicht (4-5?) als Semantik (6).
Ach, die guten, alten 7 Schichten ... da kommt Nostalgie auf an
Umschulungsunterrichtsstunden vor zwoelf Jahren, wo man versuchte,
uns die Grundlagen des Internet beizubringen.Ich habe das nie richtig gelernt, weil ich Informatiker bin und kein
Kommunikationsmensch.
Aber im Engineering schnappt man das halt so nebenbei mit auf ...Die erste Aufgabe in meinem Berufsleben in der freien Wirtschaft bestand
übrigens darin, ein Komprimierungsverfahren auf ein bewußt lesbar, also
"sperrig" definiertes Klartext-Format oben drauf zu setzen ... und wir
brauchten ein proprietäres Verfahren, weil es unsere umfangreichen, aber
ziemlich einseitigen Daten sehr spezifisch komprimieren sollte, auf meh-
reren Plattformen gebraucht wurde und noch dazu nicht beliebige Bitmuster
erzeugen durfte - die Daten mußten nämlich über eine X.25-Leitung laufen,
welche einige spezielle Bytes als Steuerzeichen interpretierte ... diese
mußten also explizit ausgespart bleiben bei der Codierung.Der Dozent ritt immerzu auf diesen 7 Schichten rum, aber wir konnten
ihm nicht so recht folgen dabei, was den daran so wichtig und toll
sei, dass man diese Schichten unterscheidet.
Es kam uns eher vor wie ein nachtraeglich aufgepfropftes philosophisches
Erklaerungsmodell fuer das Wirrwarr an Datenuebertragungsprotokollen,
die man da gleichzeitig im Einsatz hatte.Umgekehrt geht es mir bei den verschiedenen Tools der XML-und-Konsorten-
Welt genauso - ich verliere völlig den Überblick, wer da wofür zuständig
ist. (Vielleicht sollte ich langsam mal SelfHTML 8.0 lesen ... ;-)Heute denkt glaube ich kaum einer in der Praxis an den Sinn dieser
Schichten. Ich waere jedenfalls nie auf die Idee gekommen, beim
Gedanken an Bandbreiteneinsparung daran zu denken, auf welcher dieser
Schichten dies am besten zu geschehen habe ...Dabei liegt beiden dieselbe Idee zugrunde: "Teile und herrsche" - eines
der Informatiker-Credos.
Im Klartext: Lasse denjenigen eine Aufgabe erledigen, der dafür kompetent
ist - und vermeide es, dieselbe Aufgabe immer wieder zu lösen.Code reuse ist letztlich auch nur eine Ausprägung derselben Idee.
Viele Grüße
Michael-
Halihallo
Performante Übertragung gehört für mich in eine tiefere
Protokoll-Schicht (4-5?) als Semantik (6).
Ach, die guten, alten 7 Schichten ... da kommt Nostalgie auf an
Umschulungsunterrichtsstunden vor zwoelf Jahren, wo man versuchte,
uns die Grundlagen des Internet beizubringen.Ich habe das nie richtig gelernt, weil ich Informatiker bin und kein
Kommunikationsmensch.
Aber im Engineering schnappt man das halt so nebenbei mit auf ...Sprecht ihr da von diesem OSI Zeugs? ;)
Ja, davon habe ich nix mehr gehört seit ...
Na, ja, interessiert wohl wirklich niemanden mehr ;)[...]
Umgekehrt geht es mir bei den verschiedenen Tools der XML-und-Konsorten-
Welt genauso - ich verliere völlig den Überblick, wer da wofür zuständig
ist. (Vielleicht sollte ich langsam mal SelfHTML 8.0 lesen ... ;-)Ich haub auch den Überblick verloren, da ich den Anschluss irgendwie verpasst habe. Ich denke, dass ich auch mal in SelfHTML 8.0 nachlese. Die Lösung ist ja oft näher als man denkt...
Viele Grüsse
Philipp
-
Hallo,
Ich haub auch den Überblick verloren, da ich den Anschluss irgendwie verpasst habe. Ich denke, dass ich auch mal in SelfHTML 8.0 nachlese. Die Lösung ist ja oft näher als man denkt...
Das ist auch leicht geschehen bei den ganzen XML-Standards, die zur Zeit kursieren. Aber wer da behauptet den Überblick zu haben, der ist entweder ein Lügner oder er liest wahrscheinlich XML-Standards wie andere Harry-Potter-Romane oder den Herrn der Ringe ;-)
Gruß
Franz-
Hallo Franz,
Standards wie andere den Herrn der Ringe ;-)
Naaaaa!!! ;-)
Nix da ... ich lese den Roman mal wieder (jetzt auf ungarisch) das 2. Buch liegt geöffnet direkt hier neben der Tastatur gleich auf dem geöffneten XSLT Buch vom Michael Kay.
Und ich finde biede spannend. ;-)
Grüße
Thomas-
Hallo Thomas,
Nix da ... ich lese den Roman mal wieder (jetzt auf ungarisch) das 2. Buch liegt geöffnet direkt hier neben der Tastatur gleich auf dem geöffneten XSLT Buch vom Michael Kay.
Wie, du liest Sekundärliteratur zu XML? Ich halte mich streng an die Orginale. Was weiss der Kay den schon. Seit der bei der Software AG ist und alleiniger Herausgeber von XSLT 2.0 spielt der sich auch nur noch auf ;-)
Und ich finde biede spannend. ;-)
Ja, habe die drei Bände auch nochmal zur Weihnachtszeit verschlungen. Einen Band auf englisch. Aber dann ging mir das zu langsam... Schön, war's. Aber jetzt lese ich bis Weihnachten nur noch Standard, ehrlich.
Gruß
Franz
-
-
-
-
-
-
Halihallo
Content-Encoding steigert die Bandbreite.
Was sprichst du von bandbreitenschonend?Das, was es diesem Forum hier ermöglicht, die HTML-Seiten um Faktor 10 komprimiert an die Clients zu übertragen, ist eine Realisierung von "Content-Encoding: gzip".
Ui, sorry, ich dachte irgendwie an base64 oder quoted-printable o. ä. Entschuldige, ja logisch mit gzip wird die Bandbreite natürlich kleiner.
'tschuldigung
Philipp
-
-
Hallo Philipp
das ist ja eigentlich nichts anderes als ein assoziatives Array (oder Hash). Genau das brachte ich eben für meinen SOAP-Dienst.
Das kann ich nachvollziehen, was du da mit "linear" bezeichnest. So ging es mir neulich naemlich auch. Ich brauchte fuer ein CGI-Script Konfigdaten und ueberlegte, ob ich diese in einer XML-Datei sammeln sollte. Aber es waren wirklich nur simple name-value-Daten ohne weitere Hierarchie-Ebene, wie geschaffen zum Einlesen in einen Hash. Und da habe ich mich dann auch fuer die simple Form entschieden.
Anderes wird es halt, sobald eine Hierarchie-Ebene dazukommt (in den alten Windows-INI-Dateien gabs ja z.B. diese Sektionsueberschriften in eckigen Klammern). genau da, wo man mit solchen Kruecken anfangen muss, sollte man dann doch besser zu XML greifen. Die Stringverarbeitung beim Auseinanderfieseln besorgt der als Modul eingebundene XML-Parser, so dass du dich - wie es Michael ausdrueckt - ganz auf die semantische Seite der eingelesenen Daten konzentrieren kannst.
viele Gruesse
Stefan Muenz-
Hi Stefan,
Die Stringverarbeitung beim Auseinanderfieseln besorgt der als
Modul eingebundene XML-Parser, so dass du dich - wie es Michael
ausdrueckt - ganz auf die semantische Seite der eingelesenen
Daten konzentrieren kannst.um es in einem Satz zu sagen: Ich möchte XML aus demselben Grund verwenden,
aus dem ich auch "use CGI;" verwende.Mich interessiert einfach nicht, in welchem Format die Daten übertragen
wurden, wenn meine Aufgabe darin besteht, ihren Inhalt zu verstehen.Viele Grüße
Michael-
Halihallo
Die Stringverarbeitung beim Auseinanderfieseln besorgt der als
Modul eingebundene XML-Parser, so dass du dich - wie es Michael
ausdrueckt - ganz auf die semantische Seite der eingelesenen
Daten konzentrieren kannst.um es in einem Satz zu sagen: Ich möchte XML aus demselben Grund verwenden,
aus dem ich auch "use CGI;" verwende.Mich interessiert einfach nicht, in welchem Format die Daten übertragen
wurden, wenn meine Aufgabe darin besteht, ihren Inhalt zu verstehen.Na da seh ich doch was altbekanntes:
Das ist ja das selbe Thema wie : "Was nehme ich lieber, das gute alte Notepad.exe-Programm, oder WYSISYG-Editor".
Erstere (z. B. ich) sagen: Ich will wissen, was der Computer macht und nehme mir auch gerne einige Minütchen Zeit dafür. Letztere sagen: Interessiert mich alles nicht bzw. ich weiss ja wie's funktioniert, also wieso nicht wegen zeitersparnis den WYSIWYG benutzen?Hier gibt's wohl und wird's immer geben - zwei Meinungen, von welcher jede Seite Vor- und Nachteile hat.
Viele Grüsse
Philipp
-
Hi Philipp,
Mich interessiert einfach nicht, in welchem Format die Daten übertragen
wurden, wenn meine Aufgabe darin besteht, ihren Inhalt zu verstehen.
Das ist ja das selbe Thema wie : "Was nehme ich lieber, das gute alte Notepad.exe-Programm, oder WYSISYG-Editor".Nein, überhaupt nicht. Beide befassen sich mit der Form, also der Syntax
bzw. der Darstellung.Die passende Analogie wäre:
"Nehme ich Notepad oder doch lieber ein Content Management System?"Viele Grüße
Michael
-
-
-
Halihallo
Das kann ich nachvollziehen, was du da mit "linear" bezeichnest. So ging es mir neulich naemlich auch. Ich brauchte fuer ein CGI-Script Konfigdaten und ueberlegte, ob ich diese in einer XML-Datei sammeln sollte. Aber es waren wirklich nur simple name-value-Daten ohne weitere Hierarchie-Ebene, wie geschaffen zum Einlesen in einen Hash. Und da habe ich mich dann auch fuer die simple Form entschieden.
Genau diese Art von Daten werden eben in einem SOAP Dienst verwendet. Deshalb (und jetzt sind wir wieder am Anfang des Threads) halte ich XML für übertrieben (für diese Anwendung). Aber ich denke hier sind wir uns alle einig.
Anderes wird es halt, sobald eine Hierarchie-Ebene dazukommt (in den alten Windows-INI-Dateien gabs ja z.B. diese Sektionsueberschriften in eckigen Klammern). genau da, wo man mit solchen Kruecken anfangen muss, sollte man dann doch besser zu XML greifen.
Ja, da _muss_ ich dir recht geben.
Viele Grüsse
Philipp
-
- Es bietet fertige APIs für die Analyse solcher Dokumente.
- Es outsourced wesentliche Aspekte wie etwa die Visualisierung der Daten
-
Hallo,
Ich frage mich warum? - Nur dem Standard willen?
Ja, genau darum.
Der XML-Hype hat eben auch den Vorteil, dass man nicht alle 2 Minuten ein neues Format zur Repräsentation von Daten erfinden muss.Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet erreichbar sein soll, verstehe ich den Vorteil von XML, aber in einem Intranet, wo man die Standards selber festlegt?
Auch dort. Schon bei mittelgroßen Firmen sind unterschiedliche Formate unterschiedlicher Systeme, die eigentlich zusammenarbeiten sollten/könnten ein Problem.
Erst recht im Austausch zwischen Firmen. Der "neue" Hype bei XML ist doch genau in diesem Bereich zu suchen. Klar trennt XML Datenhaltung von der Darstellung, aber es ist eben auch ein standardisiertes integratives Datenformat. Die Software zur Verarbeitung ist Open-Source, es gibt mittlerweile ein verbreitetes Know-How in der Verarbeitung von XML-Dateien usw.
Klar ist XML kein Allheilmittel, auf die DTD/das Schema der auszutauschenden Daten bzw. aufzurufenden Services muss man sich immer noch einigen. Aber auch da geht die Entwicklung eindeutig Richtung Standards(s. Web-Services, WSDL, UDDI, SOAP)."Negative" Aspekte darf man natürlich auch nicht verschweigen, z.B. die immer komplizierter werdenden Standards in der XML-Welt und der Versuch alles zu XMLisieren. Aber es ist eben eine Illusion, das in der IT-Welt irgendetwas, was mal einfach begann einfach bleibt. Das zeigt sich schon an HTML.
Also ich bin ein Freund der "alten Schule".
Na, hindert dich ja keiner daran.
Trotzdem ist aber der Standpunkt auch aus deinen anderen Postings etwas eigenartig. Du siehst die Vorteile von XML, machts aber lieber deinen eigenen Kram, kapiere ich nicht.Wieso nutzt du nicht einfach XML, wenn es einen Job gibt, bei dem es passt, und ansonsten nimmst du halt CSV-Files, wenn du keine Struktur benötigst oder davon ausgehen kannst, dass deine Daten aus dem Intranet, niemals ins Extranet gehen?
Gruß
Franz-
Halihallo
Ich frage mich warum? - Nur dem Standard willen?
Der XML-Hype hat eben auch den Vorteil, dass man nicht alle 2 Minuten ein neues Format zur Repräsentation von Daten erfinden muss.
OK. So weit bin ich einverstanden ;)
Klar, im Falle eines outsourcings, d. h. wenn der Dienst über Internet erreichbar sein soll, verstehe ich den Vorteil von XML, aber in einem Intranet, wo man die Standards selber festlegt?
Auch dort. Schon bei mittelgroßen Firmen sind unterschiedliche Formate unterschiedlicher Systeme, die eigentlich zusammenarbeiten sollten/könnten ein Problem.
Genau dafür wurde ja SOAP entwickelt. Nur, dass ich XML für diesen Dienst etwas übertrieben finde (das war ja der Ursprung des Threads).
Also ich bin ein Freund der "alten Schule".
Na, hindert dich ja keiner daran.
Trotzdem ist aber der Standpunkt auch aus deinen anderen Postings etwas eigenartig. Du siehst die Vorteile von XML, machts aber lieber deinen eigenen Kram, kapiere ich nicht.Ich sehe das Wiedersprüchliche. Es ist eine komplizierte Mischung aus nostalgischen Gefühlen und optimaler Lösung (für meine Dienste war XML eben nicht optimal)
Wieso nutzt du nicht einfach XML, wenn es einen Job gibt, bei dem es passt, und ansonsten nimmst du halt CSV-Files, wenn du keine Struktur benötigst oder davon ausgehen kannst, dass deine Daten aus dem Intranet, niemals ins Extranet gehen?
Wie gesagt: Ich komme noch in die Umgewöhnungsphase ;)
Hast ja recht, bisher hat's eben nur sehr gut ohne funktioniert.Viele Grüsse
Philipp
-
-
Hallo Philipp,
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol) programmieren, ...
Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa 40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben etwas grösser).SOAP ist tot, es lebe AXIS. ;-)
Was haltet ihr von dieser XML-ifizierung?
finde ich ok.
was ich aber absolut nicht ausstehen kann, ist dass jetzt (wieder, oder erst recht) für jedes ding was es nur gibt java genommen wird. java hier java da, java überall. man nimmt sogar eine xml datei liest sie als java objekte ein und gibt sie dann per jsp wieer aus. wiederlich. wirklich. ;-)
grüße
thomas-
Hallo Thomas,
man nimmt sogar eine xml datei liest sie als java objekte ein und gibt sie dann per jsp wieer aus. wiederlich. wirklich. ;-)
Wer ist man? Du wirst dich doch nicht plötzlich mit ernstzunehmenden Programmiersprachen beschäftigen *fg*
Wen "man" die Java-Objekte dann verwendet oder manipuliert (sinnvol natürlich ;-)) dann ist das sinnvoll. Wenn nicht, ist es wirklich nutzlos.
Gruß
Franz-
Hallo Franz,
man nimmt sogar eine xml datei liest sie als java objekte ein und gibt sie dann per jsp wieer aus. wiederlich. wirklich. ;-)
Wer ist man? Du wirst dich doch nicht plötzlich mit ernstzunehmenden Programmiersprachen beschäftigen *fg*
nein. ich und java, nicht doch! ;-)
Grüße
Thomas
-
-
Halihallo
Ich musste mal einen SOAP-Dienst (Simple Object Access Protocol) programmieren, ...
Ich frage mich einfach: WARUM XML??? - Das verschlingt doch nur unmengen von Serverperformance und die Netzwerkaktivität nahm ebenfalls um etwa 40% zu, als ich das ganze mal mit XML versuchte (XML-Dateien sind eben etwas grösser).SOAP ist tot, es lebe AXIS. ;-)
Oh, kenne ich nicht. Muss mich mal informieren.
Was haltet ihr von dieser XML-ifizierung?
finde ich ok.
was ich aber absolut nicht ausstehen kann, ist dass jetzt (wieder, oder erst recht) für jedes ding was es nur gibt java genommen wird. java hier java da, java überall. man nimmt sogar eine xml datei liest sie als java objekte ein und gibt sie dann per jsp wieer aus. wiederlich. wirklich. ;-)
Kann ich gut verstehen. Java hier und Java dort... Ich konnte mich bisher auch noch nicht damit anfreunden.
Viele Grüsse
Philipp
-