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

How about:

third party -  One other than the principals involved in a transaction

(not to be confused with party no. 3 in a 3-party interaction)

For example, if two parties decide to standardize a SOAP header for the
purpose of performing some complex operation, they can reach a mutual
agreement without involving a third party.

If the header is of interest to all companies working in the insurance
industry than it can be standardized by some group in that space (not a 3rd
party). However, if all headers must be ratified by the IETF, which has no
specific interest in insurance, that would constitute a 3rd party.

The fact that anyone can define a header, individually or within some
interest group, implies that no 3rd party is required to specify headers.

The same when using UDDI. For convenience I can decide to use a UDDI as a
directory shared by multiple participants. If the UDDI can be limited to
only those interested participants (e.g. buyers and suppliers of aluminium)
then no 3rd party is involved. If the UDDI must range across all service
users/providers, then a 3rd party is involved.


As for 'a priori knowledge', I agree that the term is often confused to mean
self-deduct, intuitive, etc. Even though in this case it means 'former',
some a priori knowledge would be required in order to understand how a
priori knowledge is used in this document ;-)

No a priori knowledge should mean no knowledge whatsoever. Obviously to send
a message to a service I need to know about that service, so a priori
knowledge is required. The question could better be phrased: 'is a priori
knowledge required in order to interact with a service once I learn about
that service?'.

'A priori' should also be constrainted to talk about the service not the
service type. Obviously if I want my purchase order to be fulfilled I need
to know a lot about purchase orders. If I want to use a phone I need a
priori knowledge about phones. But if I forgot my phone at home and want to
use yours, do I need a priori knowledge about your phone?

The correct answer is yes: I need to know the number to dial for an outgoing
line, and the area code from which I'm dialing. But a smart phone could let
me determine that easily with applicable operations. Being able to get
meta-data about a service using a well-defined service type (e.g. WSIL,
UDDI) helps in reducing a priori knowledge,

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hugo Haas
> Sent: Wednesday, February 19, 2003 7: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.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 16:02:16 UTC