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

Re: what is discovery - One concrete proposal

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Fri, 11 Oct 2002 14:17:37 +0200
Message-ID: <3DA6C161.9080804@crf.canon.fr>
To: Heather Kreger <kreger@us.ibm.com>
CC: www-ws-arch@w3.org

Heather,

I agree with everything you've said. My question was really 
whether what you call "static binding" is supported by Dave's 
definition.

Axiom 2 ("early") and axiom 4 ("was already know") suggest it 
might, but unless I've missed anything obvious, I don't get a 
clear answer from Dave's definition (but I get a clear answer 
from your message!).

Jean-Jacques.

Heather Kreger wrote:
> Discovery can be done before the client is developed, while the client is
> being developed (hence it is pre-compiled in). This is the most common
> scenerio being deployed today.  In IBM we call this static binding.
> 
> Discovery can also be done by the client at runtime. There are two types of
> runtime binding:
> 1. The client has already discovered the interface, has programmed to it,
> and just the service instance (location from the WSDL) is discovered at
> runtime. This scenario is being deployed today, but less often than static
> binding.  WSIF supports this type of binding.
> 
> 2. The client discovers the interface specifics and the service instance
> during runtime. In the deployments of this that I know of, they use a DII
> style interface, like the JAXRPC call object or the WSIF apis to figure out
> what message to create, create it and process the results.  There are not
> many of these out there.
> 
> Heather Kreger
> Web Services Lead Architect
> STSM, SWG Emerging Technology
> kreger@us.ibm.com
> 919-543-3211 (t/l 441)  cell:919-496-9572
> 
> 
> "Jean-Jacques Moreau" <moreau@crf.canon.fr>@w3.org on 10/11/2002 02:42:42
> AM
> 
> Sent by:    www-ws-arch-request@w3.org
> 
> 
> To:    Dave Hollander <dmh@contivo.com>
> cc:    www-ws-arch@w3.org
> Subject:    Re: what is discovery - One concrete proposal
> 
> 
> 
> 
> A SOAP client may use a service where the service information is
> obtained out of band (e.g. it may be precompiled into the
> client). Is this supported by your current definition or are you
> implying that discovery is mandatory (I don't read anything like
> discovery is optional)?
> 
> Jean-Jacques.
> 
> Dave Hollander wrote:
> 
>>To try to get temporary closure on the discovery,triangle,
>>and cloud, let me try to state one position.
>>
>>Recommendation:
>>1. Leave it in the spec dract as is or ammended with axioms
>>   from below.
>>
>>2. Add an example where "discovery" is a trivial role because
>>   there are two parties directly exchanging information that
>>   is hardwired into the service.
>>
>>3. Label the node "Discovery Agencies"
>>
>>--------------------------------------------------------------
>>
>>Discovery = exchange of the service description details necessary
>>to make a conncection.
>>
>>Discovery Axioms:
>>
>>1) discovery need not rely upon formal documents.
>>
>>2) discovery occurs regardless of when the discovered
>>    information is bound into the connection (early or late).
>>
>>3) discovery is discovery regardless if the provider or
>>    requestor does the advertising.
>>
>>4) discovery is discovery even if the data discovered was
>>    already known. All that needs to be true is the potential
>>    that the data *may* be different or new.
>>
>>5) discovery is discovery even if there are only two parties,
>>    requestor and provider.
>>
>>
>>I believe that "discovery", as defined above, exists as a
>>role in all of the scenarios that have been presented here.
>>
>>So that leads to the question: is "discovery", as defined above,
>>relevent enough to be included in our base architecture?
>>
>>I believe discovery is relevent and should be in the
>>base architecture for the following reasons:
>>
>>1. the distinction between hypertext and web services
>>   web has hypertext links to create a network, web
>>   services currently do not have a mechanism for defining
>>   a newtwork.
>>
>>2. good for the "ilities" (scalability, reliability, etc)
>>
>>3. it always happens, just sometimes it is done outside
>>   of the system.
>>
>>4. Most people expect to see it. If it is not there, our
>>   audience will either be disappointed or will try to find
>>   it. Either way confusion and mixed understanding will result.
>>
>>
>>
>>
> 
> 
> 
> 
> 
Received on Friday, 11 October 2002 08:17:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT