- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Fri, 11 Oct 2002 14:17:37 +0200
- 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 UTC