Philosophical Split Hurts Web Services Adoption

Avidwriter writes "'There is a serious split in Web services implementation philosophy that is threatening to stall the benefits of the technology to businesses and consumers,' says this Devchannel story. 'The WSDL 1.1 specification allows programmers to choose between remote procedure call (RPC) style and document-style Web services. The decision is not an arbitrary one, as it has ramifications for both message structure and more importantly the interoperability of Web services...'"

Comments

Of course it's a problem...

[mike_sucks]

... RPC-style "web" services such as SOAP and XML-RPC should not be an option. They're contrary to the architecture to the Web. If anything, they should be called RPC over HTTP or something similar, because that is all they have in common with the Web.

If you want to do a real Web service, use REST.

Little summary and comment

[jsse]

The author stated his stance in the very first paragraph:

For example, it is incorrect to assume that a request-response programming model dictates an RPC-style message format. The Document style can also be used for request-response communication.

And in this regard, he chose his side:

In this case, Microsoft is right. Document/literal Web services are a better choice for data interoperability. While focusing on JAX-RPC instead of JAXM is in line with Sun's attempt to simplify Java development, it's the wrong approach for Web services.

Then the followings are mainly pointing out the flaws in Apache Axis.

First of all, I can see in his article what Axis does wrong. However, I don't see how Microsoft's way - Document/literal Web services - could solve the problem.

I've mixed feeling about his arguments. First I do think the present RPC implemention in WSDL is getting out of hand(chaotic and complicated), but if we could only do document style transfer as he said the Microsoft's way, why the hell should we consider adopting WS in the first place? Isn't what SUN and Apache(and IBM, he didn't mention) does exactly what we really need for interoperative protocols?

To put it simpler, in the pure document transfer model, the processing logics will lie in the senders and receivers. That is defeating the major merit of WS on interoperability, where the processing logics are not hard-coded into one framework.

The author is a scientist in DOD and he really has some insight in WSDL, but if WSDL is really implemented in Microsoft's way then many wouldn't even consider adopting WS in the first place.

Re:Little summary and comment

[etcshadow]

Also, how seriously are we supposed to consider an article about the future of web technologies when the guy can't (sic) even figure out how to properly escape his apostrohpes.

I mean really!

No, joking aside, its remarkable the extent to which this is all just unmitigated editorializing without the slightest good reasoning to back it up. Not to mention that I pretty strongly disagree with the notion that "RPC is bad". If anything, I'd actually go as far as to say that I think that SOAP is far too often overkill. If XML-RPC gets the job done, then why resort to all that heavy, unmanageable garbage?

Old news - the split has moved

[Kopretinka]

WSDL 1.1 is an old specification and the split is just as old and mostly solved by general adoption of the document/literal (as opposed to RPC/encoded) approach.

Now the pressing question seems to be the RESTfulness or not of Web Services. See a related Mark Baker's blog entry for illustration.