Good question.
But taking a step back, I am not sure what EPR is trying to do -- is it
trying to provide a referencing mechanism for a Web service/endpoint or
provide such a reference with additional bag of coordination/context
related data. Both seem like a useful thing to do, but my concern is
that EPR construct does not provide a clear separation of the two. I.e.,
provide a referencing mechanisms at the base layer and build on it by
providing a way to including coordination/context related data (thru ref
properties/ref parameters). It seems like architecturally it makes sense
to separate the two.
-Anish
--
Savas Parastatidis wrote:
> All,
>
>
>
> How do the changes in the submitted version of WS-Addressing affect
> WS-RF? It seems that WS-Addressing now has a canonical way of reasoning
> about EPR equivalence. Will WS-RF continue to use “reference properties”
> for its IRP requirements or will it have to move to “reference parameters”?
>
>
>
> Regards,
>
> --
> Savas Parastatidis
> http://savas.parastatidis.name
>
>
> ------------------------------------------------------------------------
>
> *From:* Steve Graham [mailto:]
> *Sent:* 10 August 2004 20:25
> *To:*
> *Cc:*
> *Subject:* [wsrf] WS-Addressing submitted to W3C as input
>
>
>
>
> Folks:
> Please see: http://www.w3.org/Submission/2004/05/.
> This is a submission request to the W3C by BEA, IBM, Microsoft, SAP and
> Sun to submit WS-Addressing to W3C as input to the standardization process.
>
> I would like to recommend that we consider using WS-Addressing as
> submitted to the W3C in our work in WS-RF and WS-N. Note, our use of
> WSDL 1.1 (which was a submission to W3C, just like WS-Addressing is now)
> is a precedence for this sort of pre-requisite.
>
> I formally move that we use WS-Addressing as our only means of reference
> mechanism. In particular, I propose that we avoid abstracting the
> reference mechanism, such as BPEL has done, in light of this submission
> of WS-Addressing to W3C. Note, this minimizes the perturbation to the
> currently specified message exchanges, and reduces migration impediments
> for implementations that are building to the 1.1 and 1.2 versions of our
> specifications.
>
> sgg
>
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
>
