Hi,
hast Du mal mit VS einen SOAP server geschrieben?
nein, aber ich habe mit Kunden gesprochen, die mit unseren Servern kommunizieren wollten.
und da gab es Probleme.
die man immer hat, wenn man es mit einem vielen Recht machen möchte. In einem anderen Projekt mussten unsere Partner Daten in einem CSV-Format hinter einer URL bereitstellen. Was man bei einer so einfachen Aufgabe alles erlebt ... von wirrsten CSV-Versuchen über Excel- und XML-Daten bis hin zu einem Frameset(!), in dem sich irgendwo ein Link(!) auf die CSV-Ressource befand.
PHP- oder Perlclients moeglicherweise.
Nein, nicht die verwendete Technik ist verantwortlich. Frei nach Men in Black: Menschen sind intelligent. Die Leute aber sind dumm. Wenn mehr als ein, zwei, vielleicht drei Partner etwas machen müssen, kommen die unglaublichsten Ergebnisse bei raus - garantiert.
Nicht SOAP folgende, aber XML sprechende Server sind natuerlich auch OK.
Klar. SOAP bietet Vorteile bei der Schnittstelle; aber wenn die Funktionsvielfalt minimal ist und man nur wenig Dynamik in den Requests zu erwarten hat (also jeder für sich immer nur das gleiche macht), ist es eine gigantische Fehlerquelle ohne einen sichtbaren Nutzen. Sofern also die Vorteile in die Marginalität bzw. Potenzialität abrutschen, würde ich definitiv darauf verzichten. HTTP mit den reinen Nutzdaten - egal ob XML, CSV oder was immer - reicht oft völlig aus.
Ich habe da, huestl, Erfahrung, huestl.
*g* Wir alle, Ludger, wir alle :-)
Cheatah
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes