RE: Label for Top Node of "triangle diagram"

My comments are also in line, except...I already
agreed that I am not arguing FOR centralized.

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Saturday, September 28, 2002 8:50 AM
To: Dave Hollander; www-ws-arch@w3.org
Subject: RE: Label for Top Node of "triangle diagram"


Dave, my comments inline !

At 11:04 AM 9/27/2002 -0700, Dave Hollander wrote:
>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.

[Ricky]
I think there are two major differences.  First one is you usually DON'T do 
this EXPLICITLY (and of course, there is no guarantee that your page will 
be found).  Second one is you DON'T go to centralized place to do that.

<daveh>
Well, that depends. As a former webmaster for a major corporate site,
I did explicitly register and test to assure my material was covered.
And my internal sites (>1 Million docs) did manage a centralized 
registry to list starting points for crawlers.

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

[Ricky]
It has to be "exposed" in some way.  But it doesn't need to be a "central 
place".  Think about the Gnutella model.

<daveh>
Nope, not a central place, but where and how? There is no implicit
hypertext network to crawl, so how are service providers to assure that
they service is found? 

No matter what we say, the providers and discovery service operators 
will find a way. Sometimes they will be satisfied with an more
organic like Gnutella, other times they will insist on a more
regimented model like MP3.com.


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

[Ricky]
I assume you are talking about "runtime-discover" here.  In this case, I 
agree the "cloud" need to provide some metadata to look for the qualified 
service provider candidate.  But whether it needs to host the WSDL is in 
question.  We certainly can put the service description at the endpoint 
(which I think to be outside the cloud).  Me too, I prefer a broader sense.

<daveh>
I think we have agreement
--some description will occur at least two of the nodes 
	(service provider and discovery thingy).
--description is more than just WSDL

Anybody disagree?


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

[Ricky]
Think about serialization/de-serialization a SOAP message to a local 
object.  Can we call it "data marshalling service" ?  When we use the term 
"service", it makes me (or other people as well) think that it is a remote 
functionality accessible via SOAP message exchanges.  And then I would 
think about performance overhead, exceptional handling ... etc, which may 
be not applicable if the functionality is local.

<daveh>
I guess it depends on the semantics we choose to put on "service". If we
agree that "service" is a logical function suitable for access via SOAP,
then I think discovery type functions qualify and data marshalling does
not. BTW, just because it is suitable, does not mean that SOAP is the
only invocation method supported.

Regards, DaveH

Rgds, Ricky

Received on Monday, 30 September 2002 11:39:22 UTC