Re: arch diagrams from the f2f

Hence the distinction between the relationship level and the task or 
contract level in my layered diagram :-)
Frank

On Thursday, September 19, 2002, at 10:39  AM, [email protected] 
wrote:

>
> There is yet another issue muddled together in the description space.
> We need to distinguish between describing the service provider and a
> service being offered.  As in real life, I might want to select a
> service not only on the basis of the service offered, but also on
> parameters associated with the provider (number of years in business,
> privacy policies, etc.).
>
> Maybe the top of the logical description hierarchy should look like:
>   service provider description
>     (properties of providers,
>      references to services they provide, ...)
>   service description
>     (properties of a service,
>      backpointers to service providers??,
>      references to service interface descriptions,
>      service addresses)
>   service interface description
>
> In some schemes, given a service address, you can recover the other
> information associated with the service.  To get the service address
> in the first place, however, you might have to search based on
> properties of the service.
>
> In other schemes, the search might return a reference to a resource
> that represents the entire service description (properties,
> interface descriptions, service addresses, etc.).
>
> In this modeling exercise, we should probably think hard about what
> things we want to explicitly think of as (URI-referenceable) resources
> by the way.
>
> Mark Jones
> AT&T
>
> 	From [email protected] Thu Sep 19 12:52 EDT 2002
> 	Delivered-To: [email protected]
> 	X-Authentication-Warning: mail-red.research.att.com: postfixfilter 
> set sender to [email protected] using -f
> 	Resent-Date: Thu, 19 Sep 2002 12:52:29 -0400 (EDT)
> 	Resent-Message-Id: <[email protected]>
> 	From: "David Orchard" <[email protected]>
> 	To: "'Mark Baker'" <[email protected]>, <[email protected]>
> 	Cc: <[email protected]>, <[email protected]>
> 	Date: Thu, 19 Sep 2002 09:48:24 -0700
> 	MIME-Version: 1.0
> 	Content-Transfer-Encoding: 7bit
> 	X-Priority: 3 (Normal)
> 	X-MSMail-Priority: Normal
> 	Importance: Normal
> 	X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> 	Subject: RE: arch diagrams from the f2f
> 	Resent-From: [email protected]
> 	X-Mailing-List: <[email protected]> archive/latest/2531
> 	X-Loop: [email protected]
> 	Resent-Sender: [email protected]
> 	List-Id: <www-ws-arch.w3.org>
> 	List-Help: <http://www.w3.org/Mail/>
> 	List-Unsubscribe: 
> <mailto:[email protected]?subject=unsubscribe>
> 	X-Spam-Status: No, hits=-3.1 required=5.0 
> tests=IN_REP_TO,MAY_BE_FORGED version=2.20
>
>
> 	I think there are 2 issues that are being muddled together.  We 
> probably
> 	need to separate them.
>
> 	There are at least 2 things that can be found from a "registry": The 
> actual
> 	address of a resource, and the interface for interacting with it.  
> Mark
> 	Baker is pointing out that there is no need to publish the input 
> interface
> 	for HTTP services, as HTTP defines the input interface.  For services 
> that
> 	use SOAP, or other XML defined inputs, there may a need to discover 
> the
> 	interface.  For example, a conversational web service might require a 
> soap
> 	header with a conversation ID or a callback address.  This discovery 
> could
> 	be through a variety of means - somebody mails me a copy of the spec, 
> I
> 	discover the spec in UDDI registry, I de-ref a namespace URI, etc.
>
> 	I think we need to distinguish between discovering the address of the
> 	service, and the shape or interface of messages to and from the 
> service.
>
> 	And BTW, I still don't think that HTTP is as generic as it appears.  
> To
> 	actually put information into the URL  and/or message, I as a human 
> still
> 	have to do some work.  Like fill in a form.  And the only way I know 
> what to
> 	put in the form is to "discover" the shape of the form from the web 
> site.
> 	So in a form case, I get an address to the service, and the service 
> provides
> 	the discovery mechanism and any new address for the actual service.  
> Imagine
> 	url A accesses return the form, and the form says that it should be 
> posted
> 	to url B.  Thus the discover/interact model for addresses and shapes 
> is used
> 	by the web.
>
> 	Cheers,
> 	Dave
>
> 	> -----Original Message-----
> 	> From: [email protected] 
> [mailto:[email protected]]On
> 	> Behalf Of Mark Baker
> 	> Sent: Thursday, September 19, 2002 9:37 AM
> 	> To: [email protected]
> 	> Cc: [email protected]; [email protected]; [email protected]
> 	> Subject: Re: arch diagrams from the f2f
> 	>
> 	>
> 	>
> 	> On Thu, Sep 19, 2002 at 11:08:17AM -0400,
> 	> [email protected] wrote:
> 	> > You somehow still have to come by the URI in the first
> 	> place, whether
> 	> > by work of mouth, google, etc.
> 	>
> 	> A previous GET ...
> 	>
> 	> >  Being spidered is a form of "publish".
> 	>
> 	> I'd say spidering was "interact" and "find".  "publish" would
> 	> be listing
> 	> your URI via POST at http://www.google.com/addurl.html
> 	>
> 	> > Using google is a form of "find".
> 	>
> 	> To search, sure.  But it's also "interact".
> 	>
> 	> I'm going to drop this now.  I'm trying hard to focus on the
> 	> architecture document and SOAP+WSDL, but I can't help but comment on
> 	> things I see being a concern later on.
> 	>
> 	> MB
> 	> --
> 	> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> 	> Ottawa, Ontario, CANADA.               [email protected]
> 	> http://www.markbaker.ca        http://www.idokorro.com
> 	>
> 	>
>
>