UDDI: an XML Web Service

 

Chris Lovett
Microsoft Corporation

December 18, 2000

Contents

What XML Do You Post? How Do You Post the XML? What Do You Get Back? How Well Does It Work? Conclusion

UDDI drill down example (Requires Internet Explorer 5.x)

The Universal Description, Discovery, and Integration (UDDI) Service is now up and running at Microsoft, IBM, and Ariba. This is an online Web Service that you can use from your applications to dynamically discover other online services, all neatly packaged in a simple XML interface.

For Extreme XML readers, passing XML around between client application and middle tier servers is nothing new. We've been doing this since 1998. It is nice, however, to see ongoing industry momentum in this direction that results in useful services like this one.

So let me just dive right in to the nitty-gritty. All you really need to know is the URL to post the XML to. It took some digging to find the following three URLs:

These are the UDDI entry points for "INQUIRIES". The entry points for updates are different and are typically HTTPS addresses for security reasons.

What XML Do You Post?

First of all, the XML has to be in UTF-8 (a deliberate simplification made by the UDDI project) and has to be wrapped in a SOAP envelope. The SOAP envelope looks like this:

<?xml version='1.0' encoding='UTF-8'?>
<Envelope xmlns='https://schemas.xmlsoap.org/soap/envelope/'>
<Body>...</Body>
</Envelope>

The contents of the <Body> element can be any query from the uddi schema. For example, the following query, when placed inside the <Body> of the SOAP envelope returns the details on Microsoft:

<find_business generic="1.0" xmlns="urn:uddi-org:api">
    <name>Microsoft</name>
</find_business>

Notice we switch namespaces from the SOAP namespace to the "urn:uddi-org:api" namespace. There are many other things you can do in a find_business query.

How Do You Post the XML?

Well, from a JScript file or HTML page you can use the XMLHTTP control provided by MSXML as follows:

   http = new ActiveXObject("Microsoft.XMLHTTP");
   http.open("POST", url, false);
   http.setRequestHeader("Accept","text/xml");
   http.setRequestHeader("Cache-Control","no-cache");
   http.setRequestHeader("SOAPAction",'""');
   http.send(msg);

In this case I decided to be a good SOAP citizen by setting the SoapAction in the HTTP Header. I also decided to accept only text/xml results and turn off all caching, since I want live results every time. Of course, in my attached sample code I do this asynchronously using the onreadystatechange callback.

What Do You Get Back?

Well, XML of course. In this case you get a detailed listing of <businessInfo> elements currently registered for Microsoft, which includes information about the UDDI service itself.

<businessList generic="1.0" operator="Microsoft Corporation"
    truncated="false" xmlns="urn:uddi-org:api">
  <businessInfos>
    <businessInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3">
      <name>Microsoft Corporation</name>
    <description xml:lang="en">Empowering people through great software -
    any time, any place and on any device is Microsofts vision. As the worldwide
    leader in software for personal and business computing, we strive to produce
    innovative products and services that meet our customer's </description>
    <serviceInfos>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                        serviceKey="1FFE1F71-2AF3-45FB-B788-09AF7FF151A4">
          <name>Web services for smart searching</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="8BF2F51F-8ED4-43FE-B665-38D8205D1333">
          <name>Electronic Business Integration Services</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="611C5867-384E-4FFD-B49C-28F93A7B4F9B">
          <name>Volume Licensing Select Program</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="5DE3CE59-923E-42D3-B7FB-34FC3C3CBC16">
          <name>Technet</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="24E553C3-7E3E-484A-8ECA-80E0D0B4A91F">
          <name>Microsoft Developer Network</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="77DD86E5-CD70-4219-A28C-37231EAF3901">
          <name>Online Shopping</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="0860E130-D4AF-4BD5-9F5C-D7F6FA4B1AD8">
          <name>Home Page</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
          <name>UDDI Web Services</name>
        </serviceInfo>
        <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                     serviceKey="A8E4999A-21A3-47FA-802E-EE50A88B266F">
          <name>UDDI Web Sites</name>
        </serviceInfo>
      </serviceInfos>
    </businessInfo>
  </businessInfos>
</businessList>

From here you can drill in and get information about one specific service. For example, let's drill in on the UDDI Web Service. You can take the businessKey from the above results and use <find_service> to look up a service by name:

<find_service generic='1.0' xmlns='urn:uddi-org:api'
    businessKey='0076B468-EB27-42E5-AC09-9955CFF462A3'>
    <name>UDDI Web Services</name>
</find_service>

This returns the information about this service:

<serviceList generic="1.0" operator="Microsoft Corporation"
        truncated="false" xmlns="urn:uddi-org:api">
  <serviceInfos>
    <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                    serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
      <name>UDDI Web Services</name>
    </serviceInfo>
  </serviceInfos>
</serviceList>

Then you can use the serviceKey to get the details about this particular service:

<get_serviceDetail generic='1.0' xmlns='urn:uddi-org:api'>
    <serviceKey>D2BC296A-723B-4C45-9ED4-494F9E53F1D1</serviceKey>
</get_serviceDetail>

This returns the following <bindingTemplates>:

<serviceDetail generic="1.0" operator="Microsoft Corporation"
    truncated="false" xmlns="urn:uddi-org:api">
  <businessService businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
                   serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
    <name>UDDI Web Services</name>
  <description xml:lang="en">UDDI SOAP/XML message-based programmatic web
  service interfaces.</description>
  <bindingTemplates>
    <bindingTemplate bindingKey="313C2BF0-021D-405C-8149-25FD969F7F0B"
                     serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
      <description xml:lang="en">Production UDDI server,
      Publishing interface</description>
    <accessPoint URLType="https">https://uddi.microsoft.com/publish</accessPoint>
    <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey="uuid:64C756D1-3374-4E00-AE83-EE12E38FAE63">
        <description xml:lang="en">UDDI SOAP Publication Interface</description>
      </tModelInstanceInfo>
      </tModelInstanceDetails>
    </bindingTemplate>
    <bindingTemplate bindingKey="A9CAFBE4-11C6-4BFE-90F5-595970D3DE24"
        serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
      <description xml:lang="en">Production UDDI server, Inquiry interface</description>
      <accessPoint URLType="http">http://uddi.microsoft.com/inquire</accessPoint>
      <tModelInstanceDetails>
        <tModelInstanceInfo tModelKey="uuid:4CD7E4BC-648B-426D-9936-443EAAC8AE23">
          <description xml:lang="en">UDDI SOAP Inquiry Interface</description>
        </tModelInstanceInfo>
        </tModelInstanceDetails>
      </bindingTemplate>
    <bindingTemplate bindingKey="3FE6C834-293E-4341-AF6E-41DC68949764"
                     serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
      <description xml:lang="en">Test UDDI server, Publishing interface</description>
      <accessPoint URLType="https">https://test.uddi.microsoft.com/publish</accessPoint>
      <tModelInstanceDetails>
        <tModelInstanceInfo tModelKey="uuid:64C756D1-3374-4E00-AE83-EE12E38FAE63">
          <description xml:lang="en">UDDI SOAP Publication Interface</description>
        </tModelInstanceInfo>
        <tModelInstanceInfo tModelKey="uuid:F372E009-F372-429C-A09A-794113A5C5F9">
          <description xml:lang="en">urn:microsoft-com:test-signature-element -
          signifies that this is a testing version of the service</description>
          </tModelInstanceInfo>
        </tModelInstanceDetails>
      </bindingTemplate>
    <bindingTemplate bindingKey="8ED4AD10-C63B-495E-8969-B3938F86E937"
                     serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
      <description xml:lang="en">Test UDDI server, Inquiry interface</description>
      <accessPoint URLType="http">http://test.uddi.microsoft.com/inquire</accessPoint>
      <tModelInstanceDetails>
        <tModelInstanceInfo tModelKey="uuid:4CD7E4BC-648B-426D-9936-443EAAC8AE23">
          <description xml:lang="en">UDDI SOAP Inquiry Interface</description>
        </tModelInstanceInfo>
        <tModelInstanceInfo tModelKey="uuid:F372E009-F372-429C-A09A-794113A5C5F9">
          <description xml:lang="en">urn:microsoft-com:test-signature-element -
          signifies that this is a testing version of the service</description>
          </tModelInstanceInfo>
        </tModelInstanceDetails>
      </bindingTemplate>
    </bindingTemplates>
  <categoryBag>
    <keyedReference keyName="KEYWORD" keyValue="API"
        tModelKey="uuid:A035A07C-F362-44DD-8F95-E2B134BF43B4"></keyedReference>
    <keyedReference keyName="KEYWORD" keyValue="SOAP"
        tModelKey="uuid:A035A07C-F362-44DD-8F95-E2B134BF43B4"></keyedReference>
    <keyedReference keyName="KEYWORD" keyValue="XML"
        tModelKey="uuid:A035A07C-F362-44DD-8F95-E2B134BF43B4"></keyedReference>
    </categoryBag>
  </businessService>
</serviceDetail>

Now you can see that we are starting to get some very rich information about the online Web Service itself. This tells us that there are actually four access points, two test access points on http://test.uddi.microsoft.com and two production access points on http://uddi.microsoft.com. It also tells us that the UDDI inquiry access points are publicly addressable via HTTP and that the publish access points are under HTTPS protection.

You can also use the tModelKey information to find all registered businesses that provide a UDDI Web Serice as follows:

<find_business generic='1.0' xmlns='urn:uddi-org:api'>
   <tModelBag><tModelKey>uuid:4CD7E4BC-648B-426D-9936-443EAAC8AE23</tModelKey></tModelBag>
</find_business>

This returns the <businessInfos> for Microsoft and IBM. Ariba is not returned because the Ariba <tModelInstanceDetails> don't seem to be available yet.

How Well Does It Work?

I found that there are some annoying differences between the Microsoft and Ariba implementations. For example, the Ariba implementation requires the UTF-8 to be in uppercase and cannot handle extra whitespace in the XML declaration.

Quirks like this will have to get ironed out in order for these services to become fully interoperable. I found that the response times are pretty good, but the data seems to be a bit out of sync. I hope the synchronization gets better over time.

Conclusion

If you're building applications that need to dynamically wire up to services provided by external business partners, then you definitely need to think about wiring your applications to the UDDI registry. Think of it as though it were DNS for the business application layer. The interesting thing is that you could add, change, and remove access points in real time and thereby work around the one week or more delay involved in DNS propagation.

Many people are asking what to do after finding a company and its registered services in the UDDI directory. Well, UDDI does not claim to solve everything. Attempting to spec out the master business-to-business protocol that encompasses everything ever invented is a huge undertaking and probably will never happen. The UDDI theory is that your applications will know how to do business with some well-known kinds of business protocols, and these protocols will be described in a well-known way so that you can dynamically find other businesses that support that protocol. Alternatively, you may have a small number of well-known, trusted global business partners with whom you are simply using UDDI to find new services provided by those partners. In this case, you probably already have other trusted channels established for downloading the adapters needed to connect to each service.

Bottom line: UDDI is definitely a big step in the right direction.

Chris Lovett is a program manager for Microsoft's XML team.