Dave Orchard’s most recent post states that I mistakingly conflated SOAP and XML Schema in my InfoQ interview. Specifically where I note that SOAP endpoints tend to blow up when the messages aren’t constructed exactly as expected. Dave says that what I call a SOAP issue is really an XML Schema issue. I tried to comment on his blog, but after more than 24 hours the comment hasn’t made it through moderation, so I’ll comment here instead.
First, I don’t think I conflated anything. At that point in the interview I was talking about XML Schema (as used by WSDL). More accurately I was talking about how SOAP toolkits make use of WSDL and Schema information. But even if I had confused SOAP and XSD, what difference would it make when the WS-I Basic Profile “mandates the use of XML Schema as the type system for WSDL descriptions of Web Services?” (Emphasis mine.) And, yes, I know that SOAP doesn’t mandate the use of WSDL, but the Basic Profile does.
But really, this is not a failing of SOAP or WSDL or XML Schema. I can have a WSDL/XSD described SOAP service that doesn’t suffer from the problem of being too brittle. All I have to do is not use any of the SOAP platforms currently available Update: WCF excepted. (Axis 2 might be excepted too, must check). It’s the tools, that on receipt of a message try to serialize it into an object, that cause this problem. As I said in the interview, “this style of SOAP development reinforces the SOAP as RPC/distributed-component/serialized-object perspective and relegates XML to just another serialization framework.
Dave goes on to state that I’m also mistaken in my assertion that SOAP web services are too tightly coupled, and links to Dan Pritchett’s post along the same lines. But I’ve already answered that, and I stand by my claim.
{ 7 } Comments
Sorry about the problem with comments on my blog. I’ve been having terrible problems with comment spam on my blog over the past 2 years. I just installed MT 3.33 and I’ve had 250 junk comment spam in the past 2 days - and MT thought yours was one. That brings me down to only say, 1 good comment and 15 junk comments that made it through. I did find your comment and approve it.
On to the specifics of your point. I think if you mean the current WS-* stack has a problem with extensibility and versioning, that’s what you should say. And in fact, I’d totally agree with you there. I’ve regularly flailed Schema 1.0 for it’s ext/vers difficulties.
But that is NOT a SOAP problem. And in fact, SOAP can even help you get around some of the Schema 1.0 problems because you can add in ignorable content. I will say that I bear considerable scars from trying to get the ability to specify optional soap headers in WSDL 2.0, and I’m still not pleased with the result.
The point is, when you are goring the ox, gore the right one. Schema 1.0 is terrible at ext/vers. Blame that, not SOAP. FWIW, Schema 1.1 is *way way* better, and even has stuff that RelaxNG doesn’t have. Now whether we actually move to Schema 1.1 is a separate, though very important question.
I decided to be part of the solution rather than the problem and I’ve spent a fair amount of time on XML Schema WG working solely on ext/vers. One of things I’ve done is author the guide to versioning using Schema 1.1 (http://www.w3.org/TR/xmlschema-guide2versioning/) to specifically show how much better Schema 1.1 is. Note, there is a December update to the guide that is much more complete, but the WG hasn’t had the chance to approve it for publication fwiw.
As for web sites that use Schema 1.0, most of them do NOT say the equivalent of “use this schema type but allow extensibility everywhere”. They actually say “this IS the schema type”. So they are in the same boat as the WS-* camp. Either you can add stuff in, or not. ’nuff said.
Dave: Okay, now I get where you’re coming from. And it’s certainly true that XML Schema has issues with extensibility and versioning (as you well know). But it really looks like we’re discussing two sides of the same coin: XSD extensibility and how SOAP toolkits use XSD. I submit that even if XSD was perfect and the schema properly extensible, that the SOAP toolkits, as currently architected, would still fail due to their tendency to take a code-first approach to service development. Even when a toolkit and a developer are thoughtful enough to take extensibility into account at the object level, there are enough restrictions to make success problematic. It seems to me that a better solution is to not incorporate any schema information into your code (dynamically or statically), but to simply reach into the message for the elements you require, and ignore everything else.
However, you make a great point. And I accept that if a web service is conscientiously developed to be extensible, it can be made more resilient to change.
Pete,
For what it’s worth, WCF users often leverage the XML (infoset) directly without going through any sort of deserialization.
Deserialization to statically typed values/objects is an optional feature and often isn’t the right approach for a variety of reasons.
Also, you can write some pretty interesting WCF code using just our Message and XLinq as your programming model. If/when Mike Champion gives us a .NET-based XQuery implementation, you could use that too
And FWIW, all of this is orthogonal to whether you use SOAP or POX.
Granted, a lot of folks are addicted to the WSDLXSD->Java/C# translation tools, which I agree could be better.
Cheers,
DB
PS: Fantastic blog - keep up the great work!!
Don: The more you comment, the more I’m intrigued by WCF. (Confession: bigotted Unix user since 1987.) Prompted by this comment, I googled up this: Serialization in Windows Communication Foundation. Lucid and cool.
I’m glad that serializing directly to objects is readily avoidable in WCF and that people are taking advantage of it That’s exactly what I advocate when processing XML messages. SOAP or not.
For the record, you can, of course, get to the raw XML with most any web service platform. Whether this is as easy to do as not and whether things like XPath and XSLT are available is the differentiator. Bully for WCF.
Axis2 has Axiom, an XML dom that is “soap centric”, and uses a pull model for demand parsing. Elliote Harold has expressed some concerns about whether the DOM makes it easy to create invalid XML; I worry more about integrating it with existing XML. I used to convert it to and from Xom graphs, but by serializing and parsing again, which sucks.
My little Alpine SOAP stack (not recommended for other people yet) is pure Xom based; very lightweight, xpath is the way for navigating content. I need to write up the experiences. To summarise: interop with “legacy” stacks still hurts, and its really painful creating and navigating XML graphs in languages like Java that do not (yet) treat lists and graphs as native data types.
You’ve eliminated one O/X mapping problem -going to and from WSDL-generated classes, and left building the messages by hand. Parsing with xpath is easier, but client side is hard work.
One of the nice things about the stack is its tiny. Apart from the WS-Addressing stuff, its only about 30 (small) classes, instead of the nightmare that is axis, a nightmare that comes from code to generate java source from WSDL and the like.
-Steve
Pete: An astonishingly small amount of the indigo code base or feature set is dedicated to serialization.
A significant chunk of our engineering dollars were dedicated either to performance and/or security, all of which lives below the serialization stacks (yes, we have two :-)).
DB
1) Document-literal, always.
2) Schema validation, never.
3) Forwardly-compatible versioning.
Why is this so hard? Is everyone too mesmerized by all the vendor breakage to think it though in the abstract?
Post a Comment