Federated Query

[Paul Denning <pauld@mitre.org>]

RQ 021 [1] does not seem to address a federated query.

[1] 
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5980/uddi-vnext-proj-status.htm#_Toc66860825

I will describe what I mean by federated query.  Please let me know if this 
was considered and dismissed and why, or if it has not been proposed and 
should be considered.

An example of a federated query is someone sending a find_business to a 
UDDI server [X].

To make it interesting, lets assume that the request includes a categoryBag 
for a specific taxonomy (not one of the basic NAICS/UNSPSC/ISO3166).

Server [X] may have a few entries that match the query, but server [X] 
would be a member of a federation with two other UDDI servers [Y] and [Z].

[X], [Y], and [Z] do not replicate entries among themselves.

Server [X] would submit the same find_business request to [Y] and 
[Z].  Server [X] would consolidate the results from itself [X], plus [Y] 
and [Z], and return a single response to the requester.

This assumes that [X], [Y], and [Z] have the same taxonomy (same 
tModelKey); that is, they agree that a particular taxonomy is uniquely 
identified by the tModelKey.  An alternative would be to allow each of the 
three UDDI servers to assign their own tModelKey, but use the 
indentifierBag on the tModel to uniquely identify the taxonomy.  This would 
require a translation of the find_business query either by [X] before it 
submits the request to [Y] and [Z], or for [Y] and [Z] to translate the 
tModelKey sent from [X] into their local tModelKey (matching the 
identifierBag in [X]).  Perhaps a findQualifer could be defined to the [Y] 
and [Z] to first do the translation (not discussed further here).

It would get more involved if, for example, [Z] propagated the request to 
another UDDI server [W] with which it also federates; [X] would not be 
aware of [W].

This is my understanding of what a federated search would involve.  There 
would be administrative actions (and perhaps APIs) to manage the 
federation.  An administrator would need to configure [X] to forward 
queries to [Y] and [Z].  Perhaps there could be filtering such that [X] 
would know that [Y] has the taxonomy specified in the find_business 
request, but [Z] does not, so [X] would not forward the request to 
[Z].  Maybe some of this can be defined as a TN/BP, but perhaps some 
aspects require new APIs.

I support the U.S. DoD, so it is likely that Army, Navy, and Air Force 
would have independent UDDI registries, but in some cases a user would want 
to look across all these UDDI's to find instances of a particular service 
throughput the DoD.  A federated query would solve this problem.

Has this capability been proposed as a requirement for UDDI v.Next?

Paul