Top cloud in triangle/rectangle diagram

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