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.
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.
Can you clearify?
-----Original Message-----
From: Didier PH Martin [mailto:]
Sent: Tue 4/30/2002 6:59 AM
To: Simon St.Laurent
Cc:
Subject: Re: [xml-dev] A market view
Hello Simon,
Simon said:
> I'm also not sure what you're looking for in "XML framework developers",
> as I tend to do my XML work in Java anyway.
Didier replies:
Yes, this is true, we can say that XML framework developers are also a
subset of any procedural language market segment.
I meant developers whose main language is a procedural language not the XML
framework technologies. For instance, using XSLT to transform XML documents,
etc... qualifies you as an XML framework develeloper. Using SOAP to perform
an RPC from a program don't. My hypothesis is that developers that are
actually using mainly procedural languages will tend to use web services as
RPC and thus, simply by the market pressure and the consumers needs, SOAP
will evolve more on this branch. My hypothesis is that even developers using
template based languages like JSP or ASP are also mainly procedural language
developers that learned HTML markup and that they can replace
response.write("<p>") simply by <p> in their applications.
I try to evaluate, what is the size of the market segment having made the
shift to:
data storage ------ XML document ------> browser (using XSLT to transform
into a rendering format).
This model based on a REST arcbitecture, needs that data sources produce XML
documents and that browsers support XSLT to render the produced XML document
for human consumption. Its a document centric world and developers are using
interpreters (i.e. an HTML browser or an SVG browser) pr create new ones
(i.e. with an XSLT template). Thus this whole architecture leads the
developers to master document/interpretation technologies. XSLT is the core
tool they can use to create their own interpretation (i.e. transform a
particular structure/domain language into an other one).
It seems also that the market dynamics lead the developers to be attracted
by two poles:
Pole 1:
a) the web client server architecture with as a central point a web server
and at the edge interpreters (mainly browsers). The tools are mainly
targeted to machine-human communication. The service is based on the HTTP
verbs with a major dominance of the verbs: GET and POST. The others are
rarely used (if they are used?). The evolution path for this architecture is
described in the previous paragraph.
pole 2:
b) the service architecture structure in a peer to peer architecture. My
hypothesis is that the first wave is mainly composed of web servers using
service providers. So the peers are permanently connected servers. Some
servers will act as both web servers and service providers. It seems that
SOAP has the lead and my hypothesis is that this trend is re-enforced by
Microsoft tools (6 to 7 million developers impacted) and that Java tools
will follow (some are already supporting it). Thus, the total impact of the
SOAP ecosystem could potentially be of 7.5/8 million to 8.5/9 million
developers that will use the SOAP tools proposed by the tool providers.
c) When the first wave is well established, the desktop OS monopoly (i.e.
Microsoft) will include in its platform more service clients and then
enforce their natural position and weaken the interpreter (i.e. browser)
position. For instance, Office tools could be made more powerful desktop
clients than browsers (off course I am not saying that they are better,
simply that they can potentially make them a lot more powerful than web
browsers if the formers consume network services). At this stage, the
incentive to use services packaged as SOAP services will even be stronger
since the consumers will ask for it. Off course they won't ask for web
services to be implemented with SOAP, they will ask for more powerful
applications for the more powerful machine they now have.
Thus, actually the main "web" client is the browser. My hypothesis is that
Microsoft is slowly moving to a position where we have more than one
"service" client and thus it re-enforce their actual position as the desktop
market monopoly. This could lead to a weaken position for the web browser
and prevent a substitution to other platforms. Why? the web browser could
easily be ported to any platform (in fact it is through Mozilla). An
application having a dependency on the windows API is not as easily ported
(except if toolkits like WINE offer the same API - But I doubt that without
financial support from the deep pockets like SUN or IBM that they could be
fast enough to follow Microsoft).
The more we use REST and the universal client concept (i.e. the browser) the
more the dependency is on non-windows technologies and thus what we develop
is inherently independent of the underlying platform. However, if the
mainstream developers market is engaged to used SOAP tools (based on the
ecosystems measures = from 7.5 to 9 millions), then on the long run the web
may become a totally different beast.
Forrester was introducing the concept of the X-internet last year. An
implication is the X internet created by the main stream developers may be
very dependent on SOAP and platform dependent applications. Off course this
is only an hypothesis or a potential scenario [1] I am simply analyzing.
Finally my hypothesis is that the market using the
REST/document/interpretation methodology didn't got the time to develop
fully and that the SOAP + the monopoly efforts to keep the control of the
desktop wave may motivate the developers to stick to the classical
procedural model and use SOAP for RPC.
W3C, up to now was able to use its efficient PR machine to grab interest on
a REST based XML world. Its more influencial members are deeply involved in
SOAP, W3C may be forced to follow the SOAP path. I guess that we can say we
are at an inflection point [2].
So, this is why I am buiding a view of the market, to understand the
underlying trend and market dynamics.
cheers
Didier PH Martin
[1] The art of the long view (Panning for the Future in an Uncertain World)
by Peter Schwartz.
[2] Only the paranoid survive (How to exploit the crisis points that
challenge every company and career) by Andrew Grove.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
