RE: [uddi-spec] Federated Query

[Paul Denning <pauld@mitre.org>]

Thanks for the reply Tony.

Therefore,

1.  RQ 021 does not address federated query, and
2.  UDDI Spec TC will not add any other requirement to support such a 
federated query

Right?

Anyone looking at using BPEL to orchestrate discovery queries across 
multiple independent registries (either all UDDI, or perhaps a mixure of 
UDDI and non-UDDI (e.g., ebRS))?

Paul

At 04:29 PM 2004-06-03, Rogers, Tony wrote:
>What you are describing is called "distribution" in x.500. Apart from the 
>different name, it is essentially the same concept. It is not trivial to 
>implement.
>
>It would require replication of tModels, at least those tModels which 
>define taxonomies, because it would be essential that the taxonomies be 
>kept synchronized. Domain keyGenerator tModels would also be replicated 
>(they would be the method for distinguishing which keyed entities were on 
>which node).
>
>Consider a fourth node, D, which is linked only to C, but which is another 
>member of the federation. When C receives the request from A, should C 
>then forward the request to D, and include D's response with C's? Or do we 
>require that the federation be fully connected, so that the originator, A, 
>can send the request to all other nodes of the federation directly? (it 
>gets even more interesting if D is linked to B and C, but not to A...)
>
>This is quite a complicated subject. It took quite a while to sort out in 
>the development of x.500. I'm not sure that this is an area that we should 
>be venturing into without some careful thought, but there are some 
>compelling use-cases - as you point out, there may well be clusters of 
>registries where this functionality will be required.
>
>Tony Rogers
><mailto:tony.rogers@ca.com>tony.rogers@ca.com
>-----Original Message-----
>From: Paul Denning [mailto:pauld@mitre.org]
>Sent: Fri 04-Jun-04 3:10
>To: uddi-spec@lists.oasis-open.org
>Cc:
>Subject: [uddi-spec] Federated Query
>
>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>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