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

RE: Web Service Definition [Was "Some Thoughts ..."]

From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Date: Mon, 04 Mar 2002 23:29:59 -0800
Message-Id: <>
To: michael.mahan@nokia.com, <www-ws-arch@w3.org>
At 08:26 AM 3/1/02, michael.mahan@nokia.com wrote:
>I respectfully disagree that discovery is accounted for by defining that a 
>Web service is uri identifiable.
>  Uri identifiable enables accessibility, but is not sufficient to enable 
> discovery.

After reading and watching the email storm, it's hard to figure out where 
to jump in.

First off, I pretty much agree with the thrust of steve's arguments. We 
want a concise definition which pretty much captures the broad outlines. To 
be useful the definition can and should fuzz out all the details and fine 
points. That's what 100 page specs are for.

The point David Orchard (and others) have made about XML being required by 
the charter is a good one and I agree it is use in the WSA is pretty much 
unavoidable. It might be that in a more perfect world we'd be able to claim 
that XML is just one several technologies and shouldn't tie our hands. But 
in this world, at this time, the use of XML for a W3C spec in this area is 
pretty much a requirement and a given. If this is in fact a bad choice, 
then it will become evident.

Below are some comments and observations triggered by the D&D debate.

I think we need to allow for a variety of ways for "discovery" as defined 
below to take place. Basically what is needed is that it is possible to 
acquire metadata describing a WS which provides enough information to 
enable a potential client of a WS to make informed decisions about the use 
of the service.

There are a variety of ways one goes about acquiring this information. 
Possibilities include:
   a. someone whispering it in the client's ear
   b. someone placing a piece of paper on the client's desk
   c. receipt of an email with that info
   d. receipt of the info as a result of calling another WS
etc., etc.

At the end of the day, the point is that the WS client has to acquire "a 
bunch" of information (mostly metadata) that it then uses to invoke the WS.

Breaking the problem down this way leads to several sub-problems.

What metadata will be required? IMO a well-defined WSA will then define the 
properties (using an XML vocab I would assume) of said metadata.

How is that metadata retrieved? Again, a well-defined WSA will describe the 
"standard" ways (note there is more than one) that can be counted on in 
particular environments.

How is the metadata used by the client in order to "invoke" the WS? I think 
this implies "standard" invocation mechanisms (again note there will be 
more than one).

The cross-product of the "answers" to these questions essentially describes 
the various different kinds of WS clients.

So to my mind, one of the keys is for WSA is make sure that all the 
information is available in standard formats using standard protocols (in 
the generic sense) which are generally agreed upon. Once we have these 
things then one can use a variety of implementation techniques ranging all 
the way from humans exchanging telephone messages and fax machines to 
programs which operate without direct human intervention. As a side benefit 
we won't have to achieve consensus whether the former is a web service or not.

Nevertheless, having suggested several requirements on a WSA (above), does 
not necessarily imply that all of these points have to be in top level WS 

flame away :-)

>  Discovery means "to make known or visible"[1] and hence is the process 
> of acquiring the resource identifier and optionally, deciding whether it 
> is a resource worth binding.
>According to the WS documents I have read, Discovery means that a client 
>can, during runtime, in non apriori fashion, acquire identifiers to 
>resources, analyze them to meet sought criteria, and then invoke them. I 
>think Steve's earlier examples are clearly outside this desciption. Hence 
>I still believe that discovery should be thought of as an extension to 
>rather than a basic or core web service description.
>[1] http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=discovering
>Mike Mahan, Nokia
>-----Original Message-----
>From: ext Mark Baker [mailto:distobj@acm.org]
>Sent: March 01, 2002 09:53 AM
>To: Sandeep Kumar
>Cc: Vinoski Stephen; Joseph Hui; www-ws-arch@w3.org
>Subject: Re: Web Service Definition [Was "Some Thoughts ..."]
> > If D&D are not an integral part of a Web Service defintion,
>I was claiming that discoverability *is* an integral part of the
>definition.  It's just already accounted for by defining that a Web
>service be URI identifiable.
>I know this is a bit different than some Web service work people have
>already done, but this is (IMO) one of those times where our mandate to
>be integrated with Web architecture effects our work.
> > pl help me define
> > how would you define a Web (or a Network) of Web Services, the 
> participants.
> >
> > At a high-level, they must at least have the same characteristics. If not,
> > it would be much harder to reason about them semantically, deal with
> > managing & monitoring them.
>Sorry, I'm unclear what you're asking.
>Mark Baker, Chief Science Officer, Planetfred, Inc.
>Ottawa, Ontario, CANADA.      mbaker@planetfred.com
>http://www.markbaker.ca   http://www.planetfred.com

Jeff Mischkinsky                    jeff.mischkinsky@oracle.com
Consulting Member Technical Staff   +1(650)506-1975 (voice)
Oracle Corporation                  +1(650)506-7225 (fax)
400 Oracle Parkway, M/S 4OP960
Redwood Shores, CA 94065 USA
Received on Tuesday, 5 March 2002 02:48:04 UTC

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