RE: Top cloud in triangle/rectangle diagram

"Christopher B Ferris" <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
Message-ID <OFB22869CA.99C24B4E-ON85256C4C.003F6759-85256C4C.003FC5C9@rchland.ibm.com>
+1

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

[email protected] 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 
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?
> 
> 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 .. ([email protected])
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> 
> -----Original Message-----
> From: David Booth [mailto:[email protected]] 
> Sent: Monday, October 07, 2002 5:17 PM
> To: Sedukhin, Igor; [email protected]
> 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 
parties 
> already know each other!  There is no "search" whatsoever to "discover" 
the 
> WSDL.
> 
> 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 
with.
> 
> >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 
scenario, 
> 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 
Sue 
> 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 
both 
> 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 
Sue, 
> and how many parties it passes through on its way, is totally 
irrelevant.
> 
> In short, I totally agree that it is POSSIBLE to hypothesize a third 
party 
> role.  My point is that the additional third party role isn't necessary 
or 
> 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., 
another 
> conceptual component) may be needed in SOME scenarios.  That's why it 
may 
> be useful in an EXTENDED architecture.  But it clearly is not relevant 
in 
> 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 
WSDL 
> goes through 0, 1, 2 or 20 intermediate parties.  (See the attached 
slides 
> Slide9 - Slide13 for an illustration.) There is no more need to 
hypothesize 
> one intermediary as there is to hypothesize 0, 10 or 20 
> intermediaries.  The existence or non-existence of ANY intermediary 
parties 
> is irrelevant to this scenario.
> 
> 
> -- 
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.