XML over XML, avagy miért XML-t küldenek string-ként SOAP-on?

Miután már nem az első olyan SOAP service-al találkozok, ahol a kért/visszaadott adat string, és az egy XML Dokumentumot tartalmaz, most már tényleg kezd érdekelni, hogy mi ennek az oka.

SOAP-on keresztül lehetőség van komplexebb osztályhierarchiák átadására, így meg lehet szívni az XML értelmezésével, validálásával. Ezen kívül azt sem értem, hogy ha egyszer úgy is egy-egy XML document vándorol ide-oda, akkor minek a SOAP keret?

Tudja valaki, hogy miért használják egy csomó helyen ezt a megoldást?

Hozzászólások

Tipikusan akkor van ez, amikor 1. rossz a tervezes, 2. legacy rendszert kell nem legacy rendszerekkel integralni, ahol a legacy rendszer egy XML-t kop ki magabol, de nem tud SOAP-ul, viszont a kliensek SOAP-on keresztul varjak az inputot. Ekkor ez a legfavagobb, de legbiztosabban mukodo megoldas: a legacy XML-t beburkoljuk egy SOAP boritekba, es kesz.

Nem tudok rájönni, hogy hogyan lenne megoldható kevesebb kódból az, hogy neked még kell generálnod egy XML-t (ahelyett, hogy helyből az objektumod/objektumfád tolod le), amelyet a túloldalon be kell parseolni (ahelyett, hogy a SOAP lib megtenné magától és gyakorlatilag ugyanazt az objektumot kapnád meg, mint amely a túloldalon elindult.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mert az ellenoldali fel nem objektumban gondolkodik, csak aki fogadja az uzenetet. Az ellenoldali felnek az kell, hogy egy tetszoleges legacy rendszer altal kikopott XML-t egy SOAP-ot beszelo kliens szamara megehetove tegyen. Es ezt igy csinaljak. Az a kliens dolga, hogy az uzenetet hogyan dolgozza fel. Persze meg lehet szepen is csinalni, csak az joval tobb penzbe kerul. Foleg egy legacy rendszert nem fognak felokositani, mert az NAGYON sok penzbe kerul.

Soap, hogy jobban csússzon. Vagy csak soap-atnak mindenkit. :)