Hi Dare,
Dare said:
> Your post reads like a paranoid conspiracy theory. I am particularly
interested in how using SOAP (XML on the wire) translates to vendor lock in.
You state that web browsers can be platform neutral yet somehow posit that
SOAP applications cannot, which is rather contradictory IMHO.
Didier replies:
It could be interpreted this way :-) :-) but I have too much humor to see
the world that way. I simply stated a potential scenario and a potential
threat to REST like architectures. This scenario may or may not happen. It
just a "what if" game. Moreover, we shouldn't think that keeping its
monopoly situation is "a conspiracy ", it simply business. Maybe bad
business in the long run (or an harm to an industry) but its nonetheless
business with the main goal to bring value to its stakeholders and
shareholders.
On the other hand, SOAP used for RPC do not requires a browser, just an
application at the other end to send/receive function call. We have here a
potential architectural shift. Potential other scenarios:
a) REST/interpreter architectures and SOAP/desktop apps co-exist and tend to
each specialize to certain usages
b) one architecture dominates the other
c) There is a re-unification that create a synergy effect
d) other scenarios you may envision...
Dare said:
> A web browser is an application that at the minimum understands HTTP and
renders HTML (plus Java, Flash, CSS, Javascript, etc). XML web service
applications will need to understand a similar target protocol (most likely
HTTP for the short term) and react to SOAP requests. How exactly the former
somehow leads to cross platform RESTful apps while the latter leads to
vendor lockin that marginalizes the web and creates dependencies on the
Win32 API is lost on me.
Didier replies:
Yes you can use SOAP RPC in a browser app (DHTML + JavaScript or other...).
However, you can also include RPC calls in desktop applications. If more
service providers are promoting/publishing their service as SOAP RPC calls,
then, since we have more procedural programmers in the market place and
since a vast majority of them use Microsoft tools, then these developers
could be given tools providing to hem more power to develop a new class of
desktop apps to the detriment of browser based apps. Do not forget that
Microsoft is not a Monopoly within the server market, but is one within the
desktop market. So, on the server side SOAP could be platform independent
but on the desktop, sorry but it is not yet. And if within the desktop
market a sane competitive market is brought back by a competent competitor
then the whole game is totally different.
I also forgot an alternative: customer choice. If customers require to get a
REST like architecture then we have, this time, a shift of power from the
vendor to the customer and this modifies tremendously the competitive
landscape. However, the current market behavior do not let us think that it
is the case (except within some market segments).
To better understand, suppose for a moment that to get a collection of
record/information set from Google that you just declare an array of
structure (or an identical type) and get the data from a *single* function
call expressed in the language you are competent with. You can only compete
with that with the same economy of code expressed in the same language the
developers likes. People won't do extra work just to please us.
cheers
Didier PH Martin
