W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Top cloud in triangle/rectangle diagram

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Tue, 8 Oct 2002 07:37:47 -0400
To: "Sedukhin, Igor" <Igor.Sedukhin@ca.com>
Cc: "David Booth" <dbooth@w3.org>, "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>, www-ws-arch@w3.org, www-ws-arch-request@w3.org
Message-ID: <OFB22869CA.99C24B4E-ON85256C4C.003F6759-85256C4C.003FC5C9@rchland.ibm.com>

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 10/07/2002 09:57:41 PM:

> 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 
> 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?
> 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 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
> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org] 
> Sent: Monday, October 07, 2002 5:17 PM
> To: Sedukhin, Igor; www-ws-arch@w3.org
> Cc: Cutler, Roger (RogerCutler)
> Subject: RE: Top cloud in triangle/rectangle diagram
> At 11:49 AM 10/7/2002 -0400, Sedukhin, Igor wrote:
> >Here is my interpretation of the Roger's scenario [at
> >http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0072.html]
> >
> >The guy in Widgets-R-Us who picked up the phone and then received an
> >e-mail with the WSDL did "Find" a service.
> You are really stretching the meaning of the word "Find".  The two 
> already know each other!  There is no "search" whatsoever to "discover" 
> The concept of "finding" or "discovering" an appropriate service is only 

> relevant if the two parties DON'T already know who they want to interact 
> >The guy in FredCo who responded to the phone call and then e-mailed the
> >WSDL, played a role of an "Advertizer".
> >The other guy in FredCo who created a WSDL or otherwise told the 
> >"Advertizer" guy about the WSDL did "Publish" a service.
> >
> >I think the proper architectural roles were played well :).
> Well of course, if you ASSUME that a third role is needed, then you can 
> claim that the third role is invisibly played by one of the existing 
> parties. But that's an unfair assumption.  My point is that there is no 
> need or benefit in hypothesizing this extra, third role in this 
> and therefore we should not.
> Consider this Jane/Sue analogy:
> Jane and Sue are good friends, living across the river from each 
> other.  They decide to build a bridge so that they can easily have lunch 

> together every day.  Jane agrees to build her side of the bridge, and 
> agrees to build her side.  Jane draws up a blueprint for the bridge, and 

> sends it to Sue, who agrees to the design.  They build the bridge from 
> ends, it meets in the middle, and the next day they have lunch at the 
> middle of the bridge.
> It would be silly to claim that Jane invisibly plays a third party 
> "blueprint advertiser" role that enables Sue to "discover" the bridge 
> blueprint.  The important thing that allows the bridge to meet in the 
> middle is the blueprint itself.  How the blueprint gets from Jane to 
> and how many parties it passes through on its way, is totally 
> In short, I totally agree that it is POSSIBLE to hypothesize a third 
> role.  My point is that the additional third party role isn't necessary 
> useful to this scenario.  It adds complexity to the architecture that is 

> irrelevant to this scenario.
> >I hope I'm not trying to be difficult :), but I'd like to see a BASIC 
> >WS
> >architecture that does not need the act of meeting two parties and 
> >therefore does not need those roles.
> Clearly, defining three roles instead of two roles is ADDING complexity 
> not reducing it.  That additional architectural complexity (i.e., 
> conceptual component) may be needed in SOME scenarios.  That's why it 
> be useful in an EXTENDED architecture.  But it clearly is not relevant 
> this simple, very common scenario.
> The important part of this interaction is the WSDL document itself. THAT 

> is what the two parties must agree upon.  (They could send the WSDL by 
> donkey caravan for all I care!)  Furthermore, it doesn't matter if the 
> goes through 0, 1, 2 or 20 intermediate parties.  (See the attached 
> Slide9 - Slide13 for an illustration.) There is no more need to 
> one intermediary as there is to hypothesize 0, 10 or 20 
> intermediaries.  The existence or non-existence of ANY intermediary 
> is irrelevant to this scenario.
> -- 
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
Received on Tuesday, 8 October 2002 07:38:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:41 UTC