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.html#apriori
  6. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html#webservice
  7. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html#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 10:54:09 UTC