This discussion has been very useful. Thank you!

Jim Murphy of MindReef/SOAPScope said:
>What that means to me is that SOAP is the ... tags that allow service
>designers to put application stuff in one bucket (soap:Body) and keep
>that separate from non-functional stuff that goes in Headers.

I agreed. But while I like the idea of SOAP headers, I don't have
anything standard to put in them. Web services security is a debacle;
there's still no standard tag for me to put authentication tokens in a
SOAP header. And cleverer stuff like WS-Routing hasn't gone anywhere.

My other problem with the document view is that we lose the interop.
It was a magic moment for me when I could declare (in Java) a server
function that returned a struct with an array of structs with complex
nested data, and then a client (in Perl, .NET, whatever) could just
parse it and return the data to the programmer in meaningful client
data objects. I've seen this actually work, in practice, for thousands
of client programmers.

I guess in theory XML Schema is enough for the clients to do the magic
parsing, but in practice it doesn't seem to work so well. I love this
clarification to WS-I BP1.0a:
  http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0-errata-1.htm

  R2110, R2111, R2112, and R2113 restricts array descriptions. This is
  confusing and untestable as the concept of "array" is alien to XML
  Schema 

So, um, if XML Schema doesn't have arrays, how am I supposed to pass
an array in a document/literal service?


I'm ranting a bit here, I'm sure in practice things work better than
the picture looks in the abstract. Only when I write web services code
I usually find the picture is *worse* in practice as I sweat through
the minutae of interop in a dozen different languages.


>I'm just starting to blog about that!

Nice! http://www.mindreef.com/people/jimmurphy/weblog/

Is there a list of Axis-friendly blogs? Good web services blogs?

Reply via email to