- 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