Web Service Discovery Articles

<ul>
            <li>
      <a href="http://msdn.microsoft.com/xml/general/disco.asp">Microsoft's Discovery of Web Services (DISCO) Spec</a>
    </li>
            <li>
      <a href="http://www-106.ibm.com/developerworks/library/ws-ads.html?dwzone=ws">IBM developerWorks: The Advertisement and Discovery of Services (ADS) protocol for Web services</a>
    </li>
            <li>
      <a href="http://eco.commerce.net/specs/index.cfm">eCo</a>, a distributed approach to service discovery.</li>

        </ul>

        <p>
            eCo takes one step I haven't seen the others take. It's placing a lot of emphasis
            on the <a href="http://eco.commerce.net/specs/sem.cfm">semantics of e-commerce markup</a>. To achieve
            true interoperability we need more than just discovery frameworks, we need to ensure that the service
            descriptions are using compatible terminology. This is the problem I have with
        WSDL<sup>

        <a href="http://www.google.com/search?q=%22Web+Services+Description+Language%22" title="Search for more information on Google">G</a>

    </sup>
    , it's
            not expressive enough. It just lists services and their paramaters. But what do those parameters <em>mean</em>?
        </p>


        <p>
            For example, in this <a href="http://sal006.salnetwork.com:83/lucin/email/cemail.xml">WSDL description of
            an email service</a>, which of the four parameters to the SendAnonymousEmailRequest message expect an email
            address and which expects the subject? It's easy if you read English, but I don't know of any automated agents
            that do. If I'm a user and my email application has discovered five services that let me send email how will it
            automatically be able to fill in the parameters correctly? Adding an email datatype won't help, how will it
            distinguish the 'to' address from the 'from' address? This is where all the interesting problems are. Discovery
            infrastructure is yesterday's problem.
        </p>

Permalink: http://blog.iandavis.com/2001/04/web-service-discovery-articles/


Other posts tagged as web-services

Earlier Posts