RE: Top cloud in triangle/rectangle diagram

Igor,

I really think you're trying very hard to force fit a role that doesn't 
need to be there IN THIS CASE.  To further illustrate, let me throw one 
more monkey wrench into the works.  :)

Consider this scenario:
BobCo is a big, influential company.  BobCo wants its suppliers to 
implement Web Services so that BobCo can order its parts automatically, as 
a Service REQUESTER (i.e., WS Client). SallyCo (one of BobCo's suppliers) 
has been a little slow to implement their Web Service.  To speed up the 
process, BobCo writes a WSDL document describing the Web Service that it 
wants SallyCo to implement (as a Service PROVIDER).  BobCo sends the WSDL 
to SallyCo, along with a description of the intended semantics.  SallyCo 
agrees, and implements the Service.  BobCo starts placing orders as a 
CLIENT of  SallyCo's Web Service, and everybody's happy.

Where is the "discovery"?  There is none.  In fact, in this scenario, the 
WSDL was sent in the opposite direction!  It was sent from the Service 
REQUESTOR (BobCo) to the Service PROVIDER (SallyCo)!

You may be tempted to assume that the roles are simply reversed, and BoBCo 
is now acting as the Service PROVIDER.  But they aren't.  And it isn't a 
peer-to-peer situation either.  BobCo is not operating a Web Service at 
all!  BobCo ONLY invokes SallyCo's Web Service as a CLIENT, and SallyCo 
ONLY operates as a SERVICE -- never as Client.

The whole point is that in these scenarios (and many others), the ONLY 
thing that matters is the Web Service description itself.  It makes no 
difference who wrote it, what direction it travelled, how it got from one 
place to another, or how many hypothetical parties it passed through along 
the way -- whether they be called "Discovery Agencies" or anything 
else.  See what I mean?

At 09:57 PM 10/7/2002 -0400, Sedukhin, Igor wrote:
>I'll be difficult for a while longer, but I really do believe in what I 
>say here :)...
>
>Here is my reasoning for all the associated roles (in response to David):
>
>1. Even if parties already know each other, they didn't know about the 
>services, did they? Why was a WSDL sent in the scenario provided?
>
>2. If they didn't do it right at the time of interaction, may be they did 
>it a year ago or in some weird way. But requestor did "Find" somehow, even 
>if WSDL was written in Sanskrit on a stone :). [And so Jane advertised to 
>Sue who found Jane and vice versa, so both played a role of an 
>"Advertiser" at one point.]
>
>3. If we assume that "Find" does not happen and there is nobody and no way 
>at all to do the "Advertising". Then meeting two parties is a miracle. Is 
>there a logical way of explaining that? Did I know that WSDL from my birth 
>or how?

No, it isn't a miracle.  It just isn't relevant to the architecture.  The 
WSDL document itself is relevant, but "who" created it and "how" it gets 
there are not.

>It would be unreasonable to create a basic architecture blueprint that has 
>a hole and starts from the midway.
>I'm fine to call that "donkey caravan" an "Advertizer". I would prefer 
>that to starting without an explanation to the "Requestor knows about a 
>Service" phenomenon.
>
>I can see that the act of "discovery" is not important sometimes, so let's 
>call that "static discovery/binding", but not execlude from the architecture.

I'm not suggesting that we exclude "discovery" from the architecture 
altogether.  I'm saying it doesn't belong in the BASIC architecture.  There 
may well be scenarios for an EXTENDED architecture that require a concept 
of "discovery", but these don't.

>I think that receiving a WSDL and creating a language-bound proxy is 
>really that, static discovery.
>
>[In case of WSDL intermediaries, it is a realization detail. Altogether 
>they play a role of a big indifferentiable "Advertizer" for the 
>communicating parties.] I guess it could be "Advertizers".
>
>-- Igor Sedukhin .. (igor.sedukhin@ca.com)
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Tuesday, 8 October 2002 01:40:51 UTC