RE: Action item: embedded policy requirements/use case

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
>

Received on Wednesday, 3 November 2004 20:26:05 UTC