http://radio.weblogs.com/0100887/categories/webServices/ Copyright 2002 Jon Udell Tue, 25 Jun 2002 21:41:49 GMT http://backend.userland.com/rss092 6/25/2002; 5:41:14 PM http://radio.weblogs.com/0100887/categories/webServices/2002/06/25.html#a317 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Tony Hong from </FONT><A href="http://www.xmethods.org/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>XMethods</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> is here, showing a nifty evolution&nbsp;of </FONT><A href="http://www.xmethods.net/ve2/XSpace.po"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>XSpace</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>. It's currently a service that implements a simple shared address book. The concept is that of a tuplespace updated and queried by SOAP messages. The new twist, slated to become available July 15,&nbsp; is the use of </FONT><A href="http://www.sonicsoftware.com/products/product_line.htm"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>SonicMQ</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, a JMS (Java Messaging Service) provider, to add reliability, security, and pub-sub notification services to the message flow. </FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Tony Hong from </FONT><A href="http://www.xmethods.org/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>XMethods</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> is here, showing a nifty evolution&nbsp;of </FONT><A href="http://www.xmethods.net/ve2/XSpace.po"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>XSpace</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>. It's currently a service that implements a simple shared address book. The concept is that of a tuplespace updated and queried by SOAP messages. The new twist, slated to become available July 15,&nbsp; is the use of </FONT><A href="http://www.sonicsoftware.com/products/product_line.htm"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>SonicMQ</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, a JMS (Java Messaging Service) provider, to add reliability, security, and pub-sub notification services to the message flow. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>The new service is done doc/literal style. A writer of the address book sends a XML document, which is the update, to the SonicMQ broker, and receives an acknowledgement. Separately, readers of the address book register with the broker for update notifications. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>You'll be able to download Sonic's client software in order to interact with the service. As Tony points out, this is a great first step towards a broader appreciation of SOAP's one-way messaging. Alternatively, you'll be able to interact with the service over straight HTTP. In this scenario the services supplied by JMS will be either missing, or done differently. But the point is: the payload's the same either way, and can tap into evolving standards like WS-Security. Very cool stuff!</FONT><BR></P> 6/17/2002; 11:47:56 AM http://radio.weblogs.com/0100887/categories/webServices/2002/06/17.html#a305 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I agree with the RESTian argument that SOAP-accessible web services should support HTTP GET where appropriate.&nbsp;The&nbsp;notion is that this&nbsp;will help ensure low coordination costs both for person-to-machine as well as machine-to-machine communication.&nbsp;</FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I agree with the RESTian argument that SOAP-accessible web services should support HTTP GET where appropriate.&nbsp;The&nbsp;notion is that this&nbsp;will help ensure low coordination costs both for person-to-machine as well as machine-to-machine communication.&nbsp;</FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>In </FONT><A href="http://www.w3.org/2001/tag/doc/get7"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>TAG Finding: URIs, Addressability, and the use of HTTP GET</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, Dan Connolly sums up the recommendation that resources be made URI-addressable where possible, and&nbsp;dispels two myths that have clouded the issue:</FONT></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=myth> <DL> <DT><EM><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Myth: Search services will not index anything with a "?" in the URI. </FONT></EM> <DD><EM><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>This was a heuristic to avoid infinite loops in some search service crawlers, but it was not an architectural constraint, and modern search services use more sophisticated heuristics to avoid loops. </FONT></EM></DD></DL></DIV> <DIV class=myth> <DL> <DT><EM><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Myth: URIs cannot be longer than 256 characters </FONT></EM> <DD><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif><FONT size=2><EM>This was a limitation in some server implementations, and while servers continue to have limitations to prevent denial-of-service attacks, they are generally at least 4000 characters, and they evolve as the legitimate uses of application developers evolve.</EM> </FONT></FONT></DD> <DD><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2></FONT>&nbsp;</DD></DL></DIV></BLOCKQUOTE> <P dir=ltr><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>How this relates to the orchestration of web services is still very unclear though. Consider this </FONT><A href="http://lists.w3.org/Archives/Public/www-tag/2002Apr/0159.html"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>remark on the TAG mailing list</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, from Edwin Khodabakchian, CEO of </FONT><A href="http://www.collaxa.com/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Collaxa</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>:</FONT></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr><EM><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>- we need to acknowledge the fact that we are solving a new class of&nbsp; problem that is more about machine-to-machine communication</FONT></EM></P></BLOCKQUOTE> <P dir=ltr><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Perhaps this really is a new class of problem, but if so I would like to see spelled out more clearly exactly how and why that is so, and what it implies. </FONT></P> <P dir=ltr>&nbsp;</P> 5/16/2002; 3:02:41 PM http://radio.weblogs.com/0100887/categories/webServices/2002/05/16.html#a246 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Adam Bosworth gave a whirlwind tour of BEA's WebLogic Workshop. After the obligatory Hello World, he dived into the good stuff. Cajun (I'll still call it that, for brevity) takes the web services mantra of loose coupling very seriously. It separates interfaces from implementations by generating XML grammars, called maps. In a nutshell, your map abstracts away from member variables in implementation code. An element in the map, say &lt;PERSON&gt;, is not sensitive to changes in the names of underlying member variable names. This contrasts with most SOAP toolkits which generate interfaces based on those names -- interfaces that break when the names change. </FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Adam Bosworth gave a whirlwind tour of BEA's WebLogic Workshop. After the obligatory Hello World, he dived into the good stuff. Cajun (I'll still call it that, for brevity) takes the web services mantra of loose coupling very seriously. It separates interfaces from implementations by generating XML grammars, called maps. In a nutshell, your map abstracts away from member variables in implementation code. An element in the map, say &lt;PERSON&gt;, is not sensitive to changes in the names of underlying member variable names. This contrasts with most SOAP toolkits which generate interfaces based on those names -- interfaces that break when the names change. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>A second key abstraction is conversational context. The framework persists member variables when a service is marked as conversational, and automatically sets up one-way messaging with callbacks. Under the covers, JMS (Java Messaging Service) is used rather than HTTP as the SOAP transport. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Bosworth argued that Microsoft's toolkit makes it too easy to create tightly-coupled RPC-style services. In the follow-on panel discussion, Microsoft's Dave Stutz admitted as much. "Guilty as charged," he said, while pointing that as with VB, early concept demos have been biased toward the simple, easy-to-use end of the spectrum. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I asked Stutz, Bosworth, and IBM's Sam Ruby if the doc/literal style of SOAP usage, which Visual Studio.NET in fact prefers, represents the generic approach to BEA's mapping technology. They agreed violently. Bosworth: "I'd even say RPC was a bad idea to begin with." </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Bubbling under the surface here&nbsp;are the somewhat ominous implications of an architectural style that solely addresses application-to-application communication. "Where's the web in web services?" asked </FONT><A href="http://www.knownow.com/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>KnowNow's</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> Rohit Khare. The term is a complete misnomer, the panel agreed. It should have been called Net Services, not Web Services, but the name stuck and it's too late to change it. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Tim O'Reilly jumped up to say that we ignore the social dimension of the web at our peril. There is "innovative froth" that comes from the bottom up, driven by open source energy and by the interactions among people and applications. I agree. Web services are reinventing the client/server space, and aiming to solve coordination and scaling problems that were never solved before. This necessarily goes beyond the original charter of the web, which was to be a distributed hypermedia application. But the two worlds are not wholly incompatible either. Not every message requires conversational context and asynchronous callbacks. There's a vast and useful intersection between the web as an interactive hypermedia application (used promiscuously by humans and applications), and web services as a mainly application-to-application affair. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>It's great to see BEA, Microsoft, and IBM violently agreeing on architectural principles and protocols. But like Tim O'Reilly, I wish that consensus didn't sound so much like a vendor-driven secession from the web ecosystem. </FONT></P> 5/2/2002; 2:04:18 PM http://radio.weblogs.com/0100887/categories/webServices/2002/05/02.html#a213 Since the REST/RPC/SOAP discussion flared up again, I've been looking for a single clear statement about what kind of problem may exist, and what to do about it. I found it in Paul Prescod's <A href="http://www.xml.com/pub/a/2002/04/24/google.html?page=3">Google's Gaffe</A>: <BLOCKQUOTE><I>The point that has not yet filtered through to the mainstream of web services implementors is that linking is just as important for machine-to-machine applications as it is for human-facing applications. If it is impossible to link to SOAP-exposed resources, then they are less powerful and useful than HTTP-exposed ones. Until SOAP has an addressing mechanism as rich as HTTP URIs, SOAP is less, rather than more powerful than HTTP. </I></BLOCKQUOTE>A hugely important class of web services is addressable by URI, and accessible to GET. We call these things web pages. The fact that such pages can be consumed by human-operated browsers and machine-operated scripts in the same way was, and remains, a great thing. As some pages evolve into services intended mainly for programmatic use, XML becomes a natural representation format. This need not undermine the value of the URL-line which, as I've <A href="http://www.byte.com/documents/byt20010816s0002/">pointed out</A>, remains an incredibly vital style of access. <P> <b>...</b> <P>Since the REST/RPC/SOAP discussion flared up again, I've been looking for a single clear statement about what kind of problem may exist, and what to do about it. I found it in Paul Prescod's <A href="http://www.xml.com/pub/a/2002/04/24/google.html?page=3">Google's Gaffe</A>: <BLOCKQUOTE><I>The point that has not yet filtered through to the mainstream of web services implementors is that linking is just as important for machine-to-machine applications as it is for human-facing applications. If it is impossible to link to SOAP-exposed resources, then they are less powerful and useful than HTTP-exposed ones. Until SOAP has an addressing mechanism as rich as HTTP URIs, SOAP is less, rather than more powerful than HTTP. </I></BLOCKQUOTE>A hugely important class of web services is addressable by URI, and accessible to GET. We call these things web pages. The fact that such pages can be consumed by human-operated browsers and machine-operated scripts in the same way was, and remains, a great thing. As some pages evolve into services intended mainly for programmatic use, XML becomes a natural representation format. This need not undermine the value of the URL-line which, as I've <A href="http://www.byte.com/documents/byt20010816s0002/">pointed out</A>, remains an incredibly vital style of access. <P></P> <P>In practice, though, I don't find that SOAP&nbsp;undermines the URL-line. Toolkits seem perfectly happy to let me turn service names, method names, and parameters into URLs. I have here, for example, both Visual Studio.NET and GLUE. If I write a SOAP service called StockQuote in either of these, with a method called getQuote, then in addition to the SOAP/RPC interface I can automatically use: </P> <P><a href="http://host/StockQuote/getQuote?sym=VRSN">http://host/StockQuote/getQuote?sym=VRSN</a> </P> <P>or: </P> <P><a href="http://host/StockQuote.asmx/getQuote?sym=VRSN">http://host/StockQuote.asmx/getQuote?sym=VRSN</a> </P> <P>Should Google have done something like this? Absolutely. I miss being able to type <A href="http://google.com/xml?q=roy+fielding"><a href="http://google.com/xml?q=roy+fielding">http://google.com/xml?q=roy+fielding</a></A>. As I pointed out in a essay on <A href="http://radio.weblogs.com/0100887/2002/02/12.html">monetizing web services</A>, this was possible a few months ago. Arguably it still should be. But that's just a business decision Google has made. In practice, given the restrictions placed on the Google API, the regular web-friendly HTTP GET remains the preferred way to link to the infinite space of Google queries, as people do every day. </P> <P>So, SOAP toolkits already support a RESTful mode for GET-style (though not for POST-style) operations. Since GET-style reads are what both people and machines mainly use the Web to do, I'd say we're in pretty good shape. </P> <P>PS: The top Google result for "restful soap" -- ahead of a bunch of W3C mailing list postings -- is an ad for <STRONG>a restful soap full of aromatic fragrance</STRONG>.<STRONG><EM> </EM></STRONG>The name of this restful soap? <STRONG>Desert Storm</STRONG>. Go figure.</P> 4/30/2002; 11:10:06 AM http://radio.weblogs.com/0100887/categories/webServices/2002/04/30.html#a210 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I've received a number of interesting responses to my </FONT><A href="http://www.byte.com/documents/byt1019844546060/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>current BYTE.com column</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> on the Google API. Nelson Minar, former Popular Power CTO who's now with Google, wrote to point out that since HTML doctitles are of uncertain quality, the snippets (relevant text chunks) returned by the Google API might form an interesting search space. When I tried that, though, the results didn't seem to&nbsp;diverge enough. </FONT><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>The name of the game, in this kind of surfing, is to chart a course through googlespace that diverges enough to turn up interesting new connections, but not so much as to end up off in the weeds. </FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I've received a number of interesting responses to my </FONT><A href="http://www.byte.com/documents/byt1019844546060/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>current BYTE.com column</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> on the Google API. Nelson Minar, former Popular Power CTO who's now with Google, wrote to point out that since HTML doctitles are of uncertain quality, the snippets (relevant text chunks) returned by the Google API might form an interesting search space. When I tried that, though, the results didn't seem to&nbsp;diverge enough. </FONT><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>The name of the game, in this kind of surfing, is to chart a course through googlespace that diverges enough to turn up interesting new connections, but not so much as to end up off in the weeds. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>So far, titles seem like the happy medium between URLs and snippets. But I'm not done yet. I have a hunch that things will&nbsp;get really juicy when the evaluation function is augmented by something outside of Google. This kind of cross-wiring is what most excited me when I did my <A href="http://www.byte.com/documents/s=146/byt19990906s0008/">original mindshare experiment</A>. When the activation threshold for these experiments is low, because lots of services have standardized APIs, we'll see (I am sure) some compelling&nbsp;emergent behaviors.</FONT></P> <P><FONT size=2>Another reader, Martin Spernau, pointed me to a <A href="http://traumwind.tierpfad.de/soap/">graphical Google browser</A> based on the <A href="http://www.touchgraph.com/">TouchGraph</A> framework. At the TouchGraph site, one of the demos of the framework browses a <A href="http://www.touchgraph.com/browser/LinkBrowser.html">taxonomy of graph-based interfaces</A>. Such visualizations never fail to fascinate me. But I confess that they don't hold my interest for very long, either. I suspect that the reason is the same: the evaluation functions are too simple, and too isolated.&nbsp;Consider this <A href="http://www.orgnet.com/inetindustry.html">interactive map of the Net industry</A>. According to its creator, Valdis Krebs:</FONT></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>The data is gathered from various public sources and includes only data on business partnerships such as strategic alliances and joint ventures.</EM></P></BLOCKQUOTE> <P dir=ltr><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>It's easy to imagine an evaluation function that's sensitive to the sizes of the business entities, the durations of the partnerships, the job-posting patterns in various cities, and a million other things. Visualizing these dimensions would be a worthy challenge for a graph-based interface.&nbsp;Semantic web visionaries suppose that all this metadata will be encoded in standard ways, and will then unlock these powerful evaluation functions. I think it's going to happen the other way around. Web APIs will surface whatever meager bits of metadata already exist. Applications will combine these APIs to create novel effects. Then metadata will be incrementally improved in order to enhance the effects.</FONT></P> <P>&nbsp;</P> 4/29/2002; 1:27:09 PM http://radio.weblogs.com/0100887/categories/webServices/2002/04/29.html#a209 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Google's new SOAP API seemed to follow a boom-and-bust trajectory. Everyone was excited about it until it arrived. Then doubts arose. "Bah," scoffed Edd Dumbill in an O'Reilly Network column (<a href="http://www.oreillynet.com/cs/weblog/view/wlg/1303">http://www.oreillynet.com/cs/weblog/view/wlg/1303</a>), "what a waste of space for something that can be done in one line of shell script." Edd's point -- that an HTML-screenscraping alternative to the Google SOAP API is easy to hack together -- is quite correct. But the conclusion -- that Google's SOAP API is silly -- is, I think, very wrong. Full story at </FONT><A href="http://www.byte.com/documents/byt1019844546060/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>BYTE.com</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>.</FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Google's new SOAP API seemed to follow a boom-and-bust trajectory. Everyone was excited about it until it arrived. Then doubts arose. "Bah," scoffed Edd Dumbill in an O'Reilly Network column (<a href="http://www.oreillynet.com/cs/weblog/view/wlg/1303">http://www.oreillynet.com/cs/weblog/view/wlg/1303</a>), "what a waste of space for something that can be done in one line of shell script." Edd's point -- that an HTML-screenscraping alternative to the Google SOAP API is easy to hack together -- is quite correct. But the conclusion -- that Google's SOAP API is silly -- is, I think, very wrong. Full story at </FONT><A href="http://www.byte.com/documents/byt1019844546060/"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>BYTE.com</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>.</FONT></P> <P>&nbsp;</P> 3/27/2002; 10:22:56 PM http://radio.weblogs.com/0100887/categories/webServices/2002/03/27.html#a153 I had another look at the W3C's XSLT service. Turns out you <EM>can</EM> send it parameters after all. The syntax seems a bit outdated, but it works fine. Now the original solution to the <A href="http://radio.weblogs.com/0100887/2002/03/19.html#a150">Nasa newsfeed</A>&nbsp;seems silly. All that was really needed was a <A href="http://radio.weblogs.com/0100887/gems/nasa.xml">parameterized stylesheet</A>&nbsp;and three URLS, one <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=Liftoff&amp;transform=Submit">for</A> <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=Science&amp;transform=Submit">each</A> <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=SpaceCal&amp;transform=Submit">channel</A>. <b>...</b> <P>I had another look at the W3C's XSLT service. Turns out you <EM>can</EM> send it parameters after all. The syntax seems a bit outdated, but it works fine. Now the original solution to the <A href="http://radio.weblogs.com/0100887/2002/03/19.html#a150">Nasa newsfeed</A>&nbsp;seems silly. All that was really needed was a <A href="http://radio.weblogs.com/0100887/gems/nasa.xml">parameterized stylesheet</A>&nbsp;and three URLS, one <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=Liftoff&amp;transform=Submit">for</A> <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=Science&amp;transform=Submit">each</A> <A href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http://radio.weblogs.com/0100887/gems/nasa.xml&amp;xmlfile=http://liftoff.msfc.nasa.gov/Content.xml&amp;Channel=SpaceCal&amp;transform=Submit">channel</A>. </P> <P>This way of composing Web services by blogging URL-lines feels like the spiritual descendent of the Unix pipeline. This is&nbsp;part of what motivates the REST discussion, I think. We're going to be hearing more and more about <A href="http://www.xml.com/pub/a/2002/02/20/rest.html?page=2">orchestration</A> of services in the coming months&nbsp;and years.&nbsp;There will be many ways to do that. I hope that&nbsp;basic URL-line-plus-XLST will be a viable strategy. Maybe I'm just being nostalgic, but I don't think so. I have a hunch that pipelined XML processing will be important for all the reasons that pipelined text processing has been.</P> 3/8/2002; 6:44:31 PM http://radio.weblogs.com/0100887/categories/webServices/2002/03/08.html#a118 <STRONG>Smoketesting DIY Web services</STRONG> <b>...</b> <P><STRONG>Smoketesting DIY Web services</STRONG></P> <P>Marc Barrot <A href="http://radio.weblogs.com/0104487/2002/03/07.html#a8">ran into a roadblock</A>. I offered my <A href="http://www.byte.com/tangledthreads/thread.jsp?forum=262&amp;thread=10486">5-step smoketest</A>. </P> 3/5/2002; 9:25:42 AM http://radio.weblogs.com/0100887/categories/webServices/2002/03/05.html#a107 <STRONG>WSDL for rpc.weblogs.com</STRONG> <b>...</b> <P><STRONG>WSDL for rpc.weblogs.com</STRONG></P> <P>Sam's <A href="http://radio.weblogs.com/0101679/stories/2002/03/05/aBusyDevelopersGuideToWsdl11PartIi.html">Busy Developer's Guide, Part II</A>&nbsp;delivers the <A href="http://radio.weblogs.com/0101679/stories/2002/03/05/weblogswsdl.html">WSDL</A>, and shows how to use it from Axis and .NET.</P> 3/4/2002; 7:29:10 PM http://radio.weblogs.com/0100887/categories/webServices/2002/03/04.html#a105 <STRONG>Hashtables, structs, XML-RPC, SOAP</STRONG> <b>...</b> <P dir=ltr><STRONG>Hashtables, structs, XML-RPC, SOAP</STRONG></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>It is a darn shame.&nbsp; XML-RPC does define a struct which reasonably maps to a hash table.&nbsp; If only SOAP had done the same in section 5, then Jon's adventure would have been a rather short one. </EM>[<A href="http://radio.weblogs.com/0101679/">Sam Ruby's Radio Weblog</A>]</P></BLOCKQUOTE> <P dir=ltr>Certainly that would have helped, and I'm hopeful it will yet happen. I suspect there's more going on here, though. Sam and I both believe that the dynamic nature of scripting languages is not the root cause of WSDL pain. Scripting <EM>culture</EM>, however, does play a role. Hashtables are popular with scripters because&nbsp;we can build up data structures without having to name all of their parts.&nbsp;This is a major convenience that speeds up development quite a lot. It also has a cost both to us, in terms of future readability, and to others, in terms of maintenance and (when we go over the wire) interop. How to weigh the benefits and costs of anonymous&nbsp;versus named data? And, how to join programming cultures that prefer things one way with cultures that prefer things the other way?</P> Sam Ruby&apos;s Radio Weblog 3/3/2002; 6:43:28 PM http://radio.weblogs.com/0100887/categories/webServices/2002/03/03.html#a98 <STRONG>Pipelining XML</STRONG> <b>...</b> <P dir=ltr><STRONG>Pipelining XML</STRONG></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><A href="http://www.xmlhack.com/read.php?item=1564"><EM>XML Pipeline Definition Language introduced as Note</EM></A><EM>. The W3C has released XML Pipeline Definition Language, which describes "the processing relationships between XML resources" as a Note. [</EM><A href="http://www.xmlhack.com"><EM>xmlhack</EM></A><EM>]</EM></P></BLOCKQUOTE> <P dir=ltr>The example shown illustrates&nbsp;an XML-ized make. Presumably another kind of "pipeline processor" than a command shell could be used, and the inputs and outputs could be other than files -- e.g., SAX/DOM/SOAP sources and sinks.</P> <P dir=ltr>The&nbsp;trick will be to do these things in a human-writeable way. It's been a long time since I was able to write any but the simplest makefile by hand. That's one reason I found scripting so compelling -- no makefile programming. </P> xmlhack 2/25/2002; 6:15:52 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/25.html#a95 <STRONG>Simon connects the dots</STRONG> <b>...</b> <P><STRONG>Simon connects the dots</STRONG></P> <P>Another piece of this&nbsp;puzzle is reliable messaging. It's available now, in proprietary ways, for example from <A href="http://www.byte.com/documents/byt20010718s0001/">Kenamea</A>. Simon connects the dots between routing and reliable messaging in Web-services space:</P> <BLOCKQUOTE> <P dir=ltr><EM>IBM have similar offerings with </EM><A href="http://www-106.ibm.com/developerworks/webservices/library/ws-phtt/?dwzone=webservices"><EM>HTTPR</EM></A><EM>&nbsp;&amp; </EM><A href="http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf"><EM>WSFL</EM></A><EM>&nbsp;[no equivalent to DIME as far as&nbsp;I know]. HTTPR takes a different approach to WS-Routing, in that it tunnels a reliable message exchange over HTTP [I wonder what the REST guys make of that]. </EM></P> <P dir=ltr><EM>Whilst WS-Routing takes a more layered approach, WS-Routing on its own doesn't provide reliablity, but provides the bits needs to make a reliable exchange layer. HTTPR doesn't appear to provide any routing information, so is still limited to point 2 point scenarios. Intermediaries seem to be one of the more useful features of SOAP, which is why I wrote some </EM><A href="http://www.pocketsoap.com/samples/"><EM>WS-Routing code</EM></A><EM> a while back. </EM></P> <P dir=ltr><EM>I think classic queue based middleware such as MSMQ, MQSeries and JMS are going to rule the reliable delivery situations for quite a while yet. [</EM><A href="http://www.pocketsoap.com/weblog/"><EM>Simon Fell</EM></A><EM>]</EM></P></BLOCKQUOTE> <P dir=ltr>Just to muddy the waters a bit more, there's a RESTian flavor to KnowNow's <A href="http://192.168.1.101:5335/://www.byte.com/documents/byt20011128s0003/">event router</A>, with its notion of URIs that look like: </P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr><a href="kn://what/someapp/sometopic">kn://what/someapp/sometopic</a></P></BLOCKQUOTE> Simon Fell 2/25/2002; 4:20:21 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/25.html#a94 <STRONG>Simon Fell on SOAP-RP and WS-Routing</STRONG> <b>...</b> <P><STRONG>Simon Fell on SOAP-RP and WS-Routing</STRONG></P> <P>A <A href="http://www.pocketsoap.com/weblog/2002/02/25.html#a237">clarification</A>:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Nothing in WS-Routing requires doc/literal bodies, yes the WS-Routing header itself is doc/literal, but the SOAP Body can be anything.</EM></P></BLOCKQUOTE> <P dir=ltr>Thanks, Simon, for this and also for the pointer to the <A href="http://discuss.develop.com/archives/wa.exe?A0=soap-rp&amp;D=0&amp;H=0&amp;O=T&amp;T=1">discussion archive</A>. A little more digging reveals that SOAP-RP, DIME, and XLANG (BizTalk's dialect) were all sent <A href="http://lists.w3.org/Archives/Public/www-ws/2001May/0010.html">as a batch</A> to the W3C by Henrik Frystyk Nielsen, to illustrate "<EM>some ideas in the area of SOAP routing, message encapsulation, and<BR>process orchestration</EM>."</P> <P dir=ltr>I thought there were IBM fingerprints on this stuff too, but maybe not (yet)?</P> 2/25/2002; 1:47:20 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/25.html#a93 <STRONG>WS-Routing, active proxies, PEP</STRONG> <b>...</b> <P><STRONG>WS-Routing, active proxies, PEP</STRONG></P> <P>The REST argument about pipelining reminds me that HTTP can inherently be proxied, and that Rohit Khare talked about this in his paper <A href="http://www.cs.caltech.edu/~adam/papers/csa98b.html">Composing Active Proxies to Extend the Web</A>. He said in part:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Want to annotate a Japanese page without advertisements from a HTTP-NG server? Want to book a plane ticket and a hotel room in a single transaction? Active proxies can be neatly reused as black-box components when chained together via HTTP. However, we can envision neater, more efficient ways to enable reuse. The <A href="http://www.w3.org/TR/WD-http-pep.html">HTTP Protocol Extension Protocol (PEP)</A> transcends the welter of competing APIs to offer a single syntax for naming, specializing, and applying active proxies with finer-grained control. PEP also affords reasoning about compatible extensions and composite extensions.</EM></P> <P dir=ltr><EM>We are already familiar with many analogues to active proxies as reusable filters. The difference is in the the affordances of the interchange format. UNIX filters operate on ASCII streams; SQL queries operate on relational tables; active proxies and pages operate on Web hypermedia (HTML/XML + HTTP).</EM> </P></BLOCKQUOTE> <P dir=ltr>Now here's an interesting connection. MS has a proposal on the table called <A href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsroutspecindex.asp">WS-Routing</A>. It sketches out the framework within which loosely-coupled systems will route SOAP messages that are handled in the doc/literal style, rather than the rpc/encoded style. And one of the references in that spec is none other than:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr><STRONG>[13]</STRONG> Rohit Khare, "<A name=ws-routing_rkar></A><A href="http://www.cs.caltech.edu/~adam/papers/csa98b.html">Composing Active Proxies to Extend the Web</A>"</P></BLOCKQUOTE> <P dir=ltr>It appears that SOAP will address the pipelining aspect of the REST argument,&nbsp;though whether in an overcomplicated way is open to (vigorous) debate.</P> <P dir=ltr>Would SOAP routing and proxying also deal with the addressability aspect of the REST argument? And if so, is this again over-complex? Dunno, that's why I'm asking. Feel free to <A href="http://www.byte.com/tangledthreads/thread.jsp?forum=263&amp;thread=9812">put in your own $0.02</A>.</P> 2/24/2002; 11:24:05 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/24.html#a92 <STRONG>Paul Prescod on REST vs RPC</STRONG> <b>...</b> <P><STRONG>Paul Prescod on REST vs RPC</STRONG></P> <P dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Paul Prescod has written a <A href="http://www.xml.com/pub/a/2002/02/20/rest.html">long and thoughtful piece on REST</A>. He says, in part:</FONT></P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2><EM>For instance, a balkanized way to reference about a particular stock value is as WebService.stockQuote("KREM"). This syntax is particular to some programming language and is not available outside of it. It can only be used by some other service through some form of glue. A universally addressable way is <a href="http://www..../webservice/stockquotes?KREM">http://www..../webservice/stockquotes?KREM</a>.</FONT></EM></P></BLOCKQUOTE> <P dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Is it just me, or this discussion a little like a <A href="http://www.yorku.ca/eye/necker.htm">Necker cube</A>? I see it both ways, depending on how I look. <BR><BR>I wish, though, that we could drop the tired stock-quote example. Calling a service with one simple value, and returning one simple value, does make the point that an equivalently standard one-line SOAP invocation, while possible, doesn't exist yet. But what about when complex objects are passed? <BR><BR>True, we can send and receive blobs of XML atomically. Paul notes we can then pipeline these operations, and he likens HTTP GET and PUT to the Unix shell's pipe operators. I guess that's true. On the other hand, if the command I stick after the pipe operator can support introspection, then I want to use that instead of a man page.</FONT></P> <P dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2><A href="http://www.byte.com/tangledthreads/thread.jsp?forum=263&amp;thread=9812">Discussion.</A></FONT></P> 2/24/2002; 1:22:29 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/24.html#a88 <STRONG>Displaying&nbsp;subscriptions</STRONG> <b>...</b> <P><STRONG>Displaying&nbsp;subscriptions</STRONG></P> <P>The widget below my calendar&nbsp;displays the RSS feeds to which I'm subscribed in Radio. It's a Web service, although at the moment (since I'm blocking inbound access) it can only be used locally, like so:</P> <P><FONT face=Geneva,Arial,Sans-Serif>&lt;%params = {}; xml.rpc ("127.0.0.1", 5335, "radio.subs", @params)%&gt;</FONT></P> <P><FONT face=Arial>or, equivalently,</FONT></P> <P><FONT face=Arial>&lt;% ["xmlrpc://127.0.0.1:5335/"].radio.subs () %&gt;</FONT></P> <P><FONT face=Arial>or, in fact:</FONT></P> <P><FONT face=Arial>&lt;% ["soap://127.0.0.1:5335/"].radio.subs () %&gt;</FONT></P> <P>The script is <A href="http://radio.weblogs.com/0100887/stories/2002/02/24/enumeratingInboundNewsFeeds.html">here</A>. It's an experiment in transparency. I'm revealing not just what I might say that I read, for example in a static blogroll, but what my&nbsp;aggregator database shows&nbsp;that I actually do read (or at least scan). </P> <P>This might be a little too intimate for most people to want to do. It might even be too intimate for me to want to do, at least for a global audience. I'll see how that feels. </P> <P>In any case this is clearly&nbsp;something that smaller teams of people might want to do in order to pool knowledge resources. And that's the beauty of having the implementation be a Web service. The same code that's used to render the global homepage can be used in a point-to-point kind of way.</P> <P>Part of this experiment is about getting RSS URLs to be more visible, and more easily transferable. Note that some of these feeds are courtesy of <A href="http://www.newsisfree.com/">NewsIsFree</A>. I think this is an acceptable non-commercial use. If I hear otherwise, I'll desist. <BR></P> 2/19/2002; 12:24:45 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/19.html#a72 <STRONG>Walking the fault lines</STRONG> <b>...</b> <P><STRONG>Walking the fault lines</STRONG></P> <P>I've been plugging away with a handful of toolkits --&nbsp;.NET, SOAP::Lite, GLUE, and Radio -- trying to get a feel for where the SOAP/WSDL fault lines actually are. Today, Jake Savin <A href="http://radio.weblogs.com/0001000/2002/02/19.html#a318">articulates</A>&nbsp;what I've begun to suspect also: there are a lot of ways to encode things in SOAP, and this&nbsp;complicates the problem of typing them in WSDL.</P> <P>I don't see this as simply a static/dynamic language issue. Whether or not&nbsp;a toolkit&nbsp;can or will autogenerate WSDL for some service, you should (as Simon Fell&nbsp;<A href="http://soap.4s4c.com/weblogs/subscribe.wsdl">did</A>) be able to figure out how to write the WSDL, should you choose to provide it. And when you can successfully do so, you make your service frictionlesslessly available to a lot of people.</P> <P>So far, I'm finding simple things (like arrays of strings) to be possible, and hard things (like hashes of lists, and lists of hashes) to be very difficult.</P> <P>Kind of makes me wish for the <A href="http://www.xml-rpc.com/spec">good old days</A>:</P> <BLOCKQUOTE> <P>Here's an example of a two-element &lt;struct&gt;: </P> <PRE>&lt;struct&gt; &lt;member&gt; &lt;name&gt;lowerBound&lt;/name&gt; &lt;value&gt;&lt;i4&gt;18&lt;/i4&gt;&lt;/value&gt; &lt;/member&gt; &lt;member&gt; &lt;name&gt;upperBound&lt;/name&gt; &lt;value&gt;&lt;i4&gt;139&lt;/i4&gt;&lt;/value&gt; &lt;/member&gt; &lt;/struct&gt; </PRE> <P>&lt;struct&gt;s can be recursive, any &lt;value&gt; may contain a &lt;struct&gt; or any other type, including an &lt;array&gt;. </P> </BLOCKQUOTE> <P>What, exactly, was missing from this tiny nugget of gold?</P> 2/15/2002; 2:30:26 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/15.html#a70 <A href="http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html">A Busy Developers Guide to WSDL 1.1</A>&nbsp;[<A href="http://radio.weblogs.com/0101679/">Sam Ruby's Radio Weblog</A>] Thanks, Sam! Far and away the most grokkable explanation I've seen. <b>...</b> <P><A href="http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html">A Busy Developers Guide to WSDL 1.1</A>&nbsp;[<A href="http://radio.weblogs.com/0101679/">Sam Ruby's Radio Weblog</A>] Thanks, Sam! Far and away the most grokkable explanation I've seen. </P> Sam Ruby&apos;s Radio Weblog 2/15/2002; 1:14:52 AM http://radio.weblogs.com/0100887/categories/webServices/2002/02/15.html#a68 <STRONG>wsdl/xmethods.org/vs.net redux</STRONG> <b>...</b> <P><STRONG>wsdl/xmethods.org/vs.net redux</STRONG></P> <P>Tony Hong, who runs xmethods.org, wrote asking for details on the problems I reported. I should've taken better notes the first time. Tonight, I had much better luck. Here's a commented transcript; all the code snippets shown below are working. </P> <P>When the WSDL does work with VS.NET, the effect is magical. APIs become discoverable in the nicest possible way. <EM>Exciting!</EM></P> <PRE> <a href="//">//</a> implementation: glue <a href="//">//</a> wsdl: <a href="http://www.geographynetwork.com/geoservices/v1/PlaceFinder.wsdl">http://www.geographynetwork.com/geoservices/v1/PlaceFinder.wsdl</a> <a href="//">//</a> acquire web reference? yes com.geographynetwork.www.PlaceFinder ws1 = new com.geographynetwork.www.PlaceFinder(); com.geographynetwork.www.LocationInfo l = ws1.findPlace("New York"); Console.WriteLine(l.candidates[0].description1); Console.WriteLine(l.candidates[0].x.ToString()); Console.WriteLine(l.candidates[0].y.ToString()); <a href="//">//</a> namespace completion? yes (and complex return types are no problem) <a href="//">//</a> invoke successfully? yes <a href="//">//</a> implementation: delphi <a href="//">//</a> wsdl: <a href="http://developerdays.com/cgi-bin/tempconverter.exe/wsdl/ITempConverter">http://developerdays.com/cgi-bin/tempconverter.exe/wsdl/ITempConverter</a> <a href="//">//</a> acquire web reference? yes com.developerdays.ITempConverterservice ws2 = new com.developerdays.ITempConverterservice(); Console.WriteLine(ws2.FtoC ( 99 )); <a href="//">//</a> namespace completion? yes <a href="//">//</a> invoke successfully? yes <a href="//">//</a> implementation: ?? <a href="//">//</a> wsdl: <a href="http://soaptest.activestate.com:8080/PSDBService.wsdl">http://soaptest.activestate.com:8080/PSDBService.wsdl</a> <a href="//">//</a> acquire web reference? no <a href="//">//</a> namespace completion? n/a <a href="//">//</a> invoke successfully? n/a <a href="//">//</a> implementation: apache soap <a href="//">//</a> wsdl: <a href="http://www.mybubble.com:8080/mybubbleEntServer/MyBubbleSoapServices.wsdl">http://www.mybubble.com:8080/mybubbleEntServer/MyBubbleSoapServices.wsdl</a> <a href="//">//</a> acquire web reference? yes <a href="//">//</a> namespace completion? no <a href="//">//</a> invoke successfully? n/a <a href="//">//</a> implementation: ms.net <a href="//">//</a> wsdl: <a href="http://www.perfectxml.net/WebServices/SalesRankNPrice/BookService.asmx?WSDL">http://www.perfectxml.net/WebServices/SalesRankNPrice/BookService.asmx?WSDL</a> <a href="//">//</a> acquire web reference? yes <a href="//">//</a> namespace completion? yes <a href="//">//</a> invoke successfully? yes net.perfectxml.www.SalesRankNPrice ws4 = new net.perfectxml.www.SalesRankNPrice(); Console.Write(ws4.GetAmazonAndBNSalesRank("0596001193").AmazonSalesRank); <a href="//">//</a> implementation: SqlData <a href="//">//</a> wsdl: <a href="http://www.soapclient.com/xml/SQLDataSoap.WSDL">http://www.soapclient.com/xml/SQLDataSoap.WSDL</a> <a href="//">//</a> acquire web reference? yes <a href="//">//</a> namespace completion? yes <a href="//">//</a> invoke successfully? no, but not a wsdl issue ("error opening SRL file") com.soapclient.www.SQLDataSoap ws5 = new com.soapclient.www.SQLDataSoap(); Console.WriteLine(ws5.ProcessSRL("WEB.SRI","wsdl","AltaVista")); </PRE> 2/14/2002; 12:30:15 AM http://radio.weblogs.com/0100887/categories/webServices/2002/02/14.html#a62 <STRONG>Consuming foreign&nbsp;WSDL from .NET</STRONG> <b>...</b> <P><STRONG>Consuming foreign&nbsp;WSDL from .NET</STRONG></P> <P>It all started so well. I had just installed The Mind Electric's GLUE, a really elegant Java-based XML-and-Web-services product that friends have raved about.&nbsp;GLUE autogenerates WSDL, and being curious about interop, I pointed Visual Studio.NET at it. The magic namespace completion worked like a charm! This was really encouraging!</P> <P>Then things went downhill. I switched the GLUE sample service from returning a string to returning a java.util.Hashtable. GLUE itself was perfectly happy to consume that complex return value, but VS.NET had no clue what to do with it.</P> <P>Then I&nbsp;hopped over to <A href="http://www.xmethods.org/">xmethods</A> and started trying to consume WSDL found there. Results were lousy. A bunch of WSDL files that can be retrieved don't seem to be recognized as Web services at all by VS.NET. Of those that can, only some complete on the service name. Of that subset, only some complete on operations and types. I did finally manage to get VS.NET to consume one or two services that return simple types, but as Kevin Altis said yesterday, it sure feels like work.</P> 2/12/2002; 6:20:39 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/12.html#a60 <STRONG>SOAP's work/reward ratio</STRONG> <b>...</b> <P><STRONG>SOAP's work/reward ratio</STRONG></P> <P>Kevin Altis is collecting <A href="http://radio.weblogs.com/0102677/2002/02/11.html#a15">WSDL verifiers and SOAP endpoint invokers</A>. "Quite frankly," he says,&nbsp;"using SOAP and WSDL feels like work."</P> <P>That's partly due to the tools-and-interop situation, which as Kevin notes, is rapidly improving. Mainly, though, it just <EM>is</EM> a lot of work to deploy all this machinery in order to&nbsp;call yet another stock-quote or celsius-to-fahrenheit gizmo that returns one&nbsp;lonely little value swaddled in layers of XML. It's not just tools-and-interop holding back the flood of interesting services that we all envision. What makes services interesting is data that's interesting. Some creators/gatherers of interesting data will wrap high-quality APIs around it just for fun. But for others, maybe most others, it'll have to be a business. </P> 2/12/2002; 2:46:53 PM http://radio.weblogs.com/0100887/categories/webServices/2002/02/12.html#a58 <STRONG>Monetizing&nbsp;Web services</STRONG> <b>...</b> <P><STRONG>Monetizing&nbsp;Web services</STRONG></P> <P>Sam Ruby shares a <A href="http://radio.weblogs.com/0101679/stories/2002/02/12/newspl.html">script</A>&nbsp;that massages Google's news page. "Be forewarned," says&nbsp;Sam, "that as this is based on HTML scraping&nbsp;it could break if google were to change it's layout."&nbsp;</P> <P>This reminded me that Google used to support the syntax:</P> <P><A href="http://google.com/xml?q=wsdl"><a href="http://google.com/xml?q=wsdl">http://google.com/xml?q=wsdl</a></A></P> <P>Now, of course, that&nbsp;request 403's and refers&nbsp;you&nbsp;to the <A href="http://www.google.com/terms_of_service.html ">Terms of Service page</A>. For a long time, I've thought that Amazon and now Google ought to offer, and monetize, programmatic access to their info. Why not? Return small/infrequently-requested XML datasets for free, and larger/oft-requested XML datasets for a fee.</P> 1/31/2002; 4:12:23 PM http://radio.weblogs.com/0100887/categories/webServices/2002/01/31.html#a42 Shane Caraveo from ActiveState wrote me a note illustrating how they handle WSDL for Perl: <b>...</b> <P>Shane Caraveo from ActiveState wrote me a note illustrating how they handle WSDL for Perl:</P> <DIV>=for interface</DIV> <DIV>&nbsp; static ustring echostring(ustring something); </DIV> <DIV>&nbsp; &lt;soap namespace="<A href='http://www.activestate.com/echo/"/'><a href="http://www.ActiveState.com/echo/">http://www.ActiveState.com/echo/</a>"/</A>&gt; </DIV> <DIV>=cut <P></P></DIV> <DIV><FONT face="Courier, Monospace">sub echostring {<BR>&nbsp;&nbsp;&nbsp;&nbsp; my $echo = shift;<BR>&nbsp;&nbsp;&nbsp;&nbsp; return $echo;<BR>&nbsp;}</FONT></DIV> <P>The question is overhead. Obviously this metadata, like all documentation, requires double maintenance, and can get out of synch with the code. As a Perl programmer, would I rather pay that cost in the form of typing all my functions and variables, and have a free ride on WSDL generation, or pay it only on a per-exported-object basis?</P> <P><A href="http://radio.weblogs.com/0101679/">Sam Ruby</A>&nbsp;and I talked about this today. He makes a good point: since exported stuff will surely be a fraction of all the stuff you write in a dynamic scripting language, why not just pay on an as-needed basis? It's an 80/20 (or 90/10) thing.</P> <P>The flip side of this is that web services network effects arise, I believe, when things can automatically, or almost automatically, be exported -- even when the need to do so wasn't originally anticipated. </P> <P>Kevin Altis, who is working these days on <A href="http://sourceforge.net/projects/pythoncard/">PythonCard</A>, sent me this set of definitions which was in turn sent to him by "an erudite reader":</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>"statically typed language</EM></P> <P><EM>A language in which types are fixed at compile time. Most statically typed<BR>languages enforce this by requiring you to declare all variables with their<BR>datatypes before using them. Java and C are statically typed languages.</EM></P> <P><EM>dynamically typed language</EM></P> <P><EM>A language in which types are discovered at execution time; the opposite of<BR>statically typed. VBScript and Python are dynamically typed, because they<BR>figure out what type a variable is when you first assign it a value.</EM></P> <P><EM>strongly typed language</EM></P> <P><EM>A language in which types are always enforced. Java and Python are strongly<BR>typed. If you have an integer, you can't treat it like a string without<BR>explicitly converting it (more on how to do this later in this chapter).</EM></P> <P><EM>weakly typed language</EM></P> <P><EM>A language in which types may be ignored; the opposite of strongly typed.<BR>VBScript is weakly typed. In VBScript, you can concatenate the string '12'<BR>and the integer 3 to get the string '123', then treat that as the integer<BR>123, all without any explicit conversion.</EM></P> <P><EM>So Python is both dynamically typed (because it doesn't use explicit<BR>datatype declarations) and strongly typed (because once a variable has a<BR>datatype, it actually matters)."</EM></P></BLOCKQUOTE> <P dir=ltr>(If you are that "erudite reader" and wish to be identified, just let me know.)&nbsp;</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr><EM>Correction: here is the </EM><A href="http://diveintopython.org/odbchelper_funcdef.html"><EM>source</EM></A><EM> of this quotation: it's from Mark Pilgrim's fabulous online Python </EM><A href="http://diveintopython.org/toc.html"><EM>book-in-progress</EM></A><EM>. Sorry for the mixup, Kevin and Mark.</EM></P> <P dir=ltr><EM>Note: it's tempting to try to rewrite history by changing these entries on the fly in order to erase errors. &nbsp;But that&nbsp;won't last forever. Before too long, the <A href="http://web.archive.org/">Wayback Machine</A> will catch you in the act when you try to cover your tracks :-)</EM>&nbsp;<BR></P></BLOCKQUOTE> <P dir=ltr>Perhaps this explains why I have the&nbsp;sense that if optional type declaration were going happen in any major scripting environment, it would happen first in Python. </P> 1/24/2002; 2:34:33 PM http://radio.weblogs.com/0100887/categories/webServices/2002/01/24.html#a39 If WSDL were as easy to write as <A href="http://radio.weblogs.com/0001015/alidlExamples/soap/frontier.xml">this</A>, then humans could write it by hand, and that in turn might make it easier for tools to do it automatically. But the gating factor is not WSDL syntax. It's&nbsp;the typelessness of dynamic languages. <b>...</b> <P>If WSDL were as easy to write as <A href="http://radio.weblogs.com/0001015/alidlExamples/soap/frontier.xml">this</A>, then humans could write it by hand, and that in turn might make it easier for tools to do it automatically. But the gating factor is not WSDL syntax. It's&nbsp;the typelessness of dynamic languages.</P> <P>I was checking out Radio's SOAP support the other day. Following a documented example, I tried this:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr style="MARGIN-RIGHT: 0px">local(s,params={"IntArray":{1,2,3}})<BR>s = soap.rpc.client("/examples","getStateList", @params)</P></BLOCKQUOTE> <P dir=ltr style="MARGIN-RIGHT: 0px">and Radio said:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr style="MARGIN-RIGHT: 0px">The server, localhost, returned a SOAP-ENV:Client fault: Can't call the script "getStateList" because it doesn't define a parameter named "IntArray"</P></BLOCKQUOTE> <P dir=ltr style="MARGIN-RIGHT: 0px">Jake Savin set me straight. The actual implementation had changed, and I needed to call:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr style="MARGIN-RIGHT: 0px">local(s,params={"numlist":{1,2,3}})<BR>s = soap.rpc.client("/examples","getStateList", @params)</P></BLOCKQUOTE> <P dir=ltr style="MARGIN-RIGHT: 0px">Once he pointed me to the <A href="http://radio.weblogs.com/0100887/images/my/getStateList.jpg">implementation of getStateList</A>, it was clear sailing. But I do see the problem. Typeless dynamic scripting languages can be made to <A href="http://aspn.activestate.com/ASPN/WebServices/SWSAPI">easily consume</A> WSDL. Producing&nbsp;the stuff is another matter. </P> <P dir=ltr style="MARGIN-RIGHT: 0px">Perl and Python would have to undergo some&nbsp;deep change&nbsp;(which <A href="http://www.perl.com/pub/a/2001/09/18/parrot.html">may occur</A>) in order to facilitate automatic creation of WSDL. Likewise Frontier.</P> <P dir=ltr style="MARGIN-RIGHT: 0px">Is this a correct statement of the problem?</P> 1/24/2002; 9:22:04 AM http://radio.weblogs.com/0100887/categories/webServices/2002/01/24.html#a38 Sam Ruby <A href="http://radio.weblogs.com/0101679/2002/01/23.html#a19">writes</A>: <b>...</b> <P>Sam Ruby <A href="http://radio.weblogs.com/0101679/2002/01/23.html#a19">writes</A>:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Many SOAP stacks these days come with automatic roadmap dispensers.&nbsp; Simply append a "?WSDL" to the URL and out pops the description of the service.&nbsp; Many alpha males will tell you that they don't need to ask for directions.&nbsp; But I suspect that these roadmap dispensers will be heavily used.</EM></P></BLOCKQUOTE> <P dir=ltr>Absolutely. When services are consumable by namespace completion in an editor, like so:</P> <P><IMG src="http://radio.weblogs.com/0100887/images/my/callTheService.jpg" align=center border=1></P> <P>Then we get the kind of network effect we all want.&nbsp;What matters is not only the number of SOAP endpoints that exist, but the number that are actually used, and "roadmap dispensers" are critical. Automatic testers are darned handy too:</P> <P><IMG src="http://radio.weblogs.com/0100887/images/my/testTheService.jpg" border=1></P> <P>Necessary? No. Desirable? Hugely. I want this, everybody should want this. And it looks like we're going to have it. The tension here, as always, is between what is considered the bare minumum interoperable core, and what is considered optional. If WSDL is not considered core, and isn't everywhere, that will compromise the vision displayed in these images. If it is considered core, it raises the bar on resource-constrained implementors. There's an inevitable and natural tension between these two positions.</P> <HR> <P>John Robb wrote privately to say:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Jon,<BR><BR>You are pointing to images on your Weblog that are located in your desktop folder (so they are not visible).&nbsp; They have been upstreamed to your cloud.</EM> </P></BLOCKQUOTE> <P dir=ltr>Thanks, John. This is exactly what I was testing. Here's what I learned:</P> <OL dir=ltr> <LI> <DIV>An image in or below /www/radio/images will be upstreamed. (I think automatically, but maybe it has to be kicked -- Publish-&gt;Entire Site?)</DIV> <LI> <DIV>Such an image, loaded into a separate IE window, can be dragged into Radio's MS DHTML edit control, and will be inlined.</DIV> <LI> <DIV>By default, the URL is like 127.0.0.1:5335/images, not ./images.</DIV> <LI> <DIV>I guessed that Radio would translate that on upstreaming.</DIV> <LI> <DIV>It didn't.</DIV> <LI> <DIV>So you have to use Source view in the editor, and change 127.0.0.1:5335 to . </DIV> <LI> <DIV>Then, Publish directly. If you switch back to WYSIWYG view, the editing component (which Radio does not control) will revert you to 127.0.0.1:5335.</DIV></LI></OL> <P>Obviously most users are not going to figure this out. Just as, years ago, most did not figure out how much <A href="http://www.oreilly.com/catalog/pracintgr/chapter/ch03_01.html">writing and illustrating and cross-referencing power</A>&nbsp;was built into the mail/news client that they ran every day. We have a chicken/egg situation here. Hypertextual writing, using words and pictures and links, with fluid&nbsp;transitions&nbsp;among&nbsp;local and remote resources, remains difficult. This exactly parallels the WSDL discussion. Until users can take for granted that in any web writing environment, images and text can be dragged and dropped, and everything will just work, we'll keep missing out on an important network effect.</P> <P>And now, I'm going to switch back to Source view and re-fix those links which the Edit control has re-broken. Radio can fix this particular glitch by rewriting what the DHTML edit control does, before upstreaming. But the general&nbsp;issue&nbsp;of&nbsp;how we get to a&nbsp;<A href="http://www.byte.com/documents/s=705/byt20010608s0001/index.htm">universal</A> <A href="http://www.byte.com/documents/s=1113/byt20010806s0004/20010806_udell.html">canvas</A> remains, well, a general issue.</P> <P>PS: One more wrinkle. Using . was OK for the homepage, but I forgot this item is echoed into categories and an archive page. So I'm redoing the . as a full reference to the public site.<BR><BR></P>