RE: Label for Top Node of "triangle diagram"

+1

I want to emphasize that Heather is talking about ROLES here, not things, 
not
mechanisms. A role is an abstraction as are the other nodes (roles) in the 
triangle
diagram.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: [email protected]
phone: +1 508 234 3624

Heather Kreger wrote on 09/27/2002 03:46:56 PM:

> 
> The triangle is a logical look at some roles:
> requester/provider/registry-cloud-thing, some communications: publish,
> find, interact, and some artifacts: service, service description.
> 
> The fact that you can implement any of these as a web service itself is
> orthogonal.
> 
> Other things we seem to be introducting, like intermediaries, can also 
be
> realized as web services. In fact, an intermediary might function both 
as
> an intermediary and a useful service in his own right accessed directly 
by
> other web service requesters.
> 
> And yes, I can seem many useful ways to realize some of our other roles 
as
> web services (security manager? etc.)
> 
> This does not break my head. This just means that the fundamental
> characteristics we define for web services can be shared by other roles 
as
> well. Its a feature, not a bug. :-)
> 
> Heather Kreger
> Web Services Lead Architect
> STSM, SWG Emerging Technology
> [email protected]
> 919-543-3211 (t/l 441)  cell:919-496-9572
> 
> 
> "Cutler, Roger (RogerCutler)" <[email protected]>@w3.org on
> 09/27/2002 02:50:02 PM
> 
> Sent by:    [email protected]
> 
> 
> To:    "'Dave Hollander'" <[email protected]>, [email protected]
> cc:
> Subject:    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?
> 
> Ouch!
> 
> 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
> services:
> 
> 1)Requestor/Receiver <-> Responder
> 
> 2)Requestor -> Responder -> Receiver
> 
> -----Original Message-----
> From: Dave Hollander [mailto:[email protected]]
> Sent: Friday, September 27, 2002 1:05 PM
> To: [email protected]
> 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.
> 
> 
> DaveH
> 
> -----Original Message-----
> From: Ricky Ho [mailto:[email protected]]
> Sent: Friday, September 27, 2002 11:03 AM
> To: Dave Hollander; [email protected]
> 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
> 
> [Ricky]
> 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
> 
> [Ricky]
> 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
> 
> [Ricky]
> Again, it doesn't has to be "a place"
> 
> 
> >Are these right?
> >
> >If so, my preferences:
> >
> >1) Advertising and Discovery Services
> 
> [Ricky]
> 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
> 
> [Ricky]
> They sounds to be different animals.
> 
> >3) Services Registries
> 
> [Ricky]
> This sounds to me strongly implying a "separate place" which I don't 
think
> is a necessary distinction.
> 
> Rgds, Ricky
> 
> 
> 
>