Sign In/My Account | View Cart  
advertisement


Listen Print Discuss

Web Services: It's So Crazy, It Just Might Not Work
by Clay Shirky | Pages: 1, 2, 3

Human Factors: Advertising, Branding, and Context Errors

WSDL and UDDI are earnest attempts to provide a framework for rigorous business descriptions, but there is no third party to judge the accuracy of the contents of the documents. If WSDL and UDDI are a way to advertise (note the word) the availability of services in order to get customers, then there will be permanent pressure on the creators of those documents to design their descriptions to get the maximum number of subscribers, rather than to create maximum accuracy.

Inasmuch as there is room for open-ended description of services, we'll see the familiar cat-and-mouse game between advertisers' claims and potential customers' interest, thus restoring the need for human judgment on the customers' part -- caveat emptor. And if WSDL and UDDI only work for services that can be unambiguously described, then they'll be limited to that tiny subset of business problems that require no human approval -- calculating shipping costs, looking up Zip Codes, reordering toner. Hardly the stuff of revolution.

Even in the world of completely commodified services, the pressure to advertise will create barriers to seamless interoperability. It has long been possible to upgrade operating systems with new drivers in the background, or provide bookmarkable URLs for complex searches, to take but two examples. Yet when a user installs a new printer, they are still frequently walked through an install routine, because the printer manufacturer wants to brand their service and offer the user other products and services. Likewise, many sites with search engines use POST instead of GET for their forms, so that the users can't bookmark the results, but must go back to the search page, with its attendant ad impression mechanisms.

While commodity services are good for customers, businesses dislike them; even in the cases where Web Services can be used to offer interchangeable services in the background, businesses are unlikely to embrace those functions if it means they lose the ability to brand their products and services.

Finally, even without the pressure to advertise, human factors create subtler difficulties because our minds are so given to intuition and induction, at the expense of predictability and consistency. The real world abounds with examples of these sorts of context errors, where two parties to a conversation operate with different assumptions even when they are trying to communicate clearly.

As an example, the interface to the NYC subway card vending machines offers two flavors of card: Regular Metrocard and Unlimited Ride Metrocard. The Regular metrocard, though, is a misnomer. It allows the user a fixed number of rides, and it was thus analogous in the system designers' minds to the old token system, but for the users, there is nothing more regular about one kind of card than another, since both kinds of cards were introduced at the same time. The change from the users' point of view was from tokens to cards; the distinction that made sense to the system designers has nothing to do with the users' frame of reference.

There's no guarantee that even when the people offering a new service are trying to describe the service unambiguously that they will be able to find a language that the recipients understand, a problem that is well documented by usability theorists like Mark Hurst, Don Norman, and Jakob Nielsen. Just because Web Services dispense with the world of icons and pull-down menus does not make them any less driven by user interfaces or any less susceptible to mismatches between the expectations of sender and recipient.

Web Services can't create a framework in which any two arbitrary applications can interact because XML doesn't provide shared languages, merely shared alphabets. The Web Services stack pushes this shared semantics problem into higher and higher layers without solving it. Humans often cannot create perfectly transparent descriptions even when they are trying to, and they simply won't try when there's an economic incentive to stretch the truth.

Web Services Are Not the Web

The Big Picture notion of Web Services as a way to automate remote transactions is based on a false comparison with the Web. The idea is that Web Services can do for applications what the Web did for publishing if Web Services adopt the Web model (roughly: loosely coupled passing of structured documents) with two minor changes: the documents will not be limited to a predefined set of methods and tags, and the recipients of the data will be other applications, rather than human beings.

The problem is that these are not the minor changes they seemed to be at first. A big part of the reason the Web worked as well as it did is because it had limited methods and tags and because the recipients of the data were human beings.

By using a limited and pre-defined set of methods (GET, POST, and so on) and tags (basic HTML), the Web achieved interoperability between arbitrary clients and servers the same way the stock quote examples do: by defining the data set in advance and by ensuring that all parties adhered to it. (There's even a name for this architecture, REpresenational State Transfer, (REST), and its proponents are seeking to define it well enough to apply it to other kinds of problems.) The very extensibility of XML means that this sort of coordination can never exist in the Web Services world as a whole, and it can only exist in smaller domains where all parties agree in advance to a common set of semantics.

Furthermore, humans are good at pulling information from noise. We are able to extract data we need from badly written, badly formatted web pages. There is no machine in the world that comes close to our ability to comprehend a wide range of inputs. Replacing the human recipient of the data with a computer application involves a huge loss of decoding power on the client side. Humans can be counted on to read between the lines -- applications can't even read the lines themselves. Applications must operate in a domain with narrower semantics than the Web had, not broader ones.

A real comparison with the Web suggests that the Web model is best extended into the application domain not by making it infinitely extensible, but by implementing it in areas where broad agreement on what and how to communicate already exists. Like the Web, in other words, Web Services are likely to work best in areas with predefined methods and vocabularies, where the recipient can be counted on to be able to decode the sender's message.

Private Conversations and Contractual Data

In contrast to the presentation of public and universally interoperable services, Web Services are actually best at automating private, previously negotiated conversations. The idea of unknown but perfectly described capabilities existing out there in the cloud -- at once unfamiliar enough to need to be discovered, tailored and reliable enough to build a business on, and not so critical that they need to be hosted locally -- describes a small and fairly trivial set of possible services. The ASP business ran aground on this issue, and there is no sign that the Web Services solution will work any better.

Where Web Services work beautifully, however, is where the parties involved already agree about interesting things and already have a framework for cooperating or collaborating. This is not the sexy stuff of a consumer revolution. Instead it is a combination of RPC++ and EDI++: automating things like remote database lookups, lowering costs in supply chain management, or providing developer groups easier ways to link applications.

An interesting example of what a group of like-minded developers can do with Web Services is the Blogger, Manila, and Jabber collaboration, which is using XML-RPC. But in this instance, as in all working Web Services examples, there is an existing relationship, and the semantics are already widely shared. Web Services can't replace developers but may let them get through the gritty details faster, once they've worked out the high level agreements.

Web Services is a background technology, a plumbing technology, a way to lower current thresholds, not Yet Another Paradigm Shift. And that in itself is enough to be a big deal. Lowering the effort and costs associated with interoperability is a good goal. Let's just hope the real advantages of sending data between small or private groups doesn't get swamped by the hype of perfect but unachievable automation.

Comment on this articleHideous hype, or an important advance? Share your view on web services 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
  • Web service will work well in application integration, not interoperation
    2003-01-03 16:18:42 Chunbo Huang [Reply]

    Web service is still an integration interface/technology. It is very much like RMI, RPC, Corba, but it will take off due to the following benefits:
    (1) based on HTTP so that it can across the enterprise internal boundary
    (2) language neutral, (corba is also language neutral, but components have to be coupled very closely).
    I agree that web service won't solve the interoperability problem at all. It just move a step further so that interoperability can be achieved on top of web service. Without web service, interoperability would be a harder problem to solve.

  • Web service will work well in application integration, not interoperation
    2003-01-03 16:18:32 Chunbo Huang [Reply]

    Web service is still an integration interface/technology. It is very much like RMI, RPC, Corba, but it will take off due to the following benefits:
    (1) based on HTTP so that it can across the enterprise internal boundary
    (2) language neutral, (corba is also language neutral, but components have to be coupled very closely).
    I agree that web service won't solve the interoperability problem at all. It just move a step further so that interoperability can be achieved on top of web service. Without web service, interoperability would be a harder problem to solve.

  • The Future of WebServices...
    2002-02-12 14:06:36 Christian Hoffmann [Reply]

    Just one word about the article: Excellent.


    There's just something I would like to add: web services are IN FACT an evolution, not a revolution. It's a straight-forward development of RPC-based mechanisms like RPC, CORBA, RMI, etc.


    There are just two differences: 1) now Microsoft is in the boat 2) it (could be)/(is) self-describing. (At least if you're able to read)


    The main problem: web services / SOAP are just programming models for distributed systems, there is NO artificial intelligence in it. So talking about yellow pages as UDDI service is only half of the cake. To interpret outcoming and incoming data is the other one.


    To interpret data in any programming code to obtain a "dynamic invocation client" is impossible, because this would mean to implement a kind of AI.


    Web services are quite ok to realize "atomic" service: like stock quotes and euro calculators.


    You give an input, you get an output and you print out the output. (I would even suggest, to augment web services (or uddi) to add "display information", i.e. a kind of xml-layout-manager-standard for web services to describe in xml, how web service results should be displayed on screen. So to add a kind of Style Sheet mechanisms to web service "result-sets").



    If you move on, to reuse web services to some kind of "chained" web services, i.e. to process the web service result sets in another web service or in a ´client program´, you are obliged to interpret data, to transform data, to manipulate data. And this transformation will be "hard coded". So at least now, you will realize that web services is just another RPC-mechanism. That's why I said before, that a real yellow pages service (like uDDi suggests) doesn't exist. Because normal human beings can use a yellow page to a) find a service, b) to call a service and c) to use a service.


    soap/uddi and web service allow to do a) and b). They don't allow c). Using c) means to code. It means to develop a program around the results of b).


    The only result of all that:
    a) either forget it! or
    b) Create at least an additional "style-sheet" and display mechanism, to create "web forms" to get an input for webservices and to display results as an HTML/WAP-page automatically (dynamically, so you can integrate all kind of webservice on another webpage)
    c) create a programming environment, that enables "dummy users" to create an web service chain by just using "drag-and-drop" mechanisms to choose and interconnect different webservices. So "click and drag" IDEs will be the future of webservices.



    BTW: if you are able to realize b) or c), you will gain billions...


  • Web services not a panacea
    2002-02-08 07:04:03 Zia Tamizuddin [Reply]


    We have to discern between the vision of a technology and its actual implementation. Web services does have a grand vision of automatic interoperability and as rightly pointed out by the author they are higher layers in the web services stack which are yet to be realized.
    But, lets take a step back and view web services from a perspective of the evolution of distributed systems. Sockets provided a means of network communication between two process, but their limitation was a read/write interfaces. To overcome this a layer was added on top called RPC which provided seamless intergration with the centralized models. To overcome issues with tradition RPC mechanism and paticularly with the advent of object-oriented languages another layer was (more or less) on top of RPC and thus came into existense the distributed frameworks like CORBA, RMI and the like. On a continuing basis new services are being added to these frameworks e.g security services. Now with a boom in distributed computing across enterprise firewalls,
    technologists are always looking for ways and means to facilitate this. Web services is a way to achieve this. It is based on open standards and by the very definition of open standards it is "easier" to facilitate communication between two parties. The ubiquity of XML and internet protocols has jump started the concept of web services, it remains to be seen how well the web services mature.
    From a technologist/architects point of view I believe that web services is a logical evolution of distributed computing given the factors effecting this technology.
    I do agree with the authors criticism of the claims of XML being lingua franca

  • Paradigm Shift is in the Eye of Beholder
    2002-01-15 11:30:58 Steven Williams [Reply]

    I can sympathize with Clay's rejection of 'all the hype'. However, once any reasonable person discounts for the well known hype level, aren't we just looking for lowered effort and costs associated with interoperability as described in his last paragraph? How does this justify the reverse hype as typified in the title of the article? If the reduced cost and effort of any advance is significant enough, won't it cross the 'paradigm shift' line?
    Only pundits, writers, and academics discount technologies because they are not perfect yet. If we ignored technologies that were not perfect, Bill would be just another wage slave.




  • Web services = good
    2002-01-08 07:00:52 Doug Alexander [Reply]

    Valid points in the article. I think the EDI portions of the web services has gotten more attention than it deserves. You're right, its hard to get different people and business to standarize but wheres there is enough value, people will. However, I think many people are missing some key points with web services which has gotten me and many companies very excited about it.
    1)Develop shared components that can be used both in web applications and client server applications. Face it, not every application belongs on the internet but many applications can benefit from functionality on the internet. Anyone who has been involved in migrating legacy VB, C++ or whatever code to the internet realizes how drastically different the coding environment is.
    2) By migrating or writing your components as web services you can really leverage your existing investment in code and client server developers. Big difference in the run of the mill c++ or vb developer and a web developer.


    Just my 2 cents.


    Doug

  • Web services will be an OPTION
    2001-11-18 03:31:25 Harish palaniappan [Reply]

    Web Services will stay as an option. They wont rule the web as campaigned. It is going to be a fast to develop, but crude option. The response time, clients get on the services are going to matter a lot, when they are implemented. Companies choosing ease of operability and low cost and time, because of ease of development, will choose Web Services.


    The tools that favour development of web services are going to have a tough time to convince targeted users that web services are worthful options.

    • Web services will be an OPTION
      2001-11-18 03:40:46 Harish palaniappan [Reply]

      I am adding up to my earlier message.


      A Question.
      What happens when a service owner wants to change the service slightly to accomodate changes in business, or probably wishes to the change the business rules specified earlier in the service.


      Do the applications, that used this webservice have to fail, or produce wrong results, since there is no means by which they can co-ordinate with the service providers.


      There seem to be more problems that Web Services have to address.

  • data/information flow
    2001-10-22 00:58:14 carlo tosti [Reply]

    Plumbing works only if any two pipes present to each other the possibility to "lock" Same diameter, male/female..).
    If data are like molecules of water then we can make information appear where is used.


    When data encouter two different pipes then the users are sprinkled with very misleading information :-)

  • Pragmatic but too pessimistic
    2001-10-18 22:15:34 Siddhartha Azad [Reply]

    A well written article which presents a glimpse of a fool's paradise in which many proponents of web-services are livin in these days...but the thing is...every new technology has a beginning. Web-Services is an idea which is not matured enough but promising. Work is being done in the field and this is how any new technology matures. I think IT is going in the right direction, but we shouldn't get too carried away and understand that web-services are yet to evolve!!

  • Right On!
    2001-10-16 14:57:59 Mike Rawlins [Reply]

    A man after my own heart - I'm getting very tired of over-sold hype and it is refreshing to read someone rip the covers off of it with a very cogent, literate analysis.


    Clay, for my own spin on a related topic (ebXML), check out www.rawlinsecconsulting.com - ebXML A Critical Analysis

  • Web Services
    2001-10-10 19:16:02 Bon Truong [Reply]


    I agree with most of what Clay Shirky has said in his article, especially in connection to AI.
    There is still a big misunderstanding out there that XML is the lingua franca that can solve every problem, which is definitely not the case.



    Bon Truong


  • Yes!!! any 'smart' manager (if any exist) must read
    2001-10-09 11:32:24 Ben Hui [Reply]

    I still believe XML and WSDL still an advancement, but only on technological level. Instead of using binary data, let's use XML. Instead of using IDL, let's use WSDL. It does make communication easier, but not automatic, nor magic, nor super flexible.




  • some dreams/hype always comes along !!
    2001-10-09 02:09:59 Jan Lenander [Reply]


    It wasn't anyone inventing the screwdriver without anything similar coming before. Hype just tags along and I am quite sure that soon lots of people will experience Web services as a paradigm shift for them.
    The successes will come where there are less big impact on existing way of working. Now I am very curious if there will come some really creative solution to merge ebXML and XML-RPC into the basic solution set.


    sincere regards Jan Lenander


    PS Just the choice of words "Web services" for an interface indicates a hype.

  • A little harsh
    2001-10-08 07:53:22 Ryan Tomayko [Reply]

    I really like some of the arguments Shirky exposes but at times this article seems harsh. I am in full agreement with the author's description of the unfulfillable promises parts of the industry have attached to web services but at times this article seems to question any value that web services might have at all, which I think is going to far.


    For instance, I don't think anyone with even a little technical background will debate the argument that XML does not create total and automatic interoperability. However, combining XML with standard Internet protocols provides a consistent design pattern for creating distributed applications over previously unimagined boundaries. The author does acknowledge this somewhat but I felt the importance was under exaggerated.


    I also want to note that standards like ebXML, which use web services at the foundation level, have acknowledged a definite "implementation" phase. Where two or more contracted organizations will need to implement either the service logic or the service consumption logic. There is no promise of automagic interoperability there.
    WSDL, UDDI and other vocabularies on the "stack" provide a standard way of documenting web service functionality whether that documentation be used by an engineer or by an application.


    I think this article comes off somewhat as a rant at marketing departments for being uneducated about the technology they're marketing. It's a game of telephone from R&D to marketing and it's nothing new in this industry. Maybe the article should be moved from a community with developer majority to a place where more marketing, sales, and media types will see it.


    - Ryan




  • A complexity problem
    2001-10-07 23:10:07 Nick Duan [Reply]

    When Don Box and the folks from MS and IBM first introduced SOAP, they envisioned a new programming paradigm that overcomes the limitations of DCOM and COBRA as a way to enhance interoperability across platforms and languages. Conceptually, SOAP is still based on the RPC model for distributed object computing. It is obvious that web services inherit the same programming model as COBRA and DCOM, with IIOP replaced by SOAP, IDL by WSDL, and naming and directory services by UDDI.


    COBRA has been around for over a decade and companies still have a lot of problems when trying to adopt this technology. One of the problems with CORBA (or with any RPC-based programming model) is complexity. When business process is large and complexity is high, the RPC based technology tends to fail. That’s why after spending millions of millions of dollars doing CORBA, many companies had to give up COBRA eventually. An asynchronous, messaging-based solution seems to work better than a synchronous, RPC-based one in a large-scale enterprise environment.


    So web services will eventually face an even bigger complexity problem than CORBA if it is intended be used in inter-company, B2B exchange applications.


  • "I speak english, you speak german" analogy
    2001-10-06 22:39:41 George Nava [Reply]

    “The sender is the owner of the data and the dictator of its content and structure”


    Based on this principle we can describe the exchange of information between two companies ‘BUYER’ and ‘SELLER’ as follows:


    BUYER wants to send an electronic Purchase Order to SELLER
    SELLER will send the merchandise along with an electronic Invoice.


    How do they agree in the formats of the documents to be exchanged? Their Applications/databases are completely disparate and therefore, the way they can retrieve/send and receive/understand data are totally incompatible.


    Let’s say that BUYER defines the Purchase Order as:


    <PurchaseOrder>
    <Content>I need two boxes of soap detergent by tomorrow morning</Content>
    </PurchaseOrder>


    If SELLER’s application can understand this document and parse it to its database and produce the respective invoice, then everybody is happy. If not, SELLER must request a redesign of this document giving some ‘possible’ alternatives based on its own data needs, or simply reject any possibility of document exchange with this trading partner.


    Then BUYER agrees to redefine:


    <PurchaseOrder>
    <Item>
    <Quantity>Two</Quantity>
    <Description>Soap detergent</Description>
    <DeliverBy>Tomorrow Morning</DeliverBy>
    </Item>
    </PurchaseOrder>


    Much better, but yet still impossible to understand by SELLER’s application unless they use some sort of Artificial Intelligence Application.



    Now let’s start this scenario again assuming that both trading partners know the basic principles of commerce and data structures, here is the new Purchase Order:


    <PurchaseOrder>
    <OrderNumber/>
    <Buyer/>
    <ShipTo/>
    <BillTo/>
    <DeliverBy/>
    <Commodities>
    <Item>
    <Quantity>
    <PackageCode/>
    <Description>
    <BlaBlaBla/>
    </Item>
    </Commodities>
    </PurchaseOrder>


    As we can see, everybody in the business can easily understand this Purchase Order, but it doesn’t mean that it satisfies all the data needs for all companies out there from small businesses to giant retailers, specially the latest. They require the most unthinkable pieces of data like Special-Offer-Code-Not-Expired-Since-Last-Order or Drop-Off-Terminal-Location-Dock-For-Overnight-Delivery, which would make any attempt to define a universal simple document an extremely confusing and complex monster made of thousands of optional data fields, relations and conditions (any reference to cryptic EDI is mere coincidence)


    Now raises the question, do we want one universal complex document available to everyone and letting everyone spend precious time trying to adapt their businesses to it? Or better yet, five or ten universal documents ranging from the simplest to more complex capable of defining all possible structures of what it is supposed to be a Purchase Order?


    Retaking the example of BUYER and SELLER, the purchase order will do its job of asking for some merchandise to be purchased, not to fulfill SELLER’s needs of their customer tracking, statistical, managerial and decision-taker applications.


    On the other hand, when big fish SELLER submits its electronic invoice gathered from a tenth level normalized database, composed of hundreds of sublevels in a tree-structured XML document, then again, the small fish BUYER will have to spend years trying to understand what was in the mind of the designer of such abstract masterpiece.


    In conclusion, it’s neither the alphabet nor the vocabulary we construct to communicate what make business complicated; it is the different approach we take to accomplish simple tasks as buying-selling.


    "I speak english, you speak german. If you want to talk to me, learn english. If I want your businesses I will learn german, or at least I will use a translator"


    PS. Great article indeed

    • Real scenario for a web service
      2001-10-06 23:58:16 George Nava [Reply]

      Now focusing on a real scenario, let’s talk about a Credit Report Request/Response as a web service. Let’s start identifying the entities involved as Credit Bureaus and Consumers. We all know that there are ONLY THREE mayor bureaus and if they decide to offer this web service I bet my life they will not agree in a common format because everyone of them will try to offer more value for your buck.


      Now, in this free market competition, Equifax to attract more customers will offer three different formats: unbeatable Brief Report for 99cts which will give you only their proprietary credit index just for you to have a quick idea of the consumer creditworthiness, Regular Report for $8 with complete detail of your credit history, and Full Report with your Medical and Driving records for $29.


      Experian, not to be left behind, will offer now 5 different reports, with the most complex detailing all your personal life including the names of all the pets that you have had (for marketing strategies) and how many girlfriends you dated in high school with their names and telephone numbers as references to be confirmed.


      Worst of all, they will restructure their formats every month adding new data to keep their businesses competitive in this fast paced changing world, and they are only THREE providers in a closed scenario.


      Can you imagine trying to request catalogs from the giant retailers? Or just a simple account statement? Have you seen how different are the statements of Best Buy and Target? Do you think they will agree in a common format? Will we, small fish, have to map thousands of different web service responses to a same web service request?


      Conclusion, web services and XML are the best imaginable way to exchange information, but the changing nature of businesses and the clearly explicit word of SERVICE will make it evolve and adapt to satisfy consumers needs. We can’t avoid it.


      All we can do is ask ourselves these questions for every web service available:
      - Tell me what you offer
      - Where/how can I get it
      - How much it is going to cost me
      - How can I understand your response
      - When are you going to update it
      - How much it is going to cost me to update


      And then ask the question again “How much it is going to cost me” to make my applications talk to all the web services my company needs to be technologically on top of the wave, because we all know everything moves around budgets.


  • Business evolution
    2001-10-05 14:36:56 Gary Casey [Reply]

    The web services technology stack will be (already pretty much is) universally accepted, and it is very accessible to developers.


    This acceptance and accessibility will in turn free up business talent and resources to focus more on their business problems rather than worrying about technology choices and colossally expensive development platforms.


    This freedom will allow the creation of the ontologies and interfaces - which business integration needs - to proceed at a much faster rate than before.


    This is the new new thing about web services - that it will enable a much more rapid evolution of the higher level abstractions which only humans can create.


    - Gary

    • Business evolution
      2001-12-14 14:40:43 jorge rodriguez [Reply]

      Even natural languages have a predefined alphabet, and to a certain extent, a finite vocabulary. As humans, we don't go around inventing new words on the fly... how does a an arrengement of alphabetical symbols obtain a certain meaning? What would happen if dictionaries were not around?
      Also can anyone explain to me what "yellow" looks like?


      As far as meaningful RPC is concerned, XML's scope is limited by the boundaries of the enterprise.

  • I'll take "Unkept Computing Promises" for 600
    2001-10-05 08:27:06 Michael Wooten [Reply]

    Nice banter, Clay.


    However, I don't think pointing out that the XML protocols stack (i.e. WSDL, UDDI, etc.)doesn't help solve issues that require "human contemplation or collaboration", makes that much of a case for you. I think the real issue here is that there really are some good practical usages for Web services, but they're pretty hard to see through all the smuggy rose-colored glasses.


    Here's a couple that I'm sure will be "hotly contested":


    1. Crime Scene Assistant - Runs on a PDA or Notebook w/cellular modem. Uses SwA (SOAP with Attachments) to upload images and XMLized police report. O.J. would have been in trouble if this had existed in 1994 ;-)
    2. Operating System tools - Remote "top", Roaming lsDashLer (ls -l), etc. Exploits intermediaries and SOAP-RP.
    3. HTTP Logger - Handle log entry writing and reporting.
    4. Managing the data and scores in multi-player, multi-sport's bar trivia games.


    "Clever simplicity" is what Web services will be best at. They will also be good at being facades for "existing software assets". They will definitely reduce the need to porting software. Personally, I think that trying to push them into complex B2B situations (i.e. supporting long-running, multi-site transactions, etc.) is a highly mis-guided and ill-advised direction. And this notion of "coopetition" amongst "competitors" is about as believable as thinking hacker's haven't already cracked Passport ;-)


    In closing, I think Web services do have a lot of potential, but we'd be better off letting actual business problems dictate future XML protocol stack development, not erudite mussing.


    Signed,
    Happy denizen of the Planet of the "Geeks"

  • What about RDF
    2001-10-05 01:42:26 Kit Davies [Reply]

    Good article, but..


    Isn't the purpose of the W3C RDF project to create a framework in which an ontology for a particular market can be built?
    That solves (or at least helps) the lack of meaning common between XML languages.

    • What about RDF
      2001-10-05 07:27:06 clay shirky [Reply]

      Isn't the purpose of the W3C RDF project to create a framework in which an ontology for a particular market can be built?


      Yes, so XML is a framework for building tools like RDF, and RDF is a tool for building ontologies, but somewhere in there you still have to build the ontology.


      Saying "I have a tool that will better allow all businesses in Industry Foo to agree on a common standard" does nothing to make the members of Foo agree on a common standard, it just means that if they wanted to, they could use RDF.


      In practice what happens is that several competing or overlapping standards get written, and new entrants are suspicious of standards written by existing players.


      Creating technologies that make interoperability possible is a technological issue. Interoperability itself is a business issue.


      -clay

      • What about RDF
        2001-10-05 10:44:45 Shelley Powers [Reply]

        Right on, Clay.


        RDF is a way of recording information about a domain -- you still have to understand the domain. You still have to agree on the domain.


        RDF is no different than a relational data model in that respect. Sure you can use one technology to create a database table -- but of what?


        Several years ago at Boeing I was peripherially involved with the PDES effort. What's this? An effort to create a common business model for manufacturing companies to exchange information with each other through automated processes.


        The same holds for POSC and the oil industry.


        The technology is the easy part -- getting all them competitors to agree on "business", now that's the big nasty.




  • pointer to a reply
    2001-10-04 23:58:41 Julian Bond [Reply]

    I've posted a long reply here http://www.webservices.org/article.php?sid=305&mode=&order=0 and here http://www.voidstar.com/node.php?id=423


    The gist of it is that common business semantics are indeed a major problem, but that doesn't mean that XML-RPC, Xmethods, WSDL, UDDI and so on do not solve other real world problems. Equally, the comparatively trivial implementations at xMmethods don't mean that real world solutions can't be built. And finally, yes, the hype produced by UDDI.org and slavishly re-printed by the analysts and commentators is unfortunate. On the fly integration probably is a pipe dream unless there's a large installed base of a de facto standard. But reducing app to app integration effort from months to hours *is* a huge advance.

  • the future is web services like it or not
    2001-10-04 12:11:36 steve jobs [Reply]

    clay,


    Your points have been made by many others, but you have done a good job of bringing them together. There are two issues here. Firstly, the media and analysts writing about web services don't understand them. Web services are technical beings at the moment, and say in five years time when they will have great application, the analysts should get involved. Your article should remember this, and not downplay web services for what they are, a good attempt are resarting the whole web experience for the end user and business.


    The people with the vision for web services and end users sit at redmond. They understand that web services allow an interaction for the user with the web that is simply not possible with current technology. Hence .Net My Services.


    The other people with a vision for web services are IBM. They understand that web services allow for B2B integration on a new scale. For example, insurance houses can allow quotations to go online as a web services available on any portal quickly and easily. No longer is there a need for endless B2B integration with differen portals. One web services for all! Just think of all the added functionality companies will suddenly be willing to place on the web since it is cheap and works for all.


    Yes, while these leaps forward are not huge, who said they would be (apart from non-techny analysts). Lets all take our time, get on with the job, and realise the future of the web is interoperability and network (aka web services).


    cheers.

    • the future is web services like it or not
      2001-10-04 12:41:34 Mark Baker [Reply]

      Restating what's been said so many times as part of the hype that is "Web Services" is easy, no? Looking into the how and why of the statements behind the hype is the hard part, and is what Clay is attempting here.


      If you want to debate this, wouldn't you do better to address the points he's making?


      MB

      • the future is web services like it or not
        2001-10-05 08:52:34 Margaret Green [Reply]

        I thought livejazz was wellspoken, providing a background and context that grounds a discussion of web services in the knowledge of their origins.


        No, livejazz needn't address Mr. Shirky (whom I admire and respect) on a point by point basis based solely on the article.


        After all the establishment of context is most difficult, as Mr. Shirky points out in the article. livejazz has made a positive contribution by helping refinie the context.

  • Exactly!!
    2001-10-04 10:39:59 Bob Hangsterfer [Reply]

    This article accurately describes the fundamental problems with the Web Services goals. Getting two parties to agree on the exact meaning of data fields is not achievable in the current specification. I've worked with OFX, an XML transaction set transported over HTTP, for 4 years. Whenever I need to integrate a new customer into our "Web Services", which are predefined business transactions, there are weeks of discussions on what each pre-defined field means to us (our system) and to them (their system).
    If you remove the technology, and pretend that SOAP/WSDL/UDDI is just a fancy way of performing FTP with ASCII files, you can reduce the problem of context from that of technology.
    The contextual problem is, "how do I interpret this data field?". If you work in a shop where you have relational tables, imagine someone dropping off a structured file, defined by you, and delivered via FTP into a directory on your your publicly accessible servers. This customer has no prior relationship with you. Now, write a parser that reads this structured file, and populates or retrieves data from your database, and creates a response. Assume you're responsible for exchanging goods and money, and that billing has to occur. And fraud prevention.
    Unless you use fabricated, simplistic examples of free services, like TaxRates, the problem of interpreting the data and the customer's requests is utterly impossible. It only works on the most trivial examples.
    This problem of data sharing has been attempted before. Look at ebXML.org. This is a technology upgrade from the previous method of FTP transmission with structured ASCII files. I've served on councils with this group, and irresolveable discussions always revolve around data interpretation. Always.


    A very well written and accurate article.





  • Yes, excellent! But a common "alpahbet" is still an advance
    2001-10-03 21:39:23 Michael Champion [Reply]

    Perhaps XML is not the "lingua franca" of the Internet, but at least it's the "Latin alphabet". It's hard to communicate without a common language, but it's even harder to communicate in writing without language neutral way to express different languages. What if French, German, and English all had different runes to express the basic phonemes of the individual languages rather than having (more or less) a common alphabet Half the trouble of learning a new language would be learning to parse the meta-language! That's pretty much the state we were in before XML.


    Anyway, XML is not the whole solution, but it lets us focus on the solution rather than the wallowing in the mechanical details of the problem.
    Likewise, SOAP and XML-RPC remove a lot of the mechanical tedium of installing / configuring / tuning / securing / programming CORBA or DCOM-based distributed architectures (by leveraging all the work people do for HTTP). This is not something to be sneezed at ... but neither is it something to be hyped to the stratosphere. I't better plumbing, not a new paradigm! Plumbing is not glamorous, but life without it is smelly and unsanitary!


    I very much liked the bit: "The sad fact is that communicating anything more complicated than
    inches-to-millimeters, in a data space less fixed than stock quotes,will require AI of the sort that's been 10 years away for the past 50
    years. Without AI, the description and discovery of Web Services is going to require a great deal of good old fashioned human intelligence."


    Yup. The web services plumbing simply lets human intelligence focus on what it does best, and leaves the details to SOAP, XML-RPC, UDDI, WSDL, etc. That's all it does, and that's nowhere near what all the hype talks about, but that's plenty for now.





  • Future of ebXML and BizTalk?
    2001-10-03 19:31:04 Prasenjeet Dutta [Reply]

    I think Mr Shirky summed it up very well with "Web Services is a background technology, a plumbing technology" -- its more something lots of MIS mavens -- and a few developers, like the Blogger community -- will get excited about.


    But when you write "These sample services illustrate that it's difficult to create a web service that doesn't rely on both the client and the server understanding the terms of the transaction in advance" -- I have a question: What do you see as the future of systems like ebXML and BizTalk which are trying to define standard vocabularies for all sorts of transactions?


    • Future of ebXML and BizTalk?
      2001-10-04 08:35:14 clay shirky [Reply]

      But when you write "These sample services illustrate that it's difficult to create a web service that doesn't rely on both the client and the server understanding the terms of the transaction in advance" -- I have a question: What do you see as the future of systems like ebXML and BizTalk which are trying to define standard vocabularies for all sorts of transactions?


      There are two things I remind myself when thinking about the future of
      interoperability:


      1. Efficiency always hurts someone.


      Cutting out the middleman isn't great from the middleman's point of
      view, so no matter how technologically sound a particular vision of
      integration or interoperability is, there will always be a constituency
      working against it.


      2. The world is more complex than any possible description of it.


      No matter how brilliant the designer of any particular description is,
      there will always be aspects of the world not included in the
      description, and people who subscribe to alternate descriptions.


      With these two things in mind, I think that attempts to create XML
      descriptions of transactions that everyone will agree on are mainly
      affected by whether the new system reflects the way people already
      think.


      It would be relatively hard to create schema for the selling of persian
      rugs -- the existing classifications of rugs are very ad hoc and don't
      describe appearance or "feel" well, and there are lots of middlemen who
      would resist using such a system. However, it would be relatively easy
      to create schema for ordering toner, where there is a limited and
      well-described set of categories already in existence, and the supply
      chain is shorter.


      Therefore (took a long time to get to your question, sorry), I think
      that BizTalk Accelerators and ebXML schema will meet with very variable
      success. Where they are describing narrow, well-defined domains, they
      will be adopted and used. Where they are trying to describe all possible
      interactions in a wide and homogenous field of transactions
      (entertainment purchases, say, or apartment rentals), they will be
      adopted only slowly and partially, and only by a subset of the possible
      users.


      -clay






  • Excellent Article
    2001-10-03 18:27:55 Michael Rossi [Reply]

    I do believe this is one of the most insightful, accurate and well-written articles I've read in quite a long time. I think Mr. Shirky's dead-on with his analysis and predictions. I do hope though, that people read the entire article and don't just write it off as some Web Services bashing piece. There's real value to Web Services, as noted in the article. But it's good to keep your feet on the ground when reaching for the sky.