{ "version": "https://jsonfeed.org/version/1", "title": "Sam Ruby", "home_page_url": "https://intertwingly.net/blog/", "description": "It’s just data", "author": { "name": "Sam Ruby" }, "items": [ { "guid": "tag:intertwingly.net,2004:1", "url": "http://www.intertwingly.net/blog/1.html", "title": "null", "content_html": "
I like Dave's \nInfoWorld slides very much. But to me, reality is much\nmore fractal. Bridges are complicated structures. Bootstrapping is\ndefinitely the way to go. But at some point the thin cable\nbecomes part of a larger intertwined structure that is a thicker\ncable. And that thicker cable becomes part of a larger\nintertwined structure called a bridge. And that bridge's\ndesign is approved by nameless civil servants. And\ninspected on a regular basis by blue collar workers. \nEverybody plays a vital role.
\n\nSOAP is such a\nthin cable. What other thin cables will is be interwoven with\nto produce the thicker cable that will become part of the massive\ninfrastructure that we generically refer to as the internet?
Hmmm. What the beta of the slides referenced below\ndidn't mention was that Dave was going to use his \nInfoworld keynote to argue against pulling the second cable across so that we\ncan get on with the business of building bridges between all\nplatforms, static and dynamic alike.
\n\nPerl is a reasonably dynamic scripting language, no? Yet\nin that language, parameters are passed by position instead of\nname. What extra information can the SOAP::Lite implementation make\nuse of to provide this added information? Why WSDL, of\ncourse!
Julian Bond in VoidStar asks \"is\nWSDL useful?\" I personally was converted to\nbelieve in WSDL at the \ninteropathon I hosted nine months ago. Our goal was to\nflush out any compatibility issues between soap stacks. While\nwe did plenty of that, where we spent most of our time was\nresolving issues where people couldn't follow simple\nand clear directions. People weren't sending things that\nweren't important to them but may be of vital importance\nto others (e.g. SOAPAction). There were plenty of\ntranscription errors (e.g. upper vs. lower case). And in most\ncases, the error messages produced weren't helpful. We spent\na lot of time looking at wire dumps.
\n\nThose stacks that either could make use of WSDL to create a\nstarting point (proxy, skeleton, etc); or could use WSDL\ndynamically to \"fill in the blanks\" seemed to have the least\ntrouble. At the time, Apache's wasn't one of them. We've\nsince corrected that in Axis alpha\n3 with JAX\nRPC support..
\nDave Winer: Speaking of SOAP, and\nWSDL, here's something to think about. Look at the Blogger\nAPI. No IDL. How did it work? It's very broadly\ndeployed and quite useful. It's gotten a lot of Web people excited\nabout XML-RPC. No one has ever, as far as I know, asked for an IDL.\nWhy?
\n\nProbably the same reason the Axis link to the\nleft was added using vim. \nWe are not our\ntarget audience.
\n\nBTW, it may be foolish\nof me to think that Web Services are for Web People, but well, I\ndo
\n\nDave, I guess your target audience is people like myself and Jon\nUdell who \"have for years been in the game of dynamically\ngenerating statically-served sites\". What about the hordes of\nunwashed masses who aren't so inclined and seem to prefer \nIntegrated \nDevelopment Environments\n(\nIDEs)? Wouldn't the world be a better place if there was\nsome widely adopted way to describe the messages in some structured\nway ameanable to consumption by such tools?
Simon Fell says that he\nfound the building and running of Axis to be pretty painless; What\nmore can a person ask for? \n He's looking to test out SOAP Messages with\nAttachments support for interop with pocketSOAP.
\n\nSpeaking of interop, it looks like I've not updates the Apache\nSOAP interop test to run against the latest 4s4c endpoint and the\nold endpoint has been removed. Time to update the test script\nand rerun...
What? Could there possibly be yet another \nApache SOAP implementation looming in the near future? It\nlooks like HP is looking to donate a cousin to their HP\nSOAP implementation to Apache. From what I can tell\nso far, they have better integration with Cocoon, and weaker support\nfor things like references to\nvalues. Looks like there might be a good possibility\nfor synergy...
\n\nI especially like the consise statement of their\nrequirements:
\n\nJon Udell writes:
\n\n\n\nRicher\ndescriptions of messages, and tools that exploit those richer\ndescriptions, will make life even better for \"mom\" -- if this extra\nsophistication doesn't gum up the works.
\nIs WSDL gum, or grease, or maybe a little of both?
\n
Answer: WSDL is a roadmap. Both gum\nor grease need to actually touch the moving parts to have an\naffect. WSDL does neither. Look at a SOAP message and\ntry to find the reference to the WSDL. It isn't there. \nNever has been. Look at the SOAP specification and try to\nfind the reference to a WSDL. It isn't there either.
\n\nLook at a bridge. Imagine the\narchitectural drawings that came first and greatly influenced the\nconstruction. Can you imagine a bridge of any significance\nbeing built without a roadmap?
\n\nMany SOAP stacks these days come with\nautomatic roadmap dispensers. Simply append a \"?WSDL\" to the\nURL and out pops the description of the service. Many alpha\nmales will tell you that they don't need to ask for\ndirections. But I suspect that these roadmap dispensers will\nbe heavily used.
In response to this,\ntav writes:\nsomeone please tell sam that google has been doing this for a\nlong time now... i've noticed it on around 0.3% (totally random\nnumber ;p) of google searches. Got it,\nthanks! Kinda freaked me out when I saw it, but as a\nlow frequency random sample kinds thing, it seems OK.