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

Re: Action item: embedded policy requirements/use case

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Thu, 4 Nov 2004 01:49:54 +0600
Message-ID: <00fc01c4c1de$4b9dcdb0$70734109@LANKABOOK>
To: <public-ws-addressing@w3.org>

Also .. precendence from CORBA IORs .. tagged profiles.

Maybe mentioning that was not a good idea .. I can hear the
keyboards rattling saying "see, that's exactly why it should
not be there" ;-).


----- Original Message ----- 
From: "Francisco Curbera" <curbera@us.ibm.com>
To: <public-ws-addressing@w3.org>
Sent: Thursday, November 04, 2004 1:22 AM
Subject: Action item: embedded policy requirements/use case

> 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
> 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
> 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
> 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
> 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.
> Paco
Received on Wednesday, 3 November 2004 19:50:32 UTC

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