"The correct use of SOAP "
The debate between RPC SOAP and document-based (sometimes refered to as messaging-based) SOAP has raged for a long time, but this ZDNet article signifies a new stage in the debate. It calls document-based SOAP "the correct use of SOAP" and lists the shortcomings of RPC-based SOAP, which include waiting on blocking calls and tight linkage to implementation. This view chimes with the anecdotes of early adopters who feel that they've had their fingers burnt with RPC-based SOAP.
Scott Dietzen's article in this month's Web Services Journal focusses on interoperability between .NET and J2EE, and he makes the side point that asynchronous messaging is "arguably the Web services sweet spot". This side-point might be the key to the article- since asynchronous messaging abstracts the underlying .NET and J2EE platforms. This is preferable to a situation where RPC calls are directly mapped to components on differing platforms. Jason Bloomberg (ZapThink) uses a fantastic analogy to explain this concept in Principle 6 of his Seven Principles of Service-Oriented Development:
The component-based approach to enterprise systems development is to build components on platforms that expose their functionality through their interfaces. In essence, the components are soccer players who kick a ball to each other, and the platform is the field. Needless to say, two players will find it difficult to interact if they are on different fields.
[ XML and Web Services Magazine ]
In the .NET world, the choice between messaging and RPC amounts to a choice between [WebMethod] (since ASP .NET's default is document-literal) and [WebMethod, SoapRpcMethod]. In the J2EE world, the choice amounts amounts to a choice between JAX-RPC and JAXM.
So is it a case of "messaging good, RPC bad"? It turns out that most people are "pro-choice" in this debate, where the choice of RPC or messaging depends on the system architecture (as the two excellent articles linked in the paragraph above explain).
These types of architectural decisions predate SOAP, and are crucial to system design. Ray Ozzie puts it really well (read the full essay if you haven't read it already):
Decisions such as centralized versus decentralized, hierarchical versus cellular, RPC versus MQ, API versus protocol, structured versus semi-structured, etc., are so very critical to understand in order to make an informed choice.
[ Architecture Matters ]
So it isn't "right vs wrong" - it's an architectural choice. There is still a place for RPC-based SOAP, but it's much diminished from the case 18 months ago where many developers understood SOAP to be only for RPC.
|
