|
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
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
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
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.
|