Sign In/My Account | View Cart  
advertisement


Listen Print Discuss

Google's Gaffe
by Paul Prescod | Pages: 1, 2, 3

Dynamically Declaring Types

Some people are not willing to go to the extra effort of publishing explicit service descriptions (e.g. WSDL or WRDL). That's fine. There are a variety of inline-type annotation techniques you could use. Examples include the XMI, MIME-RPC, XML-RPC, WDDL, and even SOAP's "section 5" encoding. No one of these has become the standard because the common wisdom in the strongly typed XML world is that it will be much more common to express the types in some form of external schema such as XML Schema.

In other words, dynamically parsing XML into language-native data types is a problem that has been solved over and over again. If you happen to prefer the SOAP solution, then use the SOAP encoding. My opposition is to the SOAP-RPC protocol, not the SOAP encoding.

Service as API

An important issue in all of this is ease-of-use. If it is no longer simple for programmers to use the service, then it will fail.

If you are a Java or C# programmer, you use the client bindings provided by Google. The details of the protocol are invisible to you. You can skip the rest of this section if you wish.

What if you are using one of the few other languages (e.g. Perl or Delphi) with a decent SOAP/WSDL toolkit? If the toolkit is complete then it will support WSDL's HTTP binding. You can use exactly the same API to access the service as if you were using the SOAP version. Admittedly, toolkits supporting the HTTP bindings are few and far between, but that can, and hopefully will, change quickly. Google could lead the way here.

What if you are using a language with no special toolkit at all, just a standard programming language distribution or IDE? Obviously the HTTP solution wins because SOAP and WSDL support is not yet embedded in most programming language distributions. It takes five lines of Java to get a cached page or spelling correction from my version of the service. You don't need even an XML parser installed to handle two of the three methods.

Other Non-problems

You might think that the URI form would have problems with internationalization. That is not so. Google already supports internationalized URIs. How else could non-English speakers search the Web? You might think that the URI-based API would have trouble with large queries. That is also not true. Google limits the lengths of queries explicitly, even for SOAP messages. Google's limits are well within the safe reaches of URIs. There are ways to use HTTP to deal with arbitrarily large queries so that Google can loosen their limits later without outgrowing HTTP.

Now your application may have different requirements than Google's so the analysis may be quite different. HTTP is not necessarily better than SOAP-RPC for every application in the world. In my experience, however, the HTTP solution is better for any project where a public (as opposed to individual or departmental) interface is needed for a service. If you believe you have a counter-example (a concrete, not abstract, counter-example), I'd like to discuss it. Every time I convert a service, SOAP advocates say: "yes, sure, that service would be better done as HTTP, but there are others that are not." I am still looking for evidence of this.

Advantages of the HTTP API

Let's consider the benefits of the HTTP version. First, I have already discussed how HTTP has standardized ways of doing authentication and of handling non-XML (including non-textual) data. The message size is a tiny fraction of the original. More important, it is much easier for a typical system security administrator to filter, log, monitor and read.

The CPU load is also likely to be significantly smaller. I shudder to think how many cycles are being wasted around the world creating redundant SOAP messages for Google (sometimes base64'ing data) and then parsing them again on the other side. Remember that each and every message is also an HTTP message and must be built and parsed as such. Readers in California should remind Google that electricity is precious. They could switch to pure HTTP and turn off a couple of wasted server clusters.

Users of the HTTP version have no need to install a SOAP implementation like .NET's or Apache's. They can use any HTTP implementation, including Internet Explorer, Netscape, Mozilla, Lynx, Opera, wget, java.net.URL, Python's httplib.HTTPConnection, Perl's LWP, etc. In fact, you could easily test the API through a plain old HTML form.

<p>Get cached page:</p>
<form method="GET" action="http://mymachine/cgi/cachedpage.py">
Key: <input name="key">
Url: <input name="url">
<input type="submit">
</form>

The HTTP version is highly amenable to caching. You can set up a standard HTTP cache on your local network or use one at your ISP. Google could also do server-side caching using something as simple as Squid. Of course caching of SOAP is also possible if you write the cache implementation yourself. With HTTP, you can install any one of a variety of free or commercial caching proxy implementations.

The HTTP version could use the little-known feature of HTTP known as content negotiation. "Conneg", as it is known to its fans, allows each URI to map to a resource that can deliver up various representations of itself. For instance the service could return the same URI in GoogleML, SOAP, XML-RPC and HTML, depending on the preferences of the caller as stated using an "Accept" header.

The Web's Crowning Glory

But all of these advantages are like the tiny diamonds that ring the big rock. The most important advantage is that an HTTP version is part of the Web rather than merely being behind it. This point is subtle but the most central. A piece of information is on the Web if it has a URI, accessible through a Web protocol or is embedded in an accessible document. When Google exposes its service through SOAP, it is behind the Web because the object with the web URI is the SOAP component ("endpoint"), not the actual query results. I need to go through the component to get to the data, like making a phone call through an operator instead of dialing direct. But in the XML/HTTP/URI way of thinking, every possible query result has its own URI and thus is a first-class web data object.

This assigning of URIs is incredibly powerful. First, it means that in standard hypertext documents it is possible to link to query results. There are thousands of links around the Web to Google search result resources. Google's HTML incarnation is an important part of the web community as a service, but it is also an important part of the Web through the thousands of virtual "resource documents" it hosts like:

<a href="http://www.google.com/search?hl=en&q=xml+-soap">Search Google for links about XML</a>

There are thousands of links to these documents scattered around the Web. So Google is both a service and a shared information base.

It is now time to move this concept into XML. You may recall the days when XML was intended to be a way of publishing structured information on the Web. One of the great virtues was supposed to be that result sets could be more compact and could be manipulated (e.g. sorted and filtered) using client-side scripting. Somehow we got sidetracked with RPC models and SOAP, but the core idea of delivering XML to the desktop is alive and well in Internet Explorer and Mozilla. We still have not achieved that and will not until machines and humans use the same access protocol: HTTP.

But URI addressability is important even for information that will never be seen by humans. Addressable XML can be composed into extremely sophisticated "compound-documents". Referring to context-providing or historical documents is a necessary component of any non-trivial business transaction.

There are a variety of web standards designed to make this easier, like XInclude, XSLT, XPointer, XLink, RDF and XML Topic Maps. For instance, consider a document that uses XInclude to aggregate query results:

<document xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="http://mymachine/cgi/search.py?key=
    ...&amp;q=xml+rules"/>
<xi:include href="http://mymachine/cgi/search.py?key=
    ...&amp;q=constantrevolution+rules"/>
</document>

Now consider an XSLT template that does the inclusions:

<xsl:template match="xi:include">
    <xsl:apply-templates select="document(@href)"/>
</xsl:template>

And then a template in another XSLT transform could collect the URL and snippet elements in the merged data, sort them by URL and transform them to HTML:

<xsl:template match="/">
    <sorted-results>
    <xsl:for-each select="//goog:item">
        <xsl:sort select="goog:URL"/>
        <xsl:copy-of select="goog:URL"/>
        <xsl:copy-of select="goog:snippet"/>
    </xsl:for-each>
    </sorted-results>
</xsl:template>

Next consider an RDF assertion that related the query results to an individual's home pages:

<rdf:Description about='http://www.prescod.net'>
<CachedVersionAt 
   rdf:resource='http://mymachine/cgi/cached_page.py?key=
     ...&amp;url=http://www.prescod.net'/>
<PagesThatReferTo
   rdf:resource='http://mymachine/cgi/search.py?key=
     ...&amp;q=http://www.prescod.net'/>
</rdf:Description>

Don't worry if you are uninterested in the particular technologies. Many great hyperlinked applications do not use any of them. After all, using links in XML need be no harder than putting a URL in an attribute value. The Web's strength is that it allows us to address, link, compare, relate and otherwise combine resources. You can use standardized syntaxes or proprietary ones based on your particular problem domain.

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.

SOAP-based services are called "Web Services" because their proponents wish to partake of the Web's success -- yet they don't build on its core technologies, URIs and HTTP. Somehow many have equated SOAP and Web Services but HTTP has been in Service on the Web for more than a decade now and has not yet hit its prime. One other question for you to ponder. If, in general, most deployed Web Services use XML Schema for definition of types, language-specific databinding techniques for interpretation of types and HTTP for the transport of data, then what exactly is SOAP doing?

What Would Frodo Do?

Back in the days before XML, when we used SGML, we enthusiasts were like Hobbits in the Shire, hearing tales of the distant wars between Wizards (tools vendors), Dragons (database vendors) and Armies (MIS departments). But we were relatively sheltered from them. Those days have long since passed.

What we need to do is gather together a fellowship of like-minded Hobbits, Dwarves, Elves and men and go on a quest to educate the world about the limitations of SOAP-RPC interfaces. You can join the quest by signing the petition available, and if you don't mind registering for Google Groups, you can also participate in the thread discussing this topic. Make sure to spread the topic to other mailing lists, weblogs and discussion forums.

XML users have a special understanding of the possibilities of the marriage of hyperlinks, XML and the Web. We have a responsibility to go out of the Shire and educate the other residents of Middle Earth. Google is like the wizard Saruman, a benign and powerful force inexplicably turned from the path of virtue. Nevertheless, I am confident that it can be won back. The white robe awaits the delivery of Google API beta 3 with strong support for URI-addressed XML delivered over HTTP.

Comment on this articleDoes SOAP really add anything to Google, or do you agree with the author's sentiments? Share your opinion in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only Titles Only Newest First
  • This article lines up with Apache Cocoon XMLForm
    2002-05-14 19:08:04 Ivelin Ivanov [Reply]

    I've added my vote to the petition,
    stating that it would take much less effort to develop complex web apps which are browser enabled and web services enabled at the same time,
    when http/uri based interfaces are used.
    A recent addition to the Apache Cocoon platform - XMLForm targets this space.
    http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/webapp/mount/xmlform/




  • What??!
    2002-05-14 13:07:59 Chris Nelson [Reply]

    Why are you arguing against Web Services standards? You spent the entire article reinventing your own non-standard, arcane, redundant layer over the standard Web Services compatible API provided by Google. What are you thinking? You are honestly arguing against standardization? I agree with the previous comment "You might as well ditch XML too". Heck, why not invent your own alphabet?


    We tied the google engine into our website in 10 minutes. We feed the WSDL to our toolkit and it spits out a proxy. We plug it into our web app and bang, we're done. This is the way it should be.


    So now you are honestly saying people should use some non-standard XML schema over pure HTTP because you say so?? What are you doing telling people stuff like this? It's like arguing against the wheel. Can you understand how it makes people who integrate systems lives exponentially more difficult. Web services is the first technology to come along that may make systems integration actually realistic.


    Please do us all a favor and try to see how you can help instead of steering people into a ditch.




    • What??!
      2002-06-03 09:25:32 Mark Baker [Reply]

      Nelson,


      Paul reinvented nothing. He just used HTTP and URIs. No further agreement (and therefore standardization) was necessary.


      Have you compared your SOAP API to what your partners are using at http://www.google.com/xml (using the DTD at http://www.google.com/google.dtd)?


      MB

  • interesting, but...
    2002-05-08 14:27:02 bob woodley [Reply]

    Interesting article, but i feel like it misses the point. or maybe i am.


    SOAP is popular because it is a standard that allows us to send objects around over HTTP (i know its supposed to be transport independent, but who cares? we all just want to adapt our HTTP apps to present an object-oriented API). Yes the type info is in the WSDL, and client bindings could be generated from other protocols and transports, but SOAP works and is supported by multiple big vendors and there are toolkits, so why not use it?


    the best is the enemy of the good.


    bob woodley


  • SOAP vs. REST Resources
    2002-05-05 22:43:56 Nasseam Elkarra [Reply]

    Hey, I started a page dedicated to this issue which can be found here:
    http://www.myspotter.net/links.html


    I am trying to show both sides of the argument so please stop by and give me some feedback or links.


    Peace

  • XSLT and SOAP
    2002-05-02 17:07:15 Kurt Cagle [Reply]

    Having been an ardent XSLT programmer for some time, I've been more than a resentful of the push being made by the software vendors to make the SOAP/RPC model the one true religion. XSLT 1.0 has been built around a model in which content was accessible through a URI interface (via the document() function). XSLT 2.0 mitigates this somewhat with the use of the <xsl:result-document> element, which makes it possible to send SOAP messages which can in turn be processed through a different XSLT object in an asynchronous thread, but even here, the amount of boilerplate necessary to send such content begins to become mind-numbing.


    I agree with both Paul's thesis and Edd's call to jetison the SOAP specification, especially given the degree to which it has sent other, more significant efforts spinning out of control. No doubt we're about to see the fractionalization of the web standards bodies into the older W3C and the more brash WS-I, but I predict that ultimately the WS-I will end up falling apart of its own poorly designed architectures and the greed of its charter members. I was excited when the W3C was formed, and even more excited when the RAND debacle resolved in favor of Royalty Free licensing. That the WS-I formed shortly thereafter was no accident, but I think that all of the objections that people raised about the danger of RAND technology will in fact manifest themselves very soon.

  • A web service that needs XML input
    2002-05-02 08:14:08 Andy Hickman [Reply]

    Paul,


    Thanks for the article. Some of your
    responses indicate that you've yet to come
    across an example of a web service that
    cannot be achieved using HTTP GET. I'd like
    to make a couple of observations on this.


    Firstly, it's hardly surprising that most
    current web services choose to use a simple
    key-value pair type input - the vast majority
    were either designed to have an HTML form
    front-end (which is where the query part of
    the URL syntax was defined in the first
    place), or are a thin veneer around what was
    previously an HTML based interface (as is the
    case with Google). Even if the HTTP client
    is not a web browser, there is still a strong
    motivation to use HTTP GET on the server side
    since your environment (CGI libraries, or
    whatever you're using on the server) will
    support it. I suspect the advent of web
    services with richer input requirements will
    mean this becomes a less automatic choice.


    Which brings me onto my second observation...


    Here's a stab at defining a web service where
    XML input is useful. (Note, it's not obvious
    to me what the advantage of SOAP is over just
    POSTing the XML, but that's another issue.)
    Let's say Google would like to define a
    richer input capability. For example, they
    want to offer full boolean logic in their
    input, with the ability to represent nesting
    and precedence. Or maybe they decide they
    want some kind of second order logic
    (i.e. you can assign a weight to each search
    term: "XML" = 0.8; "web service" = 0.7;
    "SOAP" = 0.1). Sure, you could cook up some
    kind of flat string representation of the
    input that allows it to be inserted in the
    URL. But this could get quite complex and
    then you've got to carefully specify the
    format and write your own parser. Every
    client has to generate the correct format and
    you end up with a load of interoperability
    problems. It's a lot easier to define an XML
    schema and let the XML parser handle what is
    essentially a structured piece of data. I
    guess the use of XQuery in SOAP requests to
    remote database queries will become an
    extremely common example of this kind of
    thing.



    Finally, a quick comment on the format of the
    results. The reason for the extra verbosity
    is Google's choice to use SOAP encoding
    style. If they chose to use document style
    encoding, then the only difference between
    your format and the SOAP format would be the
    envelope and body elements at either end.
    For all but the tiniest results this
    difference would be insignificant.


    Thanks


    Andy

    • A web service that needs XML input
      2002-05-05 18:53:47 Lucas Fletcher [Reply]

      It's not hard to imagine a simple standardized routine to serialize the XML input data into a unique string, if indeed there is not already a standard out there...

      • A web service that needs XML input
        2002-05-07 11:52:11 Will Provost [Reply]

        Right, you can "stringify" anything. The same could be said of any XML document, but we find our reasons for using XML.


        More to the point of this example, if the boolean logic were allowed to be arbitrarily complex, then the string representation would at least become cumbersome. Also, consider the costs of packing and unpacking that string, and compare to the costs of XML generation and parsing. The "non-XML" solution starts to look a lot like a reinvention of the XML solution. We can call it a "simple" string, but are we really saving time and trouble by staying away from XML?


        As already mentioned, the next question is SOAP vs. posted XML, and I agree that's a separate issue.


  • I think...
    2002-05-01 10:09:30 Ian Parker [Reply]

    ...some people really despise Microsoft. In the context that you are viewing SOAP, yes, HTTP is most likely more efficient. But there are other uses. I do have a question though. Do you think it will be easy to use HTTP in conjunction with a web service written in C#? I am rather new to the programming world so go easy on me.


    And for the people who say it's all about money... You're damn right it is. This is a capitalist society we live in. If you can't handle the heat, get out of the kitchen. It is my sincere hope that Microsoft and all other software corporations NEVER stop pushing the envelope (no pun intended) and always evolve software and standards into something better. Viewed in small steps, some things look like a step backward, but "the road ahead" isn't always mapped out clearly. <G>


    Be well,


    Soukyan

  • let's not pull our punches here
    2002-05-01 02:41:34 Lucas Fletcher [Reply]

    Come on people, isn't it obvious? Writers like Paul Prescod have no choice but to come off sounding like they are explaining something for the fifth time to kindergarteners. It's not his fault, we programmers are so small-picture heads-down oriented that we can't see the obvious, which is:


    At some point MS (maybe at one of their CEO summits) explained to the rest of the corporate world that they too can benefit from API lock-in, just like MS. But to do so, they must find a way to intermediate the resource-based nature of the internet via API's! However! Those programmers you pay so much money for are a fickle bunch. They are wary of writing to closed architectures. You'll definetely have to go through W3C, and you most certainly have to find a way of associating it with XML, even if it is something stupid like XML-defined method declarations. Another tricky point is that it has to be percieved as simple. This can be a problem, because if it is TOO simple then they'll find ways of mapping it to HTTP GETs. So put the word "simple" somewhere in the name, and then make it complicated.


    Telltale sign of propaganda machine in full gear: note how in the MSDN Library XML and Web Services share a title of a section, although XML itself is much larger than what MS calls web services. There are many others if you look for them.

  • XML for analysis
    2002-04-30 06:11:49 Piotr Prussak [Reply]

    Paul,
    although I agree with your article at heart, I also have a feeling that there are other implementations that use SOAP-RPC because other approaches would simply be difficult. Take a look at:
    http://msdn.microsoft.com/library/default.asp?URL=/library/techart/xmlanalysis.htm
    for a concrete example. This is also in support of the Will Provost's question 1. I'm sure that there are also some distributed apps hanging around which warrant the use of SOAP-RPC because of interoperability and complexity of data passed between the nodes.


    As far as Google is concerned, because of relative simplicity of their service, they probably should have offered HTTP/XML interface to the developers as well (account could be also passed in the request header as to abstract the API calls). I also feel that their reasoning for RPC style soap was purely because of backwards compatibility concerns.


    Piotr


    • XML for analysis
      2002-05-22 00:48:36 bryan rasmussen [Reply]

      you know it's been a looong time since I read that, do you know of anyone that actually uses XML for analysis, it struck me as totally bogus and overweight at the time. Could it be that Microsoft has changed their strategy from Embrace,Extend,Destroy to Embrace,Glut,Destroy?

  • Three questions
    2002-04-29 13:32:28 Will Provost [Reply]

    Paul,


    I enjoyed the article very much. It was quite thought-provoking for me, and I find I'm immediately convinced on maybe 90% of the architecture. I'm a Java kind of guy who's nevertheless been cruising down the SOAP road for a while, and now I'm wondering what really is the best solution.


    I have a few questions for you, some technical and one I guess political.


    1. As I understand it, if there's an Achilles heel to the REST architecture it's the inability to pass complex structures as part of a GET request. I see that just about anything can be serialized into a CGI string, but the ability to use XML would have some clear benefits, yes? It would be nice to hook JAXP code up to form a service request, instead of the admittedly trivial coding it takes to string some name=value arguments together. Do you agree that this is a deficiency of at least some magnitude? If so, what would you say is the best strategy? I would prefer an approach that could encode requests the same way every time, but perhaps the practical answer here is that for 95% of one's messages one uses a CGI string and 5% of the time it's necessary to kick over to POST/MIME, or to SOAP.


    2. I like the idea of a resource-based Web extended to provide services, as opposed to the SOAP approach of returning to facades at single URIs. Both sides of this debate seem to have some claim to object-oriented bragging rights: SOAP because it fosters component-based service and REST because it is naturally decomposed into resources which might be considered Web objects with their own state and behavior. I'm not certain what my question is, I guess, but I'd be interested to hear your take on this.


    3. On to the political: Edd Dumbill suggests that the W3C should get out of the Web-service specification process altogether. I see a great deal of industry momentum behind SOAP-based services. I get the sense that there will be some fragmentation between SOAP and pure HTTP services, but that the cost to the industry of failing to standardize (completely and immediately anyway) will not be terribly high -- not as bad a situation as the COM/CORBA split, for instance. As WSDL tooling catches up, and assuming that all bindings are well supported, it should be easy enough for one party to adjust to the other's choice of messaging protocols. The single-vs-multiple-URI mismatch might be a lot trickier, and data encoding is a known issue in any event.


    All this to say: realistically, what do you think is going to happen?


    Thanks again for a really eye-opening article.


    Will Provost




  • XForms vs. REST?
    2002-04-27 16:45:22 Jess Holle [Reply]

    This article brings up some great points.


    Having created several apps based on HTTP URI requests and primarily XML responses (with some other MIME types thrown in for certain requests, of course), I feel torn here. XML provides a much more elegant means of structuring sophisticated input data on the client and parsing it on the server than simple HTTP request parameters. Yet you need a simple HTTP request parameter access to directly use the given resource in countless use cases (bookmarks, XInclude, XSLT document(), AppletContext.showDocument(), etc, etc). It seems that you end up wanting (if not needing) both!


    In case the author is reading this, I believe XForms deserves further examination along these lines as to how it addresses these issues in terms of interoperability with both simple HTTP request parameter I/O and XML I/O -- or did I miss this article?

    • XForms vs. REST?
      2002-04-28 13:37:44 Paul Prescod [Reply]

      "Having created several apps based on HTTP URI requests and primarily XML responses (with some other MIME types thrown in for certain requests, of course), I feel torn here. XML provides a much more elegant means of structuring sophisticated input data on the client and parsing it on the server than simple HTTP request parameters. Yet you need a simple HTTP request parameter access to directly use the given resource in countless use cases (bookmarks, XInclude, XSLT document(), AppletContext.showDocument(), etc, etc). It seems that you end up wanting (if not needing) both!"


      Yes, it is not always trivial to express what you want in a URI rather than in XML. But you really shouldn't need to parse the URI strings "by hand". Your programming language or framework should have tools for doing this, just as it has XML parsing tools.


      "In case the author is reading this, I believe XForms deserves further examination along these lines as to how it addresses these issues in terms of interoperability with both simple HTTP request parameter I/O and XML I/O -- or did I miss this article?"


      XForms is an excellent way to get a web UI to an XML-consuming web service. Note that I'm not against XML-consuming services: I just feel that the proper place for XML is as a representation for the data objects being manipulated and not as a marshalling format for parameters to a method call.


      Paul Prescod


      • XForms vs. REST?
        2002-04-29 03:13:24 jim fuller [Reply]

        'Note that I'm not against XML-consuming services: I just feel that the proper place for XML is as a representation for the data objects being manipulated and not as a marshalling format for parameters to a method call.'


        this smells a little bit,


        marshalling is the process of getting some possibly disparate bits of data--> put em in a buffer of some type--> organise/format as per the requirements of the reciever or programmatic interface. simple definition....


        this is a well known pattern when working between language x and language y....in actual practice marshalling has proven to be inordinately difficult, as the implementation becomes rather specific to lang x and lang y, *because* there has been no agreed upon meta data format between the two; when there is an agreed upon meta data format this becomes easy; look at WDDX for example.


        now that xml is and will be ubiqitous, internally and externally within lang x and lang y or remote procedure blah blah..... the idea of marshalling may change....( why fax when one can irc ? ).


        the key issue, with most xml technologies;


        a) does xml define a process with some sort of xml based language


        or


        b) is xml the substrate or format of this process


        most efforts tend to mix the 2...


        a few examples;


        - in the EXSLT effort, we decided to generate standard *definitions* of functions, instead of binding the actual implementation with the definition. How many times has a simple function like string tokenize function been implemented in how many different languages ?


        - in the XForms effort, there seems to be a lot of implementation specific details, along with generic form definition; mixing of the 2 strategies creates subtle situations, that are confusing for tool developers and authors, i would always like to see clear seperation between definition and implementation ( once again my mouth waters at the UML code generation aspects... )


        - if one views SOAP as an IDL or definition format, then who cares what actually goes over the wire ? you are ( at its simplest ) one transformation away from whatever format that will become. ok, this is simplistic, but what to me is more important is to define a language which defines the process, instead of becoming both definition and implementation.


        - WSDL is currently being adopted because it kind represents the URI in the REST equation for developers and web services users to *use* the service; this seems to be the useful cog in the whole system at present; especially with the auto code generation within the various languages; though i for one can foresee some issues down the line if we continue to use WSDL.


        In almost every situation, i would opt for creating a *definition* in xml format, to give a coherant meta data skeleton which can then be fleshed out with any implementation ( using xml or not ).


        - xml *is* the meta data format of choice


        - having meta data everywhere is useful for assisting in deploying and defining web services


        - the overall process should be defined by an xml language


        The main problem i see is that in a world of SOAP, developers will defined complicated mesaging patterns using the SOAP headers.... which is an example of modeling with implementation, why not use XML pipeline ( on services steriods )to semantically model the marshalling requirements etc.... then have a transformation into DCOM (hehe ) implementation code ?


        cheers, jim fuller






  • Love Paul's cheek when I agree with him :-)
    2002-04-27 10:08:19 Uche Ogbuji [Reply]

    "Later I will show a way to declare the types strongly and statically enough to satisfy the most ardent Java or C# masochist."


    "Readers in California should remind Google that electricity is precious. They could switch to pure HTTP and turn off a couple of wasted server clusters."


    "Google is like the wizard Saruman, a benign and powerful force inexplicably turned from the path of virtue."


    All he needed to add was a good old yo mamma joke, and I'd have been satisfied.


    I won't say whether I find this cheek appealing when I happen to disagree with Paul. :-)


    OK, to my point: this article is a truly brilliant piece of work. It gets ten out of ten possible geek merit badges as far as I'm concerned.


    --Uche


  • correction about lack of documentation
    2002-04-27 06:48:09 Fergal Daly [Reply]

    That old XML was thoroughly documented and is still alive and well. I worked for a company that payed for access to it and we got full documentation of the parameters and the XML that would be returned.


    You can see the search engine (still using that XML API) on every page of


    http://www.iol.ie/


    If you stick an &output=xml on the end of a regular google search, you will see an error message. If you doing this from an authorised IP address you will get XML instead of HTML.


  • well done paul
    2002-04-26 04:16:24 jim fuller [Reply]

    many thx for Mr. Prescod's refreshing counter arguement ( REST appears to be the only existing/emerging contender of any weight ) to 'web' services....basically iterating that the existing internet model ( plus xml of course ) can do all and more that SOAP ( or more specifically SOAP-RPC ) can do.


    I have taken in the pros and cons of the arguement over the past years and must admit I am still confused... but a picture is definately emerging;


    a) there are 1st order benefits; such as using xml which is much more impactful then deciding on using 'WSDL as a wrapper' for http based services. So making the 'wrong' mistake now is less important an issue as it was in the past.


    b) the x in xml means that we will either converge or diverge quicker and easier then in the past; so why not have a heterogenous set of solutions, then migrate.


    c) Why can't Google's API be composed within another remote service that delivers the service in any concievable method.... the key point is that a 'method with meta data' important; the technical details are less important.


    I am not so certain that the most important issue is the development, deployment, and specification of 'web' services; we may see many varied different specifications..... possibly more important is the method by which the services are discovered, composed and ultimately consumed.


    cheers, jim fuller

  • Let's lose XML too!
    2002-04-25 11:49:54 fotios bass [Reply]

    I mean, I am sure I can come up with a more efficient way of putting together my info in a super-packed string (generated in a couple of lines of script btw) instead of using all the XML character bloat.


    Why don't you grow up?


    Fotios

    • Let's lose XML too!
      2002-04-25 12:36:19 Paul Prescod [Reply]

      I would encourage you to re-read the article (if in fact you read it at all before posting). The article says that message size is one of the least important reasons for moving away from SOAP RPC.


      • Let's lose XML too!
        2002-04-26 03:16:48 fotios bass [Reply]

        Hi,


        I have to admit that I only read the first part.


        However, if message size is basically unimportant to your argument why do you bother with it at all and why is it that you mention it first in your article?


        Starting like that, what is the motivation for me to keep reading?


        Fotios

        • Let's lose XML too!
          2002-04-26 16:01:49 Paul Prescod [Reply]

          "However, if message size is basically unimportant to your argument why do you bother with it at all and why is it that you mention it first in your article?"


          I need to show the wire dump so that people understand what SOAP is and is not doing. Message size naturally jumps out at you when you look at the wire dumps. More subtle issues are addressed later.


          "Starting like that, what is the motivation for me to keep reading?"


          Some people just like to learn things. Many people made it to the end. Not, it seems, anyone who was predisposed to criticize the article. With only one exception, their criticisms demonstrate that they didn't read it or didn't understand it.


          • Let's lose XML too!
            2002-04-27 08:55:22 fotios bass [Reply]

            > I need to show the wire dump so that people
            > understand what SOAP is and is not doing.


            sure



            > Message size naturally jumps out at you when
            > you look at the wire dumps.


            When you speak, or more importantly write, do you always say or write what comes naturally? Or do you prefer a more structured, planned, smart way of presenting your arguments?



            > More subtle issues are addressed later.


            too bad



            > Some people just like to learn things.


            and I suppose you are the one to teach them



            > Many people made it to the end.


            Many people watch jackass



            > Not, it seems, anyone who was predisposed to
            > criticize the article.


            Well, I thought you were predisposed to criticize SOAP.


            > With only one exception, their criticisms
            > demonstrate that they didn't read it or
            > didn'tunderstand it.


            You should hold on to this ONE and make him/her your friend, cuz who knows when the next ONE who actually understands you comes along.


            SOAP is good
            Try it
            It keeps you clean




        • Let's lose XML too!
          2002-04-26 03:18:53 Edd Dumbill [Reply]

          If you're willing to take so much time responding in public, you owe it to the author to consider their whole argument.

          • Let's lose XML too!
            2002-04-26 03:22:19 fotios bass [Reply]

            and how much time was that?


            As for the categorical imperative implication, it is less categorical and less imperative than you may think.


            Fotios


            • Let's lose XML too!
              2002-04-29 03:39:50 jim fuller [Reply]

              lets reconsider this persons viewpoint a corner case to the requirements of web services.


              as follows;


              a) our crusader needs something really simple, so he/she can understand it.


              b) our crusader needs us to do all the hard bits of thinking, so he/she can convince someone else ( like potential employers ) that they know what they are talking about; otherwise he/she will have to *learn* how to argue dispassionately about higher level semantics instead of just arguing.


              c) since Microsoft, Sun, IBM and just about every company has decided to dope up all their products with xml technologies, he sees they have made a grave error and his clearness and vision is a lone voice against the evil software empires that we all live in. hurrah


              d) since he has disavowed xml in general, re xml being a bloated format, yet he/she still says SOAP is good and keeps you clean, which of course means that he would like to see web services based on; actual soap products, SOAP on a ROPE being the main protocol, of course.


              e) we are dealing with someone who spent a few years learning COM then DCOM, and now is in a form of technical depression; unable to learn as the medulla stem or frontal lobe is calcifying.


              regards, jim fuller


              • Let's lose XML too!
                2002-04-29 11:35:09 fotios bass [Reply]

                cutlass,


                your nominalist persona coverup attempt did not succeed with me as I could still clearly see what comes after cutl.


                Years of manual name magling and extreme OLE sports have honed my ocular parsing abilities beyond anything you or anyone in your genepool could ever dream of achieving.


                Still, I somehow think that you should direct those of your arguments that do not violate axiomatically established paradoxical constraints to the article proprietor, with soap substituted for xml.


                Who knows? Maybe him and you will one day meet in a steamy shower room where SOAP is dropped.


                Fotios

                • Let's lose XML too!
                  2004-08-10 08:08:07 drennane [Reply]


                  All you seem to be trying to get across in your replies is the fact that your some sort of super intelligent sea of vocabulary... by the way.. there's an "n" in mangling.

  • Rebutting Paul Prescod
    2002-04-25 06:11:49 David Watson [Reply]

    http://davidwatson.org:8086/2002/04/25.html#a101

    • Rebutting Paul Prescod
      2002-04-25 10:13:43 Paul Prescod [Reply]

      David, your article proposes *exactly the same technique* for removing SOAP from the picture that I document at length in the article you are "rebutting". If you use Electric's GLUE to generate HTTP GET bindings then you are *not using SOAP* you are using HTTP and WSDL.


      You've proven exactly the point I made in my article. With a good toolkit (which, according to your description GLUE is) you can use HTTP instead of SOAP and *not even know you are doing so* because the HTTP version is exactly as easy to use as the SOAP version. So what value is SOAP providing?


      By the way, I would be very grateful if you could give me information on whether GLUE can also generate HTTP *clients*. My impression after a few minutes of playing is that it cannot and that is too bad.


      • Rebutting Paul Prescod
        2002-04-26 04:33:00 David Watson [Reply]

        http://davidwatson.org:8086/2002/04/26.html#a104

        • Rebutting Paul Prescod
          2002-04-26 16:16:50 Paul Prescod [Reply]

          Let's first deal with things that I think are incorrect in your post and then I will try to summarize the argument.


          You say: "In the case of Java or C#, writing the HTTP GETs or POSTs long-hand would not produce the ease of use and low implementation cost that the SOAP client libraries provide." This indicates to me that you did not read or did not understand the article. I specifically mention Java and C# and describe how one can use *exactly the same interface* for the HTTP version as if one was working with the SOAP version.


          You say: "In the end, most people will not be concerned with the details of the SOAP/REST mud-slinging, as Joel Spolsky says, they'll be more concerned about the fact that they get an intellisense pop-up in their IDEs when they go to write their clients."


          This further indicates to me that you have not understood the article. WSDL provides the pop-ups, not SOAP. SOAP is a wire protocol. It cannot do anything at design time.



          Let me see if I can characterize our argument.


          We agree that HTTP can be used with many Web services toolkits and basically all language distributions.


          We agree that it is sometimes appropriate to deliver a service on HTTP instead of or in addition to a SOAP version.


          You have not disputed my observation that there are things I can do with an HTTP interface that I *cannot* do the SOAP interface.


          You have not given any examples of things that can be done with Google's SOAP interface but not its HTTP interface.


          Now given that I have things I want to do with the Google project that cannot be done with the current interface, I asked them to reinstate an interface that they had up and running, working, a year ago.


          Rather than agree with me that an additional interface could only enhance the service you accuse me of using "Stop Energy" to try to stop Google from progressing. Oh contraire. I'm trying to help them to be the best Google they can be. Google employees have already told me that I helped them to focus on technical issues that they had not considered and thanked me for doing so. If only their followers were as generous!

          • Rebutting Paul Prescod
            2002-04-29 03:51:35 jim fuller [Reply]

            hehe, your use of a URI to link/view an email message to this list pretty much well illustrates one of the main benefits of the REST model !


            cheers, jim fuller

  • profit the motive?
    2002-04-25 00:08:05 bryan rasmussen [Reply]

    I'm in the camp of those considering the soap implementation a step backwards. Perhaps though, google felt, for whatever reason, that they were better able to control access to their soap-based results than they were to their old http+xml results, the control is obviously necessary in order to extract payment.

    • re: profit the motive?
      2002-04-25 05:31:27 Matt Sergeant [Reply]

      I doubt it. You could equally easily pass in a registration ID in the querystring as you could via the new SOAP interface.


      I'm sure the motive is simpler than that - SOAP has mindshare. And it's a little easier to use than Paul's proposal.

      • re: profit the motive?
        2002-04-27 07:05:19 Fergal Daly [Reply]

        I already wrote a front end to Google's old XML API and I didn't find it in any way difficult.


        Turning a bunch of argument names and values into a URL encoded argument string is just a quick loop in any language, in fact most languages already have a library that handles it for you if you want.


        I agree that it was probably buzzword compliance that prompted the SOAP interface. The profit motive was what made the GET interface pay per use about 1 year ago.