- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Thu, 4 Nov 2004 01:49:54 +0600
- 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" ;-). Sanjiva. ----- 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 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. > > Paco >
Received on Wednesday, 3 November 2004 19:50:32 UTC