UDDI and WS-I Basic Profile - on the subject of encoding

Lately I've been using some time on UDDI and during my post on case-insensitivity on encoding declations on XML documents I came across WS-I Basic Profile that I haven't looked at for some time. In this post i touch on some the surprises on UDDI, WS-I BP and encoding. The most recent BP document (version 1 branch) is Basic Profile Version 1.2, Working Group Approval Draft (2007-10-24)

describes the relation to UDDI in 5. Service Publication and Discovery:

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages whose envelopes are encoded in either UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) That there should be such a discrepancy is hardly surprising given that UDDI V2 was designed and, in many cases, implemented before the Profile was developed. UDDI's designers are aware of UDDI V2's nonconformance and will take it into consideration in their future work.

i don't agree on their evaluation since the XML Specification demands that XML Processors should support both UTF-8 and UTF-16. More important it's still stuck on UDDI V2.0, which is sort of all right since the other standards are frozen as well. But there's a new version on it's way that can read in Basic Profile Version 2.0, Working Group Draft (2007-10-25). The difference between the version 1 and 2 branch is descibed in 1.3 Compatibility with Basic Profile 1.1 and 1.2:

The Basic Profile 2.0 is the first version of the WS-I Basic Profile that changes the version of SOAP in the profile scope from SOAP 1.1 to the W3C SOAP 1.2 Recommendation. As such, clients, servers and the artifacts that comprise a Basic Profile 1.0, 1.1 or 1.2 conformant application are inherently incompatible with an application that is conformant with the Basic Profile 2.0. However, in general, the Basic Profile WG members have tried to preserve in the Basic Profile 2.0 as much consistency with the guidance and constraints of the Basic Profile 1.0, 1.1 and 1.2 as possible. This has been in part facilitated by the fact that the WG tried to remain consistent in the guidance and constraints of the original Basic Profile with the decisions that were being made in the context of the W3C XML Protocols WG as they were concurrently working on the SOAP 1.2 specificatons. For the most part, issues that were resolved in the context of the development of the Basic Profile 1.0, 1.1 and 1.2 were not revisited.

It's still a WSDL 1.1 thing (not that it's a problem to me) and on UDDI it's the same section 5. Service Publication and Discovery with what looks like the identical content.

One simple conclusion is that if you are relying on UDDI V3.0, you've in principle denied yourself the WS-I Conformance badge (UDDI Conformance claim).

Encoding requirements in UDDI V3.0

One interesting question is whether UDDI V3.0 has changed to WS-I conformance on the mentioned issue. The answer is in section 4.2 XML Encoding Requirements:

All messages sent to and received from UDDI nodes MUST be encoded in either UTF-8 or UTF-16, and MUST specify the Hyper Text Transport Protocol (HTTP) Content-Type header with a charset parameter of "utf-8" or "utf-16" respectively and a content type of text/xml. Other encoding name variants, such as UTF8, UTF_8, etc. MAY NOT be used.

First there's no issue anymore and second It's funny to see both upper and lower case used in the same paragraph, and since the values for charset parameters are given in quotes it looks like it's normative? Nope - in the next paragraph:

All parts of the Content-type header are case insensitive and quotations are optional.

With a reference to Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies though I think RFC 3023 is another good place look XML Media Type. The lat little thing is consequent use af lower case for charset and upper case on the encoding declation in the XML declaration, in ex. 4.1.1 Support for SOAPAction.

Hearing of Danish OIO UDDI Profile Version 1.1 - is the UDDI flower about to bloom?

I remember reading about how UDDI was about to change the way business is run in my first .NET book on C# (version 1.0 of course). The story went something like this: a tired developer that sat in his hotel room and wanted to find a place to eat of his preferences. He would pick up his devlopment tool, search the local UDDI (with the correct paramters - that's tModels) after that he would simply order the table online with web services. Though this is an amazing scenario, it was terrible naive and as such almost dumb. I'll not deny that something similar can be done today or in the near future, but not in a general scope and for certain not with UDDI at it's core. UDDI do have other uses and I guess in the intranet senario it does have penetration, wheres the extranet has mainly seen the big players shutting down the DBR. There is some description of how UDDI has evolved and possible use cases in the Oasis paper UDDI Executive Overview: Enabling Service-Oriented Architecture [PDF](October 2004).

As I've put into the title of this post, with a bit of drama, taken that UDDI is up for it the extranet scenario might become real in a foreseeable future. The good folks of CSI in DNITA has annonced the hearing of the Danish OIO UDDI Profile Version 1.1 (In [PDF] or [DOC]). I'll gladly admit that I haven't figured it all out yet, and I'm curious about what happened to version 1.0, that I've never seen, but the closest was Address resolving service, version 0.8 that was published about 1½ year ago.

To get a 10.000 ft overview over where this fits in a larger picture, you can read the timeline in Visioner og milepæle for serviceorienteret infrastruktur [PDF](Danish only, the title is "Visions and milestones for a service-orienteret infrastructure"). Another great source is the Architecture document that's mentioned in the short reference section which you'll probably need to consult. For my own convenience I've add them here with links:

• [OIOSI-ARCH]: The Architecture of the Danish OIO Service Oriented Infrastructure - Draft version 0.8 [PDF] (In English). A very good introduction to what they are trying to achieve.
• [UDDI-3.0]: UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, Dated 20041019 [HTML]. They just reference version 3 from 2002, but I guess the difference is minimal and just a typo.
• [UDDI-WSDL]: Technical Note: Using WSDL in a UDDI Registry, Version 2.0.2 [HTML].
• [RASP]: OIO Reliable Asynchronous Secure Profile 1.0 [PDF] (English). Once again I'm a little confised about the versioning, since in the document it says version 1.1, but I can only find the hearing version of 1.0

And they forgot a reference for:

• OWSA model T version 1.0 [PDF] - OIO Web Service Arkitektur model Transportbaseret sikkerhed (danish only)

The document contains some examples of using the UDDI Inquiry API, that I've fleshed out to XML-documents:

• find_service.xml
• serviceList.xml
• get_serviceDetails.xml
• serviceDetail.xml
• get_tModelDetail.xml
• tModelDetail.xml

REST API (GET) for UDDI entities - does anyone implement it?

The webservice API for UDDI isn't pure SOAP, there's also a little REST part, though calling it an API for itself would be an exaggeration since it only enables aminor part of the SOAP API, that for retrieving the basic entities. It's and optional feature (may but for some reason not with capital letters) and described in Section 6.5 HTTP GET Services for UDDI Data Structures :

A node may offer an HTTP GET service for access to the XML representations of UDDI data structures. If a node offers this service, the URLs should be in a format that is predictable and uses the entity key as a URL parameter.

The RECOMMENDED syntax for the URLs for such a service is as follows:

If a UDDI node’s base URI is http://uddi.example.org/mybase, then the URI http://uddi.example.org/mybase?<entity>Key=uddiKey would retrieve the XML for the data structure whose type is <entity> and whose key is uddiKey. For example, the XML representation of a tModel whose key is "uddi:tempuri.com:fish:interface" can be retrieved by using the URL http://uddi.example.org/mybase?tModelKey=uddi:tempuri.com:fish:interface.

In the case of businessEntities, the node MAY add these URIs to the businessEntity’s discoveryURLs structure, though this is NOT RECOMMENDED behavior as it complicates the use of digital signatures.

First example - Global Biodiversity Information Facility UDDI Registry

An example of a registry supporting the HTTP GET Services is theGlobal Biodiversity Information Facility UDDI Registry. The documentation contains a very nice presentation of the UDDI data structures in XML Schema in a fashion very like JavaDoc. On the frontpage the product and version number is given "GBIF UDDI is powered by Systinet (c) WASP 4.6 UDDI engine" - doing a HTTP GET returns the following headers:

wget --no-check-certificate -S https://registry.gbif.net/uddi/web
--22:10:38--  https://registry.gbif.net/uddi/web
Resolving registry.gbif.net... 192.38.28.80
Connecting to registry.gbif.net|192.38.28.80|:443... connected.
WARNING: cannot verify registry.gbif.net's certificate, issued by
  `/C=DK/ST=Copenhagen/L=Copenhagen/O=GBIF Secretariat/OU=ICT/CN=registry.gbif.net/emailAddress=helpdesk@gbif.org':
  Self-signed certificate encountered.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Tue, 23 Oct 2007 20:10:38 GMT
  Server: Systinet WASP Server for Java/4.6.1 (Java/1.4.1_03; Linux/2.4.21-52.ELsmp)
  Content-type: text/html; charset=UTF-8
  Connection: close
Length: unspecified [text/html]

That confirms this. Not exactly the newest versions, Linux 2.4 kernel, Java 1.4 and WASP server that seems to have run though two major releases in the meantime. I also find that it's run from Copenhagen.

Doing a browse search and choosing 'Australian National Insect Collection, CSIRO Entomology' gives:

Activating The View as XML button, implemented as:

<input value="View as XML" 
       class="button" 
       type="button"
       onclick="displayXMLDirect("businessKey","06bbd2a0-671b-11d8-b9b2-b8a03c50a862",'')">

using a simple JavaScript function defined in http://registry.gbif.net/uddi/web/data/uddi.js:

function displayXMLDirect(paramName, paramValue, authinfo) {    
    window.location = "?"+paramName+"="+paramValue+"&authInfo="+authinfo;    
}

For my own preference I would have skipped the JavaScript and just made the link (HTTP GET) directly - simpler and more accessible. Any way the raw XML describing the Business Entity Australian National Insect Collection, CSIRO Entomology

<?xml version="1.0" encoding="UTF-8"?>
<businessEntity authorizedName="provider"
  businessKey="06bbd2a0-671b-11d8-b9b2-b8a03c50a862" operator="GBIFS">
  <discoveryURLs>
    <discoveryURL useType="businessEntity">http://registry.gbif.net:8009/uddi/web?businessKey=06bbd2a0-671b-11d8-b9b2-b8a03c50a862</discoveryURL>
  </discoveryURLs>
  <name xml:lang="en">Australian National Insect Collection, CSIRO Entomology</name>
  <description xml:lang="en">http://anic.ento.csiro.au/</description>

Obviously there's either a configuration error or some redirecting going on since I can't access discoveryURL running on port 8009. A similar problem can be found in the old OIO UDDI based on another product so this is obviously a general problem.

Second example - OIO e-Business Registry

Abother UDDI is the OIO e-Business Registry, that can be accessed as Oracle Application Server Service Registry 10.1.3.1 (don't use the Business Control Center that is another interface to the same data, though I haven't figured out the real diffenrence). Choosing 'Search' gives the simple search page:

Doing a wildcard/browse search and choosing KMD Gateway SKI 0.7 - 04:

But I can't call this as raw XML with the HTTP GET as described in the UDDI version 3 specification:

http://publish.uddi.ehandel.gov.dk/registry/uddi/web?businessKey=uddi:5cf0ef10-7c94-11dc-89b4-ca0ca711898a

gives an error page similar to this:

But through the button on the page, that's a link enabled image:

<a href="javascript:submitToURL('form','/directGetXml','root##465195',-1,false,'https://publish.uddi.ehandel.gov.dk:12443/registry/uddi/web');;void(0);" .....</a>

this is worse than the older version, since is all JavaScript but based on href and not onClick. The JavaScript function is defined in wf.js (port 12443):

// submits page to url
function submitToURL (formName, targetTask, actionID, targetDepth, redirect, targetURL)
{
  document.forms[formName].action = targetURL;
  submitPage(formName, targetTask, actionID, targetDepth, redirect);
}

// submits page
function submitPage (formName, targetTask, actionID, targetDepth, redirect)
{
  if (checkFields(formName,actionID)) {
    document.forms[formName].elements['actionId'].value = actionID;
    document.forms[formName].elements['targetTask'].value = targetTask;
    document.forms[formName].elements['targetDepth'].value = targetDepth;
    document.forms[formName].elements['redirect'].value = redirect;
    document.forms[formName].submit();
  }
}

which relates to this form:

<form name="form" method="POST" >
<input type="hidden" name="actionId"/>
<input type="hidden" name="targetTask"/>
<input type="hidden" name="targetDepth"/>
<input type="hidden" name="redirect"/>

The values were:

• formName='form'
• targetTask='/directGetXml'
• actionID='root##465195'
• targetDepth=-1
• redirect=false
• targetURL='https://publish.uddi.ehandel.gov.dk:12443/registry/uddi/web'

So it can be POST'ed and that might not be true REST or according to what the specification suggests, but it can done by ex. curl or a simple form on another web page. I haven't tried to access it with GET, but it might work.

Does anyone implement it?

In fact it would be more interesting to know whether anyone uses it, but the two examples I've looked at here does both implement it (both systinet products), in diffent ways, I haven't used UDDI for a real business case or development so I can't way whether is a great feature or just a possible feature.

Searching UDDI version 3 with the browse pattern - wildcards and findQualifiers

It's been some since I last looked at UDDI, but the availability of the new OIO e-Business registry has awaken my interest once again. The old OIO UDDI supported only version 2 (see for example my post Using the ISB UDDI #1), whereas the new one supports UDDI version 3. In this post I'll walk through how to do a simple search for all tModels in a version 3 registry by using the web service API that comes with UDDI.

The WSDL for the Inquiry API

The new registry does have a correct Inquire WSDL that supports no less than the ws API's for all three version:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <definitions name="UDDI_API_V3"
    3              targetNamespace="urn:uddi-org:api_v3generated/"
    4              xmlns:tns="urn:uddi-org:api_v3generated/"
    5              xmlns="http://schemas.xmlsoap.org/wsdl/">
    6 
    7   <import namespace="urn:uddi-org:api_v2"
    8           location="http://publish.uddi.ehandel.gov.dk:80/registry/uddi/inquiry/2.0/wsdl" />
    9 
   10   <import namespace="urn:uddi-org:api_v3"
   11           location="http://publish.uddi.ehandel.gov.dk:80/registry/uddi/inquiry/3.0/wsdl" />
   12 
   13   <import namespace="urn:uddi-org:inquiry"
   14           location="http://publish.uddi.ehandel.gov.dk:80/registry/uddi/inquiry/1.0/wsdl" />
   15 
   16 </definitions>

I have no idea about challenges with backwards compatibility, but it is covered by the specification. The only confusion here is that we're doing inquiry and an endpoint with the host name on publish.uddi.ehandel.gov.dk but I guess the meaning like it's the production site, where it's public available and as such published. The WSDL for the inquiry API in version 3:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <definitions name="UDDI_API_V3"
    3              targetNamespace="urn:uddi-org:api_v3"
    4              xmlns:tns="urn:uddi-org:api_v3"
    5              xmlns:api_v3_binding="urn:uddi-org:api_v3_binding"
    6              xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    7              xmlns="http://schemas.xmlsoap.org/wsdl/">
    8 
    9   <documentation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   10                  xmlns:api_v3_binding="urn:uddi-org:api_v3_binding"
   11                  xmlns:tns="urn:uddi-org:api_v3">
   12     Copyright 2001-2005 Systinet Corp. All rights reserved. Use is subject to license terms.
   13 
   14     WSDL SOAP/HTTP binding for UDDI V3 Security, Publication and Inquiry APIs.
   15   </documentation>
   16 
   17   <import namespace="urn:uddi-org:api_v3_binding" location="uddi_api_v3_binding.wsdl" />
   18 
   19   <service name="UDDI_Inquiry_SoapService">
   20     <port name="UDDI_Inquiry_PortType" binding="api_v3_binding:UDDI_Inquiry_SoapBinding">
   21       <soap:address location="http://publish.uddi.ehandel.gov.dk:80/registry/uddi/inquiry" />
   22     </port>
   23   </service>
   24 
   25   <service name="UDDI_Publication_SoapService">
   26     <port name="UDDI_Publication_PortType" binding="api_v3_binding:UDDI_Publication_SoapBinding">
   27       <soap:address location="urn:unknown-location-uri" />
   28     </port>
   29   </service>
   30 
   31   <service name="UDDI_Security_SoapService">
   32     <port name="UDDI_Security_PortType" binding="api_v3_binding:UDDI_Security_SoapBinding">
   33       <soap:address location="urn:unknown-location-uri" />
   34     </port>
   35   </service>
   36 
   37 </definitions>

The endpoint is given, and I'm ready to next step.

Not that it's significant, but it's a little confusing that the Security and Publish is also mentioned here (under 'Inquiry'), though without specific endpoints.

Coding the ws client with Axis2

Want to search the UDDI by programming? No problem, take the WSDL and run it through your favorite WS-tool, create your search Class and you're done ready to do the search. That was what I did with the Axis2 nightly, and with my preferred binding XmlBeans - well done Axis2 committers!

I could probably have used the Systinet Oracle Java API for the registry, but I don't see much use for it - yes there could be nice utility methods etc. but I don't need them.

The first quick search - uhmm, is it really empty?

Based on my earlier experience with the version 2 Inquiry programmers API, I knew that '%' is used as wildcard, so I decided to do a search on all tModels. In the UDDI version 3 specification this is called the browse pattern which is spot on:

Software that allows people to explore and examine large quantities of data requires browse capabilities. The browse pattern characteristically involves starting with some broad information, performing a search, finding general result sets and then selecting more specific information for drill-down.

The request went like:

    1 <?xml version='1.0' encoding='UTF-8'?>
    2 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    3   <soapenv:Body>
    4     <urn:find_tModel xmlns:urn="urn:uddi-org:api_v3">
    5       <urn:name>%</urn:name>
    6     </urn:find_tModel>
    7   </soapenv:Body>
    8 </soapenv:Envelope>

And the response:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
    3   <Body>
    4     <tModelList xmlns="urn:uddi-org:api_v3">
    5       <listDescription>
    6         <includeCount>0</includeCount>
    7         <actualCount>0</actualCount>
    8         <listHead>1</listHead>
    9       </listDescription>
   10     </tModelList>
   11   </Body>
   12 </Envelope>

Uhmmm, this couldn't be true, so either I was doing something wrong or there would have to be some policy hiding all results for me - it naturally was the former. As described in the next section, in version 3 I have to add a specific FindQualifier in the request:

    1 <?xml version='1.0' encoding='UTF-8'?>
    2 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    3   <soapenv:Body>
    4     <urn:find_tModel xmlns:urn="urn:uddi-org:api_v3">
    5       <urn:findQualifiers>
    6         <urn:findQualifier>uddi:uddi.org:findqualifier:approximatematch</urn:findQualifier>
    7       </urn:findQualifiers>
    8       <urn:name>%</urn:name>
    9     </urn:find_tModel>
   10   </soapenv:Body>
   11 </soapenv:Envelope>

And now i get results, a lot in fact (1,4 MB/27729 lines of pretty print XML), as this snippet shows:

    1 <?xml version="1.0" encoding="utf-8"?>
    2 <tModelList xmlns="urn:uddi-org:api_v3">
    3   <listDescription>
    4     <includeCount>6929</includeCount>
    5     <actualCount>6929</actualCount>
    6     <listHead>1</listHead>
    7   </listDescription>
    8   <tModelInfos>
    9     <tModelInfo tModelKey="uddi:systinet.com:uddi:service:porttype:account">
   10       <name>AccountApi</name>
   11       <description xml:lang="en">This portType defines all operations with the accounts.</description>
   12     </tModelInfo>
   13     <tModelInfo tModelKey="uddi:systinet.com:uddi:service:binding:account">
   14       <name>Account_SoapBinding</name>
   15       <description xml:lang="en">This is the SOAP binding for the Account portType.</description>
   16     </tModelInfo>
   17     <tModelInfo tModelKey="uddi:systinet.com:uddi:service:porttype:administrationutils">
   18       <name>administrationUtilsApi</name>
   19       <description xml:lang="en">This portType defines all operations with the administrationUtils.</description>
   20     </tModelInfo>
   21     <tModelInfo tModelKey="uddi:systinet.com:uddi:service:binding:administrationutils">
   22       <name>administrationUtils_SoapBinding</name>
   23       <description xml:lang="en">This is the SOAP binding for the administrationUtils portType.</description>
   24     </tModelInfo>
   25     <tModelInfo tModelKey="uddi:42f92342-c3ed-46ff-8a8a-6518f55d5cd5">
   26       <name>Application response service</name>
   27       <description xml:lang="en">NIST definition of the service interface for handling UBL application response messages.</description>
   28     </tModelInfo>

The header information (in bold) listDescription so there are 6929 tModels in the registry currently.

A deeper look at Find Qualifiers

In section 5.1.4 Find Qualifiers the second row in the table Find Qualifiers by API defines "approximateMatch" with the uuid uddi-org:approximateMatch:SQL99, the introduction says:

Each of the find_xx APIs accepts an optional findQualifiers argument, which may contain multiple findQualifier values. Find qualifiers may be either tModelKeys or may be referenced by a string containing a "short name". Each of the pre-defined findQualifiers in UDDI can be referenced using either the appropriate tModelKey, or by its short name. Registries MUST support both forms, and MUST accept the find qualifiers case-insensitively. The use of tModelKeys for findQualifiers allows extension to create additional new qualifiers, but registries are not obligated to support them. Find qualifiers not recognized by a node will return the error E_unsupported.

Matching behavior for the find_xx APIs when multiple criteria are specified is logical "AND" by default. Find qualifiers allow the default search behaviors to be overridden. Not all find_xx APIs support all findQualifier element values.

later in 5.1.4.3 Find Qualifier Descriptions:

approximateMatch

signifies that wildcard search behavior is desired. This behavior is defined by the uddi-org:approximatematch:SQL99 tModel and means "approximate matching as defined for the character like predicate in ISO/IEC9075-2:1999(E) Section 8.5 like predicate, where the percent sign (%) indicates any number of characters and an underscore (_) indicates any single character. The backslash character (\) is used as an escape character for the percent sign, underscore and backslash characters. This find qualifier adjusts the matching behavior for name, keyValue and keyName (where applicable).

Let's just take the special characters from the last part again:

percent sign '%'

indicates any number of characters

an underscore '_'

indicates any single character.

The backslash character '\'

is used as an escape character for the percent sign, underscore and backslash characters.

This find qualifier adjusts the matching behavior for name, keyValue and keyName (where applicable).

There's more detail in section 5.1.6 About wildcards, where I've put the most important parts in bold:

The default behavior of UDDI with respect to matching is "exact match". No wildcard behavior is assumed. Many UDDI inquiry APIs take the arguments "name," "keyName," and "keyValue" whose values are of type string. All such arguments may be specified using a wildcard character to obtain an "approximate match". In order to obtain wildcard searching behavior, the findQualifier tModel uddi-org:approximateMatch:SQL99 (whose tModelKey is uddi:uddi.org:findqualifier:approximatematch), or its short name "approximateMatch" MUST be specified.

Wildcards, when they are allowed, may occur at any position in the string of characters that constitutes the argument value and may occur more than once. Wildcards are denoted with a percent sign (%) to indicate any value for any number of characters and an underscore (_) to indicate any value for a single character. The backslash character (\) is used as an escape character for the percent sign, underscore and backslash characters. Use of the "exactMatch" findQualifier will cause wildcard characters to be interpreted literally, and as such should not also be combined with the escape character. Detailed rules for interpretation are defined by the above tModel for approximate matching. Examples of the use of wildcards may be found in Appendix G Wildcards.

I havn't figured out if this is really smart or relly technical, since this isn't SQL and it sort of breaks with how it worked in version 2, also why the need to interpret them literally when there's a simple way to escape them? It works and now I know, so it's just my personal opinion.

The keys to UDDI - from nonsense Hex-digits to meaningfull URIs

UDDI version 3 is new to me even though it's not a new standard. A classic approach to new versions is to look for the what's new section. The specification doesn't give that (UDDI Version 3.0.2). A quick search lead me to PerfectXML's The Evolution of UDDI. Looking at the date's on history table I was surprised to see that it's in fact more than five years old. A couple of minor revisions lead me to believe i wasn't that old, but it is from the summer of 2002:

Update!: Today I found the announcement "UDDI Version 3.0 Beomes an OASIS Standard" dated February 03, 2005! It would had been nice with a formal version, with the label standard and the correct date, and I can't remember any other OASIS Standard without such an officially labeled specification. I conclude that it took approximately 2.5 years and 2 minor revisions for version 3 to become an real standard.

Version	Date for Committee draft
3.0.2	19 October 2004
3.0.1	14 October 2003
3.0	19 July 2002

UDDI Keys

One of the central new things are the keys used in UDDI, which has always be central but with the shift of focus to federation, this is even more important. The article gives a short description in "Creating and Managing Registration Keys". But first a look at how it was defined in version 2.

UDDI Keys in version 2

In UDDI version 2 section "4 API Reference" the keys are described:

uuid_key

Access keys within all UDDI defined data elements are represented as universal unique identifiers (these are sometimes called a GUID). The name of the element or attribute designates the particular key type that is required. These keys are always formatted according to an algorithm that is agreed upon by the UDDI Operator Council with the one exception being tModelKey values, which are prefixed with a URN qualifier in the format "uuid:" followed by the UUID value.

and further down under tModelBag All tModelKey values are always expressed using a Uniform Resource Identifier (URI) format that starts with the characters "uuid:" followed by a formatted Universally Unique Identifier (UUID) consisting of Hexadecimal digits arranged in the common 8-4-4-4-12 format pattern.

According to Richard Monson-Haefel's book J2EE Web Services in section "6.5 UUID Keys": The UUID is a hexadecimal-encoded number taht is about 30 charaters long and is generated using the DCE UUID-generation algorithm.

UDDI Keys in version 3

In version 3, the section "4.4 About uddiKeys" gives the change:

..All UDDI keys are URIs that conform to RFC 2396 but not all URIs are valid UDDI keys. The URIs that are valid as UDDI keys correspond to a subset of the opaque part alternative of the absoluteURI rule in RFC 2396. Further, registries MUST use keys from the scheme "uddi" following the syntactic and semantic rules for that scheme as given in this section,..

and "9.4.2 Registry General Keying Policy":

UDDI Version 3 introduces the ability for publishers to generate entity keys. This feature preserves the requirement for distinct keys while enabling keys to be created in a safe, efficient manner.

A registry MUST have a policy on key format and key generation. The registry MUST have a policy on data integrity or how the keyspace is protected from unauthorized modification.

Registries MAY use whatever keying policies they wish subject only to the constraints that keys MUST be URIs, and the registry MUST have policies that prevent key collisions.

Update: Today I found the UDDI Version 3 Features List where "2.2 Human-friendly, URI-based keys":

Alongside the ability to promote keys across registries is a new format for UDDI keys. Prior versions of UDDI mandated that keys had to be a formatted Universally Unique Identifier (UUID). Version 3 removes this restriction and recommends the usage of a key scheme based on DNS names. This allows publishers to establish a key partition from a DNS record and then generate keys based on that partition. For example, a valid Version 3 key might look as follows:

• uddi:example.com:1
• uddi:example.com:sales-division:53

These human-friendly keys allow organizations to manage their own key space using internally established conventions and structures.

So now all keys in UDDI are URI's and the publisher can suggest them. I haven't really used UDDI so I can't tell any story from the trenches about the problems with opaque keys, but sometimes it's sure nice to make some meaning out of them, Though it's also some times seen as best practice not to put any meaning into keys since things have a tendency to change.

OIO e-Business Registry - choice of product and main use case

The OIO e-Business Registry looks like the new registry for OIO, though the focus right now is just on e-Business. The original OIO registry (UDDI) is part of the InfoStructureBase (ISB), based on a Microsoft implementation. I'm not really sure if Microsoft has officially abandoned further development, but it currently only support version 1 and 2 (see the Windows 2003 Server UDDI FAQ).

The chosen product

Following the URL to the registry website you're met by the Oracle Application Server Service Registry Business Service Control - I haven't figured out what that loooong title really means, especially the final Business Service part puzzles me. In fact it's the Systinet Registry (Supporting UDDI version 3) that Oracle has teamed up with. I didn't know, but found an article about it on techtarget from 2005 Oracle-Systinet deal a win-win:

Oracle Corp. and Systinet Corp. have entered into a strategic three-year agreement in which Oracle will embed Systinet's registry with the recently unveiled Oracle Application Server 10g Release 3, a component of Oracle Fusion Middleware.

So Oracle has realized that developing they're own registry wasn't worth it - and they are not alone with that analysis. It turns out that BEA has done something similar, as can be read in an zdnet blog post Connecting the SOA dots with UDDI:

When BEA’s "AquaLogic" hits the market, one of its most interesting features will be a service registry that employs the Universal Description, Discovery and Integration (UDDI) standard. (Details on the service registry can be found here.) BEA announced it will be reselling the Systinet Registry as this component of AquaLogic.

On the Systinet website there's an overview of the registry [HTML] and the Systinet Registry Datasheet.

The main use case

I won't go into why the choose UDDI, but instead have a quick look at how it's used in connection with OIOSI. On the overview page for OIO Service Oriented Infrastructure (english version) the document: The Architecture of the Danish OIO Service Oriented Infrastructure [PDF] (Draft version 0.8, For public review) can be found. Main section 6 Service registry describes how the UDDI fits in, and section 6.2 Functionality lists the functionality (read use cases):

• Registration

  Businesses or public authorities must register their web services with the service registry in order for others to find and use the service to send a business message. All registrations are done to the master UDDI and the registered information is copied to the replicas afterwards by the replication procedure. Registration can be done through a Web interface or by calling UDDI web services.

• Activation

  It is necessary to make sure that interfaces defined by a client are correct after a registration. Therefore a number of test requests are initiated from the national master UDDI. The test requests use dummy data and test certificates. The responses are verified by the master UDDI....After the tests have been carried out successfully, the web service entry will be active in the UDDI, enabling lookups of the particular web service.

• Endpoint lookup

  An organization needs the endpoint of another organizations web service in order to send a business message to that organization. The purpose of the lookup mechanism is to provide this endpoint, based on the information of the business.

  EAN location numbers2 and CVR numbers are used to identify organizations and based on one of these numbers, it is possible to lookup web services from the specific organization through the UDDI replicas.

With the last one being essential, that's heavy in terms of usage/volume, and the former two supporting this one. This is one of the classic UDDI use cases, though I'll gladly admit that I wasn't expecting to see this already considering dynamic lookup for a business process directly related to money and bank accounts, will need some founding business agreements and readiness in terms of both raw technology and willingness from the business perspective. In OIO e-business profile version 0.8 it's show in an activity diagram:

Using the ISB UDDI #5 - whos doing business?

A very central data structure in UDDI is business, which can be searched by find_business:

    1 <?xml version="1.0"?>
    2 <find_business generic="2.0" xmlns="urn:uddi-org:api_v2">
    3   <name>%</name>
    4 </find_business>

a the search at present gives:

    1 <?xml version="1.0"?>
    2 <businessList generic="2.0"
    3               operator="Infostructurebase"
    4               truncated="false"
    5               xmlns="urn:uddi-org:api_v2">
    6   <businessInfos>
    7     <businessInfo businessKey="c780e2ec-41cc-4978-8d19-47d07f167c41">
    8       <name xml:lang="en-us">&lt;New Provider Name></name>
    9       <serviceInfos>
   10         <serviceInfo serviceKey="095a67b9-cb6d-47b7-ab97-13238427ae43" businessKey="c780e2ec-41cc-4978-8d19-47d07f167c41">
   11           <name xml:lang="en-us">&lt;New Service Name></name>
   12         </serviceInfo>
   13       </serviceInfos>
   14     </businessInfo>
   15     <businessInfo businessKey="5466157e-0129-43cc-a0a3-382aed61e53e">
   16       <name xml:lang="en-us">&lt;New Provider Name></name>
   17       <serviceInfos />
   18     </businessInfo>
   19     <businessInfo businessKey="5d7c6751-5ff3-4888-a91b-c9fd9227588f">
   20       <name xml:lang="en">Accenture</name>
   21       <serviceInfos>
   22         <serviceInfo serviceKey="176e44de-2b73-4a45-971e-d0d363078a3e" businessKey="5d7c6751-5ff3-4888-a91b-c9fd9227588f">
   23           <name xml:lang="en">AcnService1</name>
   24         </serviceInfo>
   25         <serviceInfo serviceKey="688cfcd8-7977-4063-9e1f-34603e6f3716" businessKey="5d7c6751-5ff3-4888-a91b-c9fd9227588f">
   26           <name xml:lang="en">Accenture Service 1</name>
   27         </serviceInfo>
   28       </serviceInfos>
   29     </businessInfo>
   30     <businessInfo businessKey="1b3ebc57-a6fb-4900-bce4-efe947f07885">
   31       <name xml:lang="en">Accenture SP</name>
   32       <serviceInfos />
   33     </businessInfo>
   34     <businessInfo businessKey="49fda011-0b46-41ee-addf-c075134929e7">
   35       <name xml:lang="en">ACCENTURETEST1</name>
   36       <description xml:lang="en">Test 1</description>
   37       <serviceInfos>
   38         <serviceInfo serviceKey="d7987d41-2cd0-48df-9c54-5ba9617b88e4" businessKey="49fda011-0b46-41ee-addf-c075134929e7">
   39           <name xml:lang="en">acntest1</name>
   40         </serviceInfo>
   41       </serviceInfos>
   42     </businessInfo>
   43     <businessInfo businessKey="e29d142d-4f68-4ad2-862d-12cbc9bd44c2">
   44       <name xml:lang="en">ACCENTURETEST2</name>
   45       <description xml:lang="en">test2</description>
   46       <serviceInfos />
   47     </businessInfo>
   48     <businessInfo businessKey="cfe58050-fd25-40ac-9d75-c1cbd27e5fee">
   49       <name xml:lang="en">ACCENTURETEST3</name>
   50       <description xml:lang="en">ACCENTURETEST3</description>
   51       <serviceInfos />
   52     </businessInfo>
   53     <businessInfo businessKey="2f489a02-dffc-4d41-9311-f0d251c20cca">
   54       <name xml:lang="en">delete</name>
   55       <serviceInfos>
   56         <serviceInfo serviceKey="cd367ebe-57e0-42ed-ad38-da1ebc079992" businessKey="2f489a02-dffc-4d41-9311-f0d251c20cca">
   57           <name xml:lang="en">delete serv3</name>
   58         </serviceInfo>
   59       </serviceInfos>
   60     </businessInfo>
   61     <businessInfo businessKey="78ea44cb-8201-4b0e-aff8-87be54cd1fce">
   62       <name xml:lang="da">Det Centrale Virksomhedsregister</name>
   63       <name xml:lang="en">&lt;New Provider Name></name>
   64       <serviceInfos>
   65         <serviceInfo serviceKey="3465bf97-a35d-4d86-8e7b-e966b8ffdd0e" businessKey="78ea44cb-8201-4b0e-aff8-87be54cd1fce">
   66           <name xml:lang="en">CVR online</name>
   67         </serviceInfo>
   68       </serviceInfos>
   69     </businessInfo>
   70     <businessInfo businessKey="b7453c3b-c8e7-4318-bb8f-180831e2a060">
   71       <name xml:lang="en-us">FESD pilot</name>
   72       <serviceInfos>
   73         <serviceInfo serviceKey="4c8f92dd-5026-4d6f-b551-ba5da930808e" businessKey="b7453c3b-c8e7-4318-bb8f-180831e2a060">
   74           <name xml:lang="en-us">FESD A850 webservice pilot</name>
   75         </serviceInfo>
   76       </serviceInfos>
   77     </businessInfo>
   78     <businessInfo businessKey="0bb38549-919e-415f-8239-70aacc0780ae">
   79       <name xml:lang="en">gf</name>
   80       <description xml:lang="en">gf</description>
   81       <serviceInfos />
   82     </businessInfo>
   83     <businessInfo businessKey="2811adb5-88d3-4403-983e-1fb1fbb70840">
   84       <name xml:lang="da">glr.dk</name>
   85       <serviceInfos>
   86         <serviceInfo serviceKey="d24b8874-71c9-4da6-84d0-8bb993b7864b" businessKey="2811adb5-88d3-4403-983e-1fb1fbb70840">
   87           <name xml:lang="da">MVJGis</name>
   88         </serviceInfo>
   89       </serviceInfos>
   90     </businessInfo>
   91     <businessInfo businessKey="a2ab96a6-d760-4bdd-8659-edc9feac6fba">
   92       <name xml:lang="en">hjh3</name>
   93       <description xml:lang="en">hjh3</description>
   94       <serviceInfos />
   95     </businessInfo>
   96     <businessInfo businessKey="09b02af8-09cf-4e5d-acd7-94c917380f46">
   97       <name xml:lang="en">Infostructurebase</name>
   98       <description xml:lang="en">A Microsoft UDDI Services site</description>
   99       <serviceInfos>
  100         <serviceInfo serviceKey="d6817e82-746c-481c-a7c9-91a8d8646913" businessKey="09b02af8-09cf-4e5d-acd7-94c917380f46">
  101           <name xml:lang="en-us">Repository Services</name>
  102         </serviceInfo>
  103         <serviceInfo serviceKey="0a4ce531-f876-4181-bcbf-02ee36b1d8af" businessKey="09b02af8-09cf-4e5d-acd7-94c917380f46">
  104           <name xml:lang="en">UDDI Services</name>
  105         </serviceInfo>
  106       </serviceInfos>
  107     </businessInfo>
  108     <businessInfo businessKey="47594afd-2774-4621-a241-4973c4b45d01">
  109       <name xml:lang="en-us">ITST</name>
  110       <serviceInfos>
  111         <serviceInfo serviceKey="48d326e6-b0e9-4d5c-8c52-1c29b21a9b0b" businessKey="47594afd-2774-4621-a241-4973c4b45d01">
  112           <name xml:lang="en-us">MasteDataBasen</name>
  113         </serviceInfo>
  114       </serviceInfos>
  115     </businessInfo>
  116     <businessInfo businessKey="f3cef3b7-a747-4856-a8d1-47be02fbc8c3">
  117       <name xml:lang="en-gb">John Gøtze</name>
  118       <serviceInfos>
  119         <serviceInfo serviceKey="1de05d22-d2b9-41ae-b65f-e576b03a43b9" businessKey="f3cef3b7-a747-4856-a8d1-47be02fbc8c3">
  120           <name xml:lang="en-gb">WS4RP</name>
  121         </serviceInfo>
  122       </serviceInfos>
  123     </businessInfo>
  124     <businessInfo businessKey="3296d079-4431-418b-a350-18d30a275d3f">
  125       <name xml:lang="da">KMD</name>
  126       <description xml:lang="da">Kommunedata A/S</description>
  127       <serviceInfos>
  128         <serviceInfo serviceKey="f382674f-b48f-4fa8-885b-09cc9c20a438" businessKey="3296d079-4431-418b-a350-18d30a275d3f">
  129           <name xml:lang="da">P-Data opslag</name>
  130         </serviceInfo>
  131       </serviceInfos>
  132     </businessInfo>
  133     <businessInfo businessKey="f9b1a2e5-c1a1-436a-bff1-8efe55acc2e5">
  134       <name xml:lang="da-dk">Krak</name>
  135       <description xml:lang="da">
  136         Den grundlæggende idé bag Krak har gennem mere end 230 år været at indsamle, bearbejde og udgive information – med
  137         det formål at hjælpe danskerne til at skabe handel. Idéen holder stadig – dog er den nu videreudviklet. Samtidig er
  138         vi i stand til at hjælpe
  139       </description>
  140       <serviceInfos>
  141         <serviceInfo serviceKey="5925002d-5a70-4ad9-a823-b378e8083a69" businessKey="f9b1a2e5-c1a1-436a-bff1-8efe55acc2e5">
  142           <name xml:lang="en-us">AddressValidation</name>
  143         </serviceInfo>
  144         <serviceInfo serviceKey="4f86f0cd-c988-4aa1-ada0-67d2b389321f" businessKey="f9b1a2e5-c1a1-436a-bff1-8efe55acc2e5">
  145           <name xml:lang="en-us">TicketCentral</name>
  146         </serviceInfo>
  147         <serviceInfo serviceKey="f7189317-3187-48c3-9962-d8ad28cd58c0" businessKey="f9b1a2e5-c1a1-436a-bff1-8efe55acc2e5">
  148           <name xml:lang="en-us">CompanySearch</name>
  149         </serviceInfo>
  150       </serviceInfos>
  151     </businessInfo>
  152     <businessInfo businessKey="8dba6919-e074-428f-aba0-1c8df2340f0e">
  153       <name xml:lang="da-dk">LCO/RUC</name>
  154       <serviceInfos>
  155         <serviceInfo serviceKey="1d9427d3-b73e-4199-8279-6f99c3e752e1" businessKey="8dba6919-e074-428f-aba0-1c8df2340f0e">
  156           <name xml:lang="da-dk">EjendomService</name>
  157         </serviceInfo>
  158       </serviceInfos>
  159     </businessInfo>
  160     <businessInfo businessKey="aeeee52f-e42a-4798-bc32-92cfc1c9369a">
  161       <name xml:lang="en">lkl</name>
  162       <description xml:lang="en">lkl</description>
  163       <serviceInfos>
  164         <serviceInfo serviceKey="4466bca1-093a-4bfb-ba51-d6de5ec82f5c" businessKey="aeeee52f-e42a-4798-bc32-92cfc1c9369a">
  165           <name xml:lang="en">ACCENTURETEST11</name>
  166         </serviceInfo>
  167       </serviceInfos>
  168     </businessInfo>
  169     <businessInfo businessKey="f98ba3dd-940a-45b1-890c-5510f4f08c18">
  170       <name xml:lang="en-us">National IT and Telecom Agency</name>
  171       <name xml:lang="da">IT- og Telestyrelsen</name>
  172       <description xml:lang="en-us">
  173         The National IT and Telecom Agency is part of the Ministry for Science, Technology and Innovation. The Agency's
  174         principal task is to develop and implement initiatives within key areas of the Government's IT policy strategy.
  175       </description>
  176       <description xml:lang="da">
  177         IT- og Telestyrelsen er en del af Ministeriet for Videnskab, Teknologi og Udvikling. IT- og Telestyrelsen har som
  178         hovedopgave at udvikle og gennemføre initiativer inden for de centrale områder af regeringens IT-politiske strategi.
  179       </description>
  180       <serviceInfos>
  181         <serviceInfo serviceKey="34d2acc8-9fde-4af5-a429-abd928f8e6d0" businessKey="f98ba3dd-940a-45b1-890c-5510f4f08c18">
  182           <name xml:lang="en-us">PressRoom</name>
  183           <name xml:lang="da">PressRoom</name>
  184         </serviceInfo>
  185       </serviceInfos>
  186     </businessInfo>
  187     <businessInfo businessKey="bcd2db3d-9a5f-404c-8d04-9d40de8ddcf2">
  188       <name xml:lang="en-us">OIO</name>
  189       <description xml:lang="en-us">
  190         OIO - Offentlig Information Online (public information online) is a website and an electronic newsletter offering
  191         information, knowledge and access to tools in relation to IT in the publice sector as well as public sector
  192         communication.
  193       </description>
  194       <description xml:lang="da">
  195         OIO står for Offentlig Information Online. På engelsk Open Public Information Online. Portalen oio.dk er for alle,
  196         der beskæftiger sig med digital forvaltning og implementering af it i den offentlige sektor samt effektivisering af
  197         den offentlige kommunik
  198       </description>
  199       <serviceInfos>
  200         <serviceInfo serviceKey="26b8f5fe-5eef-4c75-8d61-4f63e7fddd87" businessKey="bcd2db3d-9a5f-404c-8d04-9d40de8ddcf2">
  201           <name xml:lang="en-us">AWS - Address Web Service</name>
  202           <name xml:lang="da">AWS - Adresse Web Service</name>
  203         </serviceInfo>
  204       </serviceInfos>
  205     </businessInfo>
  206     <businessInfo businessKey="7323deeb-f4e2-4d94-bbba-fc0b0cd60d89">
  207       <name xml:lang="en-us">OIOMaker.dk</name>
  208       <description xml:lang="en">
  209         OIOMaker provide automatic metadata about what OIO-subjects are relevant to the content to a given document or
  210         webpage. All tags are returned in Dublin Core tags as: &lt;DC:OIO Subject>
  211       </description>
  212       <description xml:lang="da-dk">
  213         OIOMaker er en webservice der leverer metadata om hvilke OIO-emner i henhold til OIO-emnesystem der er relevante for
  214         indholdet af et givent dokument eller en webside. For mere information om OIOemnesystem se
  215         http://www.oio.dk/index.php?o=60603a5f79ef7cbd
  216       </description>
  217       <serviceInfos>
  218         <serviceInfo serviceKey="906ed95f-0013-4efb-82bd-7c6e70662260" businessKey="7323deeb-f4e2-4d94-bbba-fc0b0cd60d89">
  219           <name xml:lang="en-us">OIOMaker</name>
  220         </serviceInfo>
  221       </serviceInfos>
  222     </businessInfo>
  223     <businessInfo businessKey="6ccb966d-e97f-4b12-9f6e-733b3d16791f">
  224       <name xml:lang="da">Retsinformation</name>
  225       <name xml:lang="en">Legal Information</name>
  226       <description xml:lang="da">
  227         Retsinformation er statens juridiske online informationssystem, som giver Dem adgang til love, bekendtgørelser og
  228         cirkulærer m.v., til Folketingets dokumenter og til Folketingets Ombudsmands beretningssager.
  229       </description>
  230       <description xml:lang="en">
  231         Retsinformation was established in 1985 and contains all Danish rules and regulations, i.e. all acts passed by the
  232         Folketing (the Danish parliament) as well as statutory orders, circulars etc. issued by the administration.
  233       </description>
  234       <serviceInfos>
  235         <serviceInfo serviceKey="fd36f2a5-97bf-40e4-ba2d-639df8679b0e" businessKey="6ccb966d-e97f-4b12-9f6e-733b3d16791f">
  236           <name xml:lang="da">RetsInfoDocuments</name>
  237           <name xml:lang="en">RetsInfoDocuments</name>
  238         </serviceInfo>
  239       </serviceInfos>
  240     </businessInfo>
  241     <businessInfo businessKey="c18d0eed-d1e6-41b2-a9cf-2cd2a88a685e">
  242       <name xml:lang="da-dk">Sweetxml</name>
  243       <name xml:lang="en-us">Sweetxml</name>
  244       <description xml:lang="da-dk">Sweetxml er et website/en blog for Brian Nielsen.</description>
  245       <description xml:lang="en-us">Sweetxml is a website/blog for Brian Nielsen.</description>
  246       <serviceInfos />
  247     </businessInfo>
  248     <businessInfo businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  249       <name xml:lang="da">Told og Skattestyrelsen</name>
  250       <description xml:lang="da">
  251         Skatteministeriets opgaver kan overordnet kategoriseres i tre typer: lovgivning, forvaltning (klagebehandling),
  252         drift. Den funktionelle opgavefordeling mellem ministeriets tre institutioner er således, at Departementet varetager
  253         lovgivningen mv., Landsska
  254       </description>
  255       <serviceInfos>
  256         <serviceInfo serviceKey="32e4a992-dac5-495f-b31d-7ca48b2bf08b" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  257           <name xml:lang="en-us">PaymentVacationPensionDetailService</name>
  258         </serviceInfo>
  259         <serviceInfo serviceKey="285188ec-8931-422b-b05b-8acaf911d7fd" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  260           <name xml:lang="en-us">EmploymentService</name>
  261         </serviceInfo>
  262         <serviceInfo serviceKey="13ce4c5e-0798-401e-be68-be6d774e6dcf" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  263           <name xml:lang="en-us">PaymentVacationPensionPrBaseMonthService</name>
  264         </serviceInfo>
  265         <serviceInfo serviceKey="285df998-310c-49b5-9714-d3848e621e0f" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  266           <name xml:lang="en-us">PaymentVacationPensionSumService</name>
  267         </serviceInfo>
  268         <serviceInfo serviceKey="ba3aaee4-c771-47e2-a107-029068906e00" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  269           <name xml:lang="en-us">EmploymentPrCprService</name>
  270         </serviceInfo>
  271         <serviceInfo serviceKey="b0fbdce6-1685-4117-b20f-a4a583d0633d" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  272           <name xml:lang="en-us">PaymentVacationInsurancePensionPrCprService</name>
  273         </serviceInfo>
  274         <serviceInfo serviceKey="a421e42b-b6b7-46b3-a647-a85196b71e4d" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  275           <name xml:lang="en-us">PaymentVacationDetailPrCprService</name>
  276         </serviceInfo>
  277         <serviceInfo serviceKey="f25ce542-e665-4a35-8198-171ac353764e" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  278           <name xml:lang="en-us">InsurancePensionPrCprService</name>
  279         </serviceInfo>
  280         <serviceInfo serviceKey="ad3803bd-c390-46f8-a40d-7aa94aca72c6" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  281           <name xml:lang="en-us">PaymentVacationInsurancePensionPrTypeService</name>
  282         </serviceInfo>
  283         <serviceInfo serviceKey="db0c9383-e5a0-4a96-b437-0119deb27819" businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  284           <name xml:lang="en-us">PaymentVacationPensionPrBaseMonthPrCprService</name>
  285         </serviceInfo>
  286       </serviceInfos>
  287     </businessInfo>
  288     <businessInfo businessKey="390ced8a-9d8b-47ba-acf8-24a813f03217">
  289       <name xml:lang="en-us">xmltools.oio.dk</name>
  290       <description xml:lang="da">OIO test side for xmlværktøjer og webservices.</description>
  291       <description xml:lang="en-us">OIO test site for xml tools and webservices</description>
  292       <serviceInfos>
  293         <serviceInfo serviceKey="458f4e3e-e452-4ea7-bd79-15ce9721289d" businessKey="390ced8a-9d8b-47ba-acf8-24a813f03217">
  294           <name xml:lang="en-us">AuthorityCodeConversion</name>
  295         </serviceInfo>
  296       </serviceInfos>
  297     </businessInfo>
  298   </businessInfos>
  299 </businessList>

I'll now have a look at the details available for SKAT (Told og Skattestyrelsen) with the businessKey:

    1 <?xml version="1.0"?>
    2 <get_businessDetail
    3   generic="2.0"
    4   xmlns="urn:uddi-org:api_v2">
    5   <businessKey>483afc20-f25e-4ed7-b316-9d8de9131d34</businessKey>
    6 </get_businessDetail>

with the result:

    1 <?xml version="1.0"?>
    2 <businessDetail
    3   generic="2.0"
    4   operator="Infostructurebase"
    5   truncated="false"
    6   xmlns="urn:uddi-org:api_v2">
    7   <businessEntity
    8     businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34"
    9     operator="Infostructurebase"
   10     authorizedName="OIO\knippel">
   11     <discoveryURLs>
   12       <discoveryURL useType="businessEntity">
   13         http://vtuapp01.oio.dk/uddipublic/discovery.ashx?businessKey=483afc20-f25e-4ed7-b316-9d8de9131d34
   14       </discoveryURL>
   15     </discoveryURLs>
   16     <name xml:lang="da">Told og Skattestyrelsen</name>
   17     <description xml:lang="da">
   18       Skatteministeriets opgaver kan overordnet kategoriseres i tre typer: lovgivning, forvaltning
   19       (klagebehandling), drift. Den funktionelle opgavefordeling mellem ministeriets tre institutioner er
   20       således, at Departementet varetager lovgivningen mv., Landsska
   21     </description>
   22     <contacts>
   23       <contact useType="">
   24         <personName>Jens Lorentz Bay</personName>
   25         <phone useType="">72373453</phone>
   26         <email useType="">Jens.bay@toldskat.dk</email>
   27       </contact>
   28     </contacts>
   29     <businessServices>
   30       <businessService
   31         serviceKey="32e4a992-dac5-495f-b31d-7ca48b2bf08b"
   32         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
   33         <name xml:lang="en-us">PaymentVacationPensionDetailService</name>
   34         <description xml:lang="da">
   35           En borgerrettet service. På baggrund af CPR-nr samt evt. SE-nr på arbejdsgiver og medarbejdernr.
   36           returnerer servicen detailoplysninger om en borgers løn, feriekonto og forsik-ring/pension for en
   37           anfordret periode.
   38         </description>
   39         <bindingTemplates>
   40           <bindingTemplate
   41             bindingKey="167c45c2-7c7f-46e0-8c36-707bd252f9ef"
   42             serviceKey="32e4a992-dac5-495f-b31d-7ca48b2bf08b">
   43             <description xml:lang="da">Servicen kører på et lukket net</description>
   44             <accessPoint URLType="http">http://</accessPoint>
   45             <tModelInstanceDetails>
   46               <tModelInstanceInfo tModelKey="uuid:27b337ec-9df5-4851-887f-5665215dcf19" />
   47             </tModelInstanceDetails>
   48           </bindingTemplate>
   49         </bindingTemplates>
   50       </businessService>
   51       <businessService
   52         serviceKey="285188ec-8931-422b-b05b-8acaf911d7fd"
   53         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
   54         <name xml:lang="en-us">EmploymentService</name>
   55         <description xml:lang="da">
   56           En borgerrettet service. På baggrund af CPR-nr samt evt. SE-nr på arbejdsgiver og medarbejdernr
   57           returnerer servicen stamoplysninger om borgerens ansættelsesforhold for en anfordret periode.
   58         </description>
   59         <bindingTemplates>
   60           <bindingTemplate
   61             bindingKey="b2255ce1-ff20-4e94-b79a-9ff2d960b766"
   62             serviceKey="285188ec-8931-422b-b05b-8acaf911d7fd">
   63             <description xml:lang="da">Servicen kører på et lukket net</description>
   64             <accessPoint URLType="http">http://</accessPoint>
   65             <tModelInstanceDetails>
   66               <tModelInstanceInfo tModelKey="uuid:a8a22fcf-c208-496f-ad7b-1c6e9b781a78" />
   67             </tModelInstanceDetails>
   68           </bindingTemplate>
   69         </bindingTemplates>
   70       </businessService>
   71       <businessService
   72         serviceKey="13ce4c5e-0798-401e-be68-be6d774e6dcf"
   73         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
   74         <name xml:lang="en-us">PaymentVacationPensionPrBaseMonthService</name>
   75         <description xml:lang="da">
   76           En borgerrettet service. På baggrund af CPR-nr samt evt. SE-nr på arbejdsgiver og medarbejdernr
   77           returnerer servicen summerede oplysninger om en borgers løn, feriekonto og forsikring/pension pr.
   78           ansættelsesforhold, pr. basismåned.
   79         </description>
   80         <bindingTemplates>
   81           <bindingTemplate
   82             bindingKey="ee46120b-9edc-4a82-9802-2fd379c6df81"
   83             serviceKey="13ce4c5e-0798-401e-be68-be6d774e6dcf">
   84             <description xml:lang="da">Servicen kører på et lukket net</description>
   85             <accessPoint URLType="http">http://</accessPoint>
   86             <tModelInstanceDetails>
   87               <tModelInstanceInfo tModelKey="uuid:8fb960e5-1f1a-451a-b975-f195cfa439a0" />
   88             </tModelInstanceDetails>
   89           </bindingTemplate>
   90         </bindingTemplates>
   91       </businessService>
   92       <businessService
   93         serviceKey="285df998-310c-49b5-9714-d3848e621e0f"
   94         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
   95         <name xml:lang="en-us">PaymentVacationPensionSumService</name>
   96         <description xml:lang="da">
   97           En borgerrettet service. På baggrund af CPR-nr samt evt. SE-nr på arbejdsgiver og medarbejdernr
   98           returnerer servicen summerede beløb for den ønskede periode. Der summeres lønoplysninger, optjente
   99           feriepenge samt indbetalinger til pensionsordninger.
  100         </description>
  101         <bindingTemplates>
  102           <bindingTemplate
  103             bindingKey="72e2397d-d2d2-4d1b-adf7-53268cfcb67e"
  104             serviceKey="285df998-310c-49b5-9714-d3848e621e0f">
  105             <description xml:lang="da">Servicen kører på et lukket net</description>
  106             <accessPoint URLType="http">http://</accessPoint>
  107             <tModelInstanceDetails>
  108               <tModelInstanceInfo tModelKey="uuid:0325a926-1f82-445d-85ef-98b0002a2dce" />
  109             </tModelInstanceDetails>
  110           </bindingTemplate>
  111         </bindingTemplates>
  112       </businessService>
  113       <businessService
  114         serviceKey="ba3aaee4-c771-47e2-a107-029068906e00"
  115         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  116         <name xml:lang="en-us">EmploymentPrCprService</name>
  117         <description xml:lang="da">
  118           Er en virksomhedsrettet service. Servicen returnerer oplysninger om ansættelsesforhold for de
  119           medarbejdere, der er tilknyttet en virksomhed.
  120         </description>
  121         <bindingTemplates>
  122           <bindingTemplate
  123             bindingKey="c6e21193-c72f-4549-a93e-e76dd62a238d"
  124             serviceKey="ba3aaee4-c771-47e2-a107-029068906e00">
  125             <description xml:lang="da">Servicen kører på et lukket net</description>
  126             <accessPoint URLType="http">http://</accessPoint>
  127             <tModelInstanceDetails>
  128               <tModelInstanceInfo tModelKey="uuid:805939a7-5bd3-45b7-ae89-46972be7cca0" />
  129             </tModelInstanceDetails>
  130           </bindingTemplate>
  131         </bindingTemplates>
  132       </businessService>
  133       <businessService
  134         serviceKey="b0fbdce6-1685-4117-b20f-a4a583d0633d"
  135         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  136         <name xml:lang="en-us">PaymentVacationInsurancePensionPrCprService</name>
  137         <description xml:lang="da">
  138           Er en virksomhedsrettet service. Servicen returnerer indberettede detailoplysninger om ansattes
  139           forsikring/pension for en anfordret periode for et antal CPR-numre.
  140         </description>
  141         <bindingTemplates>
  142           <bindingTemplate
  143             bindingKey="5dfdecb0-1958-4a9a-a220-89ce18cf9925"
  144             serviceKey="b0fbdce6-1685-4117-b20f-a4a583d0633d">
  145             <description xml:lang="da">Servicen kører på et lukket net</description>
  146             <accessPoint URLType="http">http://</accessPoint>
  147             <tModelInstanceDetails>
  148               <tModelInstanceInfo tModelKey="uuid:22967ba5-ff4d-43f2-8553-498e31f2ec42" />
  149             </tModelInstanceDetails>
  150           </bindingTemplate>
  151         </bindingTemplates>
  152       </businessService>
  153       <businessService
  154         serviceKey="a421e42b-b6b7-46b3-a647-a85196b71e4d"
  155         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  156         <name xml:lang="en-us">PaymentVacationDetailPrCprService</name>
  157         <description xml:lang="da">
  158           Er en virksomhedsrettet service. Servicen returnerer detailoplysninger om indberettede løn- og
  159           feriekontooplysninger for en anfordret periode for et antal CPR-numre. Derudover returnerer services
  160           også nulindberetninger.
  161         </description>
  162         <bindingTemplates>
  163           <bindingTemplate
  164             bindingKey="a19f0b44-fa48-4c32-a58a-91185f43782f"
  165             serviceKey="a421e42b-b6b7-46b3-a647-a85196b71e4d">
  166             <description xml:lang="da">Servicen kører på et lukket net</description>
  167             <accessPoint URLType="http">http://</accessPoint>
  168             <tModelInstanceDetails>
  169               <tModelInstanceInfo tModelKey="uuid:97b5f657-63b5-4b98-bb60-85b0686603f8" />
  170             </tModelInstanceDetails>
  171           </bindingTemplate>
  172         </bindingTemplates>
  173       </businessService>
  174       <businessService
  175         serviceKey="f25ce542-e665-4a35-8198-171ac353764e"
  176         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  177         <name xml:lang="en-us">InsurancePensionPrCprService</name>
  178         <description xml:lang="da">
  179           En virksomhedsrettet service. Servicen returnerer sum-tal på lønoplysninger, optjente feriepenge
  180           samt indbetalinger til pensionsordninger. Ud over sumtal pr. med-arbejder leveres listning af
  181           periodens øvrigt indberettede kryds, kode og tekstfelter.
  182         </description>
  183         <bindingTemplates>
  184           <bindingTemplate
  185             bindingKey="311cbd47-0726-458f-adc2-9d8a8cf4ddf5"
  186             serviceKey="f25ce542-e665-4a35-8198-171ac353764e">
  187             <description xml:lang="da">Servicen kører på et lukket net</description>
  188             <accessPoint URLType="http">http://</accessPoint>
  189             <tModelInstanceDetails>
  190               <tModelInstanceInfo tModelKey="uuid:429d9818-70fa-42bb-ac0f-3be9a30164a0" />
  191             </tModelInstanceDetails>
  192           </bindingTemplate>
  193         </bindingTemplates>
  194       </businessService>
  195       <businessService
  196         serviceKey="ad3803bd-c390-46f8-a40d-7aa94aca72c6"
  197         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  198         <name xml:lang="en-us">PaymentVacationInsurancePensionPrTypeService</name>
  199         <description xml:lang="da">
  200           Er en virksomhedsrettet service. Servicen returnerer sumtal for virksomheden som helhed på
  201           lønoplysninger, optjente feriepenge samt indbetalinger til pensionsordninger.
  202         </description>
  203         <bindingTemplates>
  204           <bindingTemplate
  205             bindingKey="ae9c24f2-a5f3-4f08-8728-37bf2c16accc"
  206             serviceKey="ad3803bd-c390-46f8-a40d-7aa94aca72c6">
  207             <description xml:lang="da">Servicen kører på et lukket net</description>
  208             <accessPoint URLType="http">http://</accessPoint>
  209             <tModelInstanceDetails>
  210               <tModelInstanceInfo tModelKey="uuid:bbcd88f4-4aed-43f9-95bf-7f3e98c30008" />
  211             </tModelInstanceDetails>
  212           </bindingTemplate>
  213         </bindingTemplates>
  214       </businessService>
  215       <businessService
  216         serviceKey="db0c9383-e5a0-4a96-b437-0119deb27819"
  217         businessKey="483afc20-f25e-4ed7-b316-9d8de9131d34">
  218         <name xml:lang="en-us">PaymentVacationPensionPrBaseMonthPrCprService</name>
  219         <description xml:lang="da">
  220           En virksomhedsrettet service. På baggrund af oplysninger om medarbejdere returnerer servicen
  221           summerede oplysninger om løn, feriekonto og forsikring/pension pr. basismåned for hvert
  222           ansættelsesforhold.
  223         </description>
  224         <bindingTemplates>
  225           <bindingTemplate
  226             bindingKey="b5853087-239e-4bf0-aafb-697d42ab5133"
  227             serviceKey="db0c9383-e5a0-4a96-b437-0119deb27819">
  228             <description xml:lang="da">Servicen kører på et lukket net</description>
  229             <accessPoint URLType="http">http://</accessPoint>
  230             <tModelInstanceDetails>
  231               <tModelInstanceInfo tModelKey="uuid:8ce8045a-c6f4-4f13-a460-30288e461b87" />
  232             </tModelInstanceDetails>
  233           </bindingTemplate>
  234         </bindingTemplates>
  235       </businessService>
  236     </businessServices>
  237     <categoryBag>
  238       <keyedReference
  239         tModelKey="uuid:f699264c-384d-47a2-bb46-c6a476242e55"
  240         keyName="SKAT"
  241         keyValue="b4df00fd-ba21-4ef5-9e43-918bdcadea9b" />
  242     </categoryBag>
  243   </businessEntity>
  244 </businessDetail>