- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Fri, 27 Sep 2002 16:27:47 -0400
- To: www-ws-arch@w3.org
- Message-ID: <OFA27A4648.A65C2665-ON85256C41.006D9C8D-85256C41.00704B63@rchland.ibm.com>
+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: chrisfer@us.ibm.com 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 > kreger@us.ibm.com > 919-543-3211 (t/l 441) cell:919-496-9572 > > > "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>@w3.org on > 09/27/2002 02:50:02 PM > > Sent by: www-ws-arch-request@w3.org > > > To: "'Dave Hollander'" <dmh@contivo.com>, www-ws-arch@w3.org > 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:dmh@contivo.com] > Sent: Friday, September 27, 2002 1:05 PM > To: www-ws-arch@w3.org > 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:riho@cisco.com] > Sent: Friday, September 27, 2002 11:03 AM > To: Dave Hollander; www-ws-arch@w3.org > 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 > > > >
Received on Friday, 27 September 2002 16:28:30 UTC