Q: Where (when) use Web-services?

A: SOAP (XML-RPC) – suitable for inter companies’ communications and nothing else. WS are not suitable in many cases just because RPC model is not sufficient. I just want to warn: consider applicability of RPC model for a particular case and then consider the most likely scenario for system’s growth (toward “document” model or …)

WS have some sense, but attempt to recreate entire communication infrastructure atop of less than efficient basis does not seem right to me.

Q: What is wrong with RPC?

A: RPC model has limited applicability. RPC model is around here since early 70’s ( http://members.ud.com/about/gc/grid_evolution.htm ) and it proven to be insufficient in some cases (but widely applicable).

Q: What do I mean?

A: I mean that ORB (object request broker) model is way more advanced over RPC. With an RPC, we call a specific function (the data is separate). In contrast, with an ORB, we call a method within a specific object. Different objects (class instances) may respond to the same method call differently. Because each object manages its own private instance data, the method is implemented on that specific instance data. ORB method invocations are precise. The call gets to a specific object that controls specific data and then implements the function in its own class-specific way. In contrast, RPC classes have no specificity: all the functions with the same name are implemented the same way. 

I mean also that RPC model resembles procedural programming (“C”-style) and has all its advantages and disadvantages.

Q: So, WS/RPC is applicable to B2B, right?

A: I think that B2B is not quite about RPC and WS model mentions that talking about “document” model. WS should be considered and used (if necessary) with emphasis on “document” model. So, I guess WS is something about some standardized document processing and should not be used for implementing RPC between systems. The difference between “document” view and RPC view is almost unnoticeable (and even may not exist technically), but it is here. We may notice that if we will consider architectural aspects and nature of B2B communications.

I would try to draw a separation line: if we want to map an incoming document to a programming language structure and use that structure programmatically, then we should not use WS (even UDDI and WSDL allows us to do that). If we are going to process incoming data as XML document, lets say transform it into another text document, then, most likely, we are dealing with “document” oriented model and WS will be good enough. But actually in the case we should not worry how that XML document was delivered. We may even recall that SOAP does not define delivery protocol (well, except http that I consider to be a foreign inclusion).

Q: What is my point?

A: Just lone voice against WS hype, which is profitable for vendors but may be dead-end for users. WS could lead to the same outcome as VB (or scripting languages): easy to start with but impossible to scale up to necessary level.