RE: WSA issue 1: what is a priori knowledge?

I think that this is an excellent analysis.  However, is it too late to
consider substituting the word "prior" for "a priori"?  I really think
that the meaning intended by everyone concerned is really more along the
lines of "prior", and that using this word would lessen the confusion.
The reason I think this is that the term "a priori" generally indicates
that something is known inherently or is self-evident.  I believe that
this connotation is essentially what causes people to sit up and say,
"Huh??" when they see its use in this context.  If we used the word
"prior" would it not serve just as well and alleviate the concern?  The
parties who are using web services to communicate simply do not have any
inherent or self-evident knowledge of each other, IMHO.

-----Original Message-----
From: Hugo Haas [mailto:hugo@w3.org] 
Sent: Wednesday, February 19, 2003 9:54 AM
To: www-ws-arch@w3.org
Subject: WSA issue 1: what is a priori knowledge?



All,

As promised in an earlier email[2], this is an attempt at making
progress on issue 1, "what is a priori knowledge?"[1].

The outcome of this discussion should be some text for the architecture
document, accurate definitions for the relevant terms in the glossary,
and hopefully resolution of issue 1 once we agree on the text and
definitions.

In [3], Paul Denning offered an interpretation:

| The lack of a priori knowledge by the communicating parties refers to 
| a degree of transparency about the underlying mechanisms used to 
| transfer a SOAP envelope.  It relates to the concept of layering, and 
| separation of interface from implementation, where higher layers make 
| use of an interface to lower layer mechanisms rather than duplicate 
| the functions of those lower layer mechanisms.
[..]
| The WSAWG charter's clause about "without third party agreement" gives

| us a clue of the concern about a priori knowledge.  An example of a 
| third party agreement would be if new SOAP features (SOAP header block

| namespaces, bindings, message exchange patterns, encoding styles, and 
| fault codes) could not be used unless W3C approved them.
[..]
| Other examples where a communicating party would not need a priori
| knowledge would be by using a runtime discovery mechanism, such as 
| UDDI.
| 
| SOAP faults are another way of dealing with a lack of a priori
| knowledge.  If a sender includes a SOAP header block marked with 
| mustUnderstand="true", a fault is generated if the receiver does not 
| understand it.

In [4], Mark Baker wrote:

| I think it means that the architecture should not require that parties
| have to visit a common third party in order to be able to communicate.
| 
| I've seen UDDI used in this way; that one party must go to a UDDI 
| registry to get the information necessary to access another.
| 
| More recently, people have adopted the convention of placing the WSDL 
| for a Web service on the end of a GET on the URI for that Web service.

| That is an excellent idea that we should encourage as best practice, 
| IMO, since it means that all you need is a URI, and no third party, to

| get started.

Trying to summarize all those ideas and going back to the basic meaning
of the words, "a priori knowledge" refers to what communicating parties
know about each other before starting interacting.

The glossary reads[5]:

| The amount of information that a client knows about a Web service that

| it is going to start interacting with.

Reading the above suggestions, it seems that a-priori knowledge appears
at several levels:
- at the functional level: the WSDL description of the service,
  support by the service of certain SOAP modules that the client would
  like to use (e.g. security ones), etc.
- at the semantics level: what the service does.

The glossary definition may therefore be too client- / service
requestor-centric. This definition could be made more symmetric:

  The amount of information that a service requestor and a service
  provider know about each other before starting to interact.

Indeed, the service may also be interested in knowing what extensions
the client is going to use. One can imagine some negotiation on the best
security extension to use based on what each party implements.

Now, let's try to go a step further. What does "no a-priori knowledge"
and "without third party agreement", which also comes into the picture
in this debate?

Let's talk about third party agreement agreement first, since it seems
(to me) to be easier. I believe that "without third party agreement"
refers to the fact that extension of the architecture -- such as the
creation of a new encryption mechanism --, or participation in the
architecture -- by participation, I mean creating a Web service and have
people use it --, may not require contacting a third-party. One can
think of any point of centralization, such mandating to use a new URI
scheme for a SOAP extension to be registered or anything similar.

Now, no a-priori knowledge. Surely there is _some_ a-priori knowledge
about any interaction. The minimum that one would think of is that one
of the parties, either the service or the client, is aware of the other.

Therefore, no a-priori knowledge actually means the minimum amount of
knowledge that communicating parties would have about each other in
order to interact.

A Web service being defined as[6]:

| A Web service is a software system identified by a URI [RFC 2396], 
| whose public interfaces and bindings are defined and described using 
| XML. Its definition can be discovered by other software systems. These

| systems may then interact with the Web service in a manner prescribed 
| by its definition, using XML based messages conveyed by Internet 
| protocols.

it seems that the minimum information that a client would have about a
Web service would be its URI.

As Mark was suggesting, since we are on the Web, one can think that
doing a GET or OPTIONS on this URI could give the client enough
information, both functional and semantic, to start interacting.

What about the server side of this equation? As Paul pointed out, a SOAP
receiver can tell a SOAP sender that a module is not supported thanks to
SOAP faults. Similarly, HTTP servers can indicate that a method is not
supported, or a request not understood, etc.

Therefore, I think that the lack of a-priori knowledge is characterized
by the client only knowing the URI of a service, and that the Web
services architecture should document how to bootstrap communication
from here, i.e. how to use this URI, what to get from the resource, and
also document the communication mechanisms such as SOAP faults that
allow client and service to understand each other.

Trying to relate this to the properties defined in Roy Fielding's
dissertation[8], minimizing a-priori knowledge increases modifiability,
and lack of third-party agreement increases scalability and simplicity.

And to refer to a previous fairly long thread about loose-coupling which
led to the definition that one can find in the glossary[7], I think that
"no a-priory knowledge" is a property of loose coupling, i.e. it
minimizes artificial dependency.

Sorry for the long post. Comments are welcome.

Regards,

Hugo

  1. http://www.w3.org/2002/ws/arch/2/issues/wsa-issues.html#x1
  2. http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0084.html
  3. http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0154.html
  4. http://lists.w3.org/Archives/Public/www-ws-arch/2002Apr/0028.html
  5.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.h
tml#apriori
  6.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.h
tml#webservice
  7.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.h
tml#loosecoupling
  8.
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_
2_3
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 19 February 2003 11:22:05 UTC