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.
