[
Lists Home |
Date Index |
Thread Index
]
On Sat, 23 Nov 2002 05:11:16 -0800 (PST), m a r l o n . n e l s o n <thesardonicwon@yahoo.com>
wrote:
> i have read yet another article (http://www.vnunet.com/News/1137043) on
> Web services, and to be honest, i do not know what to think about it
> anymore. For a hot minute, i was under the impression that we were making
> good head-way with this technology, but now i am not so convinced
> anymore.
It's like everything else in the technology world: someone gets a decent
idea (like leveraging XML and the Web to get distributed object systems
to interoperate), a few proof of concepts are built and proto-standards
defined, then various weasels declare it the Next Big Thing and all
hell breaks loose. A couple of years later, the stark realization that it
hasn't
cured world hunger becomes apparent, the trade press declares it a Total
and Complete Failure for not living up to the hype, and the weasels scurry
for something else to hype. Somewhere in the debris the actual decent
ideas continue to develop at their own pace, and the REALLY good ones
survive.
> So, are Web services the city of Jericho, hiding behind a great wall
> awaiting a 'joshua' to lead the charge in breaking it down? What is the
> argument (at this point) for Web services? What is the main
> hinderance(s) (XML, UDDI, SOAP, etc.)? Any opinions?
I remain as skeptical of the Total Failure meme as the Next Big Thing
meme. Real people have serious problems getting diverse applications
to interoperate, definitely behind the firewall, and probably over the
Internet if the infrastructure and business models continue to evolve
to support that idea. Somehow or other, XML (vendor/application/platform-
neutral as it is) and the Web (the most successfully distributed
application
in history) are sure to be part of the solution. So, the core
ideas are not likely to be broken down by a Joshua or anyone else.
It's more like the Great Wall of China than the walls of Jerico ...
invaders
who breached the walls might conquer Beijing, but ended up assimilated
a couple of generations later. A Joshua is certainly welcome to blast
down the walls of hype -- more power to him!. My life (wearing my
W3C hat) has gotten easier as the "bubble mentality" and the myth
that profound problems can be solved by yet another standard has
faded in the last few months, leaving room for realistic expectations about what
web services can do and what timeframe it will take to do them.
I don't have any great insights into how long it will take the rubble of
the
hype wars to get reincorporated into a new city, or exactly which
technologies
will the building blocks. As for the specific technologies mentioned:
* XML has definitely been put to the test by web services. It's hard
core has emerged more or less intact (although concerns about its serialization
format's efficiency in high-transaction volume environments
aren't going away quietly). On the other hand, some of the bits that
cause the most interoperability problems (e.g. DTD internal subsets,
entity references and processing instructions) have been quietly deprecated
from use in web services. I think this will eventually
motivate changes to XML (or its successor!) to make it more modular and
cleanly layered.
* UDDI is generally considered the weakest of the bricks
you mentioned, but on the other hand it is evolving the fastest -- v3 uses
URIs to identify the web service resources, and I've heard that they may
support
HTTP URIs in the next version.
* SOAP has both assimilated some of the ideas that were thrown against it
(REST->the web method feature in SOAP 1.2 ) and may have some of the flab
slimmed off (e.g. the encoding stuff that
the WS-I profile essentially deprecates). On the other hand, its core idea
of
an extensibility model based on headers being added, subtracted, processed,
or
ignored as a message is processed seems extremely powerful to me -- that's
the basis for the WS-Security stuff, transaction management proposals, coordinating
messages that are part of multi-part workflows, etc. There are a lot of
ideas in SOAP that will work in pipelined processes, "spaces"
and other database-mediated web services architectures, pure REST
implementations, as well as RPC-style interactions.
* WSDL is also coming along. However all this stuff works, there needs to
be a declaration language so that producers, consumers, and, intermediaries
can understand what they need to know about what other parties expect.
Again, it seems to be robust enough to absorb new ideas (e.g the WSCI
proposals for WSDL extensions to define choreographed invocations of
individual web services).
Clearly the *ideas* behind at least SOAP and WSDL will survive the hype meltdown.
Will the specs as we know them? They have some
well-known warts ... but then so do Java, HTTP, HTML, URIs, XML,
etc. etc. etc. The more standardized the solution is, the more the network effect
can do its magic: agreement on SOMETHING, warts and all,
is generally more productive than fighting over over which ideal world
is more elegant than another.
[disclaimer: not speaking for W3C WS Architecture WG or anyone but myself]
|
