W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Action item: embedded policy requirements/use case

From: Francisco Curbera <curbera@us.ibm.com>
Date: Wed, 3 Nov 2004 14:22:02 -0500
To: <public-ws-addressing@w3.org>
Message-ID: <OFC03D6DEF.FCAA3E71-ON85256F41.00676678-85256F41.006A63B0@us.ibm.com>

The question was raised of whether or why EPRs should explicitly architect
the use of "policy" information. Here are some considerations that I think
are relevant and may help inform the discussion:

1. Metadata that applies to an endpoint can be found in different ways.
Registry look-up or direct query to the endpoint are two prominent
examples. In addition, EPRs contain references to external metadata
(service description elements).  To obtain any of this information an
application needs to access external resources; the result is that in some
scenarios the metadata will not be accessible to the invoking application.

2. Embedding metadata inside the EPR allows these application to access the
endpoint w/o assuming availability of those external resources. A
bootstrapping example: an application receives an EPR and tries to query
the endpoint to discover its policies and the access protocols it supports.
If the endpoint does not support a default interoperability protocol, or
requires additional QoS protocols to be used on top of it, it will not even
be possible to do this query. Metadata embedded inside the EPR can be used
to provide the basic information to enable access to the endpoint for query
purposes. Detailed metadata for the business interaction can then be
retrieved  using a metadata request API.

3. Note that metadata directly encoded within an EPR will either extend,
confirm or contradict metadata that may be retrieved those other
mechanisms. To be useful, metadata within the EPR needs to have a well
defined relationship with whatever metadata available through other
mechanisms. The difference between relying on extensibiilty and
architecting the use of embedded metadata in the EPR is the oportunity of
providing clarity about how these issues are resolved.

These issues were behind the embedding of policy inside the EPR in the
current specification. As we prepare to throw out the dependency on
WS-Policy I think it would be important not to loose the architected
capability of dealing with these issues.

Received on Wednesday, 3 November 2004 19:22:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:06 UTC