[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Date | Thread | Author

[XML-SIG] WSDL library ?

paul@boddie.net wrote:
>> When asked to investigate SOAP, one of the apparent advantages I found for
>> those who have already invested in XML data exchange representations is that it
>> seems to be possible to just drop the usual XML instances inside a SOAP
>> envelope and use largely the tools you already have to deconstruct those
>> instances later.     (01)

More or less. But there are lots of details you may have to worry about.
Some of them your SOAP toolkit will handle, but others it will not. For
instance if you have a hyperlink from one part of your document to
another of the form xpath="/", should you rewrite it (the document's
root element is no longer THE root element) before putting it in the
SOAP message or not? SOAP doesn't really tell you. Heretical though it
is, I'd say it is safer to NOT embed XML in SOAP. Either use separate
MIME parts or use a protective level of encoding like base64.    (02)

> ... For people who aren't strictly interested in converting their
>> data to RPC-like calls, SOAP provides the messaging infrastructure, in theory,
>> whilst the interpretation of the data is left to the application.    (03)

HTTP or SMTP or whatever provides the messaging infrastructure. SOAP
provides...a secondary level of envelope?    (04)

> Personally, I think the obsession with making everything an object, so that one
>> can receive RPC messages or access relational databases by pulling objects out
>> of a hat and calling setFamilyName on them (for example), is somewhat tiresome
>> and not always particularly necessary.     (05)

Some of us would argue hardly ever necessary.    (06)

> ... In other words, I think that there are
>> benefits to just receiving an XML document, rather than having to stuff such
>> data into an object hierarchy.    (07)

I think you'll find quite a bit of agreement on that point.    (08)

 Paul Prescod    (09)