Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Web Services -- The City of Jericho?
 On Sat, 23 Nov 2002 05:11:16 -0800 (PST), m a r l o n . n e l s o n <thesardonicwon@y...> 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] 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
