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

RE: arch diagrams from the f2f

From: <jones@research.att.com>
Date: Thu, 19 Sep 2002 13:39:45 -0400 (EDT)
Message-Id: <200209191739.NAA28404@bual.research.att.com>
To: distobj@acm.org, dorchard@bea.com, jones@research.att.com
Cc: kreger@us.ibm.com, www-ws-arch@w3.org

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

	From www-ws-arch-request@w3.org Thu Sep 19 12:52 EDT 2002
	Delivered-To: jones@research.att.com
	X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to www-ws-arch-request@w3.org using -f
	Resent-Date: Thu, 19 Sep 2002 12:52:29 -0400 (EDT)
	Resent-Message-Id: <200209191652.g8JGqTl14186@frink.w3.org>
	From: "David Orchard" <dorchard@bea.com>
	To: "'Mark Baker'" <distobj@acm.org>, <jones@research.att.com>
	Cc: <kreger@us.ibm.com>, <www-ws-arch@w3.org>
	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: www-ws-arch@w3.org
	X-Mailing-List: <www-ws-arch@w3.org> archive/latest/2531
	X-Loop: www-ws-arch@w3.org
	Resent-Sender: www-ws-arch-request@w3.org
	List-Id: <www-ws-arch.w3.org>
	List-Help: <http://www.w3.org/Mail/>
	List-Unsubscribe: <mailto:www-ws-arch-request@w3.org?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.


	> -----Original Message-----
	> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
	> Behalf Of Mark Baker
	> Sent: Thursday, September 19, 2002 9:37 AM
	> To: jones@research.att.com
	> Cc: distobj@acm.org; kreger@us.ibm.com; www-ws-arch@w3.org
	> Subject: Re: arch diagrams from the f2f
	> On Thu, Sep 19, 2002 at 11:08:17AM -0400,
	> jones@research.att.com 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.               distobj@acm.org
	> http://www.markbaker.ca        http://www.idokorro.com
Received on Thursday, 19 September 2002 13:40:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:59 UTC