RE: Label for Top Node of "triangle diagram"

You guys are making my head hurt.  It just became clear to me that the
"cloud" is, itself, a web service.  So somehow we are defining web services
in some kind of recursive way?


I'm liking the triangle less an less by the minute.  Sorry -- maybe I'm just
misunderstanding here, but ...

If the cloud is, in fact, a web service -- then it seems to me that there
are two and only two reasonable diagrams for a web service, the cloud simply
being a replication of one of these fundamental components used for the
special purpose of discovering and describing the availability of web

1)Requestor/Receiver <-> Responder

2)Requestor -> Responder -> Receiver

-----Original Message-----
From: Dave Hollander [] 
Sent: Friday, September 27, 2002 1:05 PM
Subject: RE: Label for Top Node of "triangle diagram"

I agree that registries are not the only way to implement discovery! That is
why i quoted "place", but apparently I was not clear. I think we intuitively
knew this when we agreed that a --cloud-- was the best graphical icon for
this node.

Advertising - web pages advertise by being part of a hypertext network. If I
want a search engine to find my page, I have to 
make sure it is either in its explicit listing of pages (registry) or linked
to from a page that is.

Web services are not hypertext--there is no way to start at a 
node and explore links described at that node. Hence they need to advertise
in some form...either by phone, email to other service developers or
describe themselves to a well known mechanism (typically a registry).

Description - I am very interested in where and how people 
believe description happens. Is it an atomic transaction-- fully described
in one interchange--or composite? Who is 
responsible for what roles? How can you use a --cloud-- to
find a service if the --cloud-- does not provide some description? Will we
have to inquire directly to each service to select between them?  Is
description narrowly defined as the data in WSDL or does it include UDDI
concepts and others? I prefer the broader sense.

"Advertising and Discovery Mechanisms" - I could live with this but am not
afraid to use "services" either. I think we should describe them as
services, and as we add security, management, QOS etc we will end up
describing services. But that is a debate for a later day.


-----Original Message-----
From: Ricky Ho []
Sent: Friday, September 27, 2002 11:03 AM
To: Dave Hollander;
Subject: RE: Label for Top Node of "triangle diagram"

I think "registry" (in the way you describe it) is one way to implement a 
"discovery" mechanism.  The "roles" that you describe about a "registry" 
implies a centralized place where information is kept.  But "registry" 
shouldn't be the ONLY way to implement discovery.  For example, a 
peer-to-peer approach can be used to implement the discovery mechanism 
...  My response inline ...

>The roles, as I understand them, are:
>1) a "place" to advertise a service's availability

Do we really require the service to explicitly "ADVERTISE" its availability 
in a particular "PLACE" ?  Think about a web page, you don't need to 
advertise it and still able to be found in search engine.  What can't the 
service provider be using similar mechanism ?

>2) an agency that brokers services' descriptions

Like WSIL, we can discover the service's description at the endpoint.  It 
doesn't have to be in a separate agency.

>3) a "place" to discover what services are availabile

Again, it doesn't has to be "a place"

>Are these right?
>If so, my preferences:
>1) Advertising and Discovery Services

By the term "service", are you implying it has a WSDL description, and a 
particular endpoint address where the service is provided ?
Or are we actually talking about an "Advertising and Discovery Mechanism" ?

>2) Services Description and Discovery

They sounds to be different animals.

>3) Services Registries

This sounds to me strongly implying a "separate place" which I don't think 
is a necessary distinction.

Rgds, Ricky

Received on Friday, 27 September 2002 14:50:25 UTC