UDDI registries can be extended to support additional functionality using the extended UDDI APIs and data structures. By extending a UDDI registry, additional features can easily be added to core UDDI functionality. This feature should be used with caution, as clients may over time expect all registries to support extended functionality when they do not, causing errors.
Extensions within a UDDI registry are usually associated with one or more tModels that hold reference to the extension. The tModel in this scenario indicates that it represents an extension to one or more UDDI APIs. By using tModels, clients can discover extensions to the core UDDI API. An example is shown below:
<keyedReference keyName="uddi-org:derivedFrom:v2_inquiry" keyValue="uddi:uddi.org:v2_inquiry" tModelKey="uddi:uddi.org:categorization:derivedFrom"/>
Extending the registry in this manner may require supporting two different sets of service endpoints. Additionally, each service should register additional bindingTemplates. One of the main reasons for doing this is to avoid confusion and potential collisions in API calls. For example, when a UDDI registry receives a request to get_businessDetail, the registry cannot determine whether the client can handle the extension or not. When a service supports two distinct end-points, the UDDI registry can determine whether the client can handle the extension, based upon the endpoint the client chooses to use.
Flute Bank has decided to take advantage of the extension capabilities of UDDI to add supporting documentation as part of the UDDI publisherAssertion data structure. The bank has added a discoveryURL element to the publisherAssertion structure that will contain a URL to the business agreements and licensing terms agreed upon between Flute Bank and its partners.
In Listing 6.14, we are creating a UDDI extension derived from uddi:publisherAssertion. As part of extending the publisher assertion, we specify that the discovery URL is optional; hence its value of minOccurs="0". A publisher such as Flute Bank will use the assertion structure to indicate that its legal agreements are available at the discovery URL.
<xsd:schema targetNamespace="http://flutebank.com/uddi_extension" xmlns:egExt="http://flutebank.com/uddi_extension" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:uddi="urn:uddi-org:api_v3" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:import namespace="urn:uddi-org:api_v3" schemaLocation="http://www.uddi.org/schema/uddi_v3.xsd" /> <xsd:element name="publisherAssertionExt" type="egExt:publisherAssertionExt" substitutionGroup="uddi:publisherAssertion"/> <xsd:complexType name=publisherAssertionExt"> <xsd:annotation> <xsd:documentation>Extension of publisherAssertion</xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="uddi:publisherAssertion"> <xsd:sequence> <xsd:element ref="uddi:discoveryURLs" minOccurs="0" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema>
XML schemas support the ability to derive additional schemas from a specified base. The targetNamespace and egExt namespace take advantage of this feature. The publisherAssertion element is extended by creating a new type named publisherAssertionExt. Whenever a registry receives a request for a publisherAssertion that references the newly extended namespace but does not include the discoveryURLs element, the registry will behave in the same manner, as it would have without the extension.
There are many additional reasons that Flute Bank may want to use the UDDI extension mechanism to support its business model-including, but not limited to, supporting digital signing for all publish APIs, changing the assertion model to support custom assertion models, incorporating additional Flute Bank-specific elements on businessEntity, along with their respective services.