At 09:40 PM 10/2/2002 -0400, Christopher B Ferris wrote:
>David,
>
>I don't think anyone disagrees with these points. But a role does NOT
>imply a central place . . . .
I understand that you think of the term "a role" as being all-inclusive,
but I don't think it is. Even asserting that there is "a role" is making
some assumptions. I'll try to explain more clearly with some diagrams.
Slide1 (attached) views the top of the triangle as "a role". It clearly
allows any publishing/discovery agency (or "registry" or whatever you want
to call it), but it CLEARLY implies that the "Publish" and "Find" actions
are using the SAME publish/discovery agency. (For this reason, I do not
advocate this diagram, and I would hope that no one else would either,
except as an example of ONE style of implementation.)
Slide2 (attached) also views the top of the triangle as "a role". It
SOMEWHAT implies that the "Publish" and "Find" actions are using the same
publish/discovery agency. However, the cloud makes the implication less
conclusive. This ambiguity is important because it suggests that we are
not constraining what that top part is or does.
Slide3 (attached) shows a rectangle instead of a triangle. It doesn't have
"a role" at the top, it has TWO roles. It CLEARLY suggests that the action
of "Publishing" may use an entirely different agency than the action of
"Finding". For example, the Service Provider may "Publish" it's
description to a UDDI registry, but the Service Requester may "Find" that
description in a "Jack-Sprat's-Favorite-Web-Services" registry. (Jack
Sprat may be providing a very valuable service by consolidating WS
descriptions from many sources.)
Slide4 (attached) has no role at all for the top part. The Service
Provider, by some means (spam?), has advertised its description DIRECTLY to
the Service Requester. From an architectural viewpoint, there is no third
party involved. (Obviously there may be a third party involved physically,
such as a router, or TCP store-and-forward nodes, but that is true of any
network connection and is irrelevant from an architectural point of view.)
Clearly, our architecture should accommodate all of the above
scenarios. By drawing the architecture as a triangle with "a role" at the
top, we ARE making some assumptions that reflect certain biases. We can
mitigate those assumptions: (a) by drawing the top thing as a cloud instead
of an atomic node; (b) by carefully selecting our labels; and (c) by our
accompanying descriptive text. All three of these techniques are important
to use.
>No one to my knowledge is advocating an exclusive, centralized model for
>discovery. . . .
It is true that nobody has advocated a PARTICULAR or EXCLUSIVE centralized
model, but that wasn't the issue.
Some have advocated the use of the word "registry" or "registries" to refer
to the top cloud. And CLEARLY, for many or most people, the word
"registry" suggests a central or common "meeting place", whether it is
implemented in a centralized or distributed (gnutella) fashion, and whether
there is only one or more than one.
We CAN talk about the action of "publishing", and the action of "finding".
But unless we know what mechanisms they use, there is virtually nothing we
can say about the top cloud in the diagrams. We cannot even assume that
the "Publish" and "Find" actions are interacting with the same entity.
>. . . this inane debate . . . .
Well, the debate really isn't about arbitrary terms. It is about the
underlying architectural assumptions that are implied by our terms and
diagrams. It is clear that some people have made some assumptions while
others have made others, and we DO need to come to agreement about those
assumptions.
--
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273