Re: Action item: embedded policy requirements/use case

Thanks for completing the AI, Paco.

For the benefit of people on the list who weren't at the F2F, this 
action came about to serve as a use case for decisions that we'll have 
to make; e.g., issues 14 and 24.

In that context, the question at hand is, if we remove policy from 
EPRs, what facilities will be necessary to accommodate adding this 
information in an extension later? E.g., a 'mustUnderstand' mechanism 
for EPR extensions was mentioned as being useful; does there need to be 
anything else in the core?

I read this use case as saying that defining things like the 
relationship of externally sourced to inline metadata is important; so, 
we need to figure out a) whether that will be defined in a generic way, 
and b) whether it will be specified by the documents we publish.

Cheers,

On Nov 3, 2004, at 3:25 PM, Ashok Malhotra wrote:

>
> Sanjiva:
> First, please explain how you refer to a msg that is going to be sent 
> in the future.  That's a neat trick.  The msg is still perhaps in 
> Paco's brian!
>
> On the policy reference, Paco's points are well taken and shd be 
> considered.
>
> If we remove the policy reference from the EPR we need a mechanism that
> can access the metadata a) without access to another resource and b) 
> no matter
> what the policy is.  I think a simple syntax using the EPR URI can do 
> this.
>
>
> All the best, Ashok
>
> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Sanjiva 
> Weerawarana
> Sent: Wednesday, November 03, 2004 11:50 AM
> To: public-ws-addressing@w3.org
> Subject: Re: Action item: embedded policy requirements/use case
>
>
> 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
>>
>
>
>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 4 November 2004 20:57:53 UTC