OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [uddi-spec] Federated Query

Title: [uddi-spec] Federated Query
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
-----Original Message-----
From: Paul Denning [mailto:pauld@mitre.org]
Sent: Fri 04-Jun-04 3:10
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Federated Query

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


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?


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]