RE: Using attributes to mark RefProp's and RefParam's

Technically viable? Yes.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> wrote on 11/24/2004 
06:25:39 PM:

> So technically this is a viable solution ("we don't lose the ability to
> leverage the SOAP processing model") right? If yes, I will write up some
> scenario for using it (intermediary/management/proxy type of scenario)
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Christopher B
> Ferris
> Sent: Wednesday, November 24, 2004 5:54 PM
> To: Srinivas, Davanum M
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> 
> I'm still unclear as to why you think it necessary. If an endpoint
> publishes an EPR with ref props and/or params, one assumes that it is
> doing so full in the knowledge as to what it intends to do with these as
> SOAP headers.
> The one thing that distinguishes them in the context of an EPR is that
> ref props are used in determinging EPR equivalence (e.g. that the two
> equivalent EPRs have the same metadata (WSDL, schema, policy, etc.) The
> intent of defining EPR equivalence is specifically so that the sending
> node can know which policies it can expect will be applied (or which to
> apply).
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> public-ws-addressing-request@w3.org wrote on 11/24/2004 05:21:17 PM:
> 
> > Is this a hot potato? :) no replies so far :)
> > 
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> > Srinivas, Davanum M
> > Sent: Wednesday, November 24, 2004 12:56 PM
> > To: public-ws-addressing@w3.org
> > Subject: Using attributes to mark RefProp's and RefParam's
> 
> > Team,
> > Me and Igor were chatting about how to mark RefProp's and RefParam's 
> > on
> the way back AND still not
> > "lose the ability to leverage the SOAP processing model", here's the
> outcome?..Comments?
> > Suppose we have an EPR which says this: 
> > <wsa:EndpointReference>
> >    <wsa:Address>
> >         http://www.example.com/services/someService
> >    </wsa:Address>
> >    <wsa:ReferenceProperties>
> >         <tns:resourceID>DataChunk42</tns:resourceID>
> >    </wsa:ReferenceProperties>
> >    <wsa:ReferenceParameters>
> >         <tns:expires>32000</tns:expires>
> >    </wsa:ReferenceParameters>
> > </wsa:EndpointReference>
> > Can we have it come back as this? 
> > <SOAP-ENV:Envelope>
> >      <SOAP-ENV:Header>
> >          <wsa:MessageID>msgid:1234567902282223</wsa:MessageID>
> >          <wsa:To>http://www.example.com/services/someService</wsa:To>
> >          <wsa:Action>http://www.example.com/someAction</wsa:Action>
> > 
> > <wsa:From>http://www.example.com/clients/someClient</wsa:From>
> > 
> <wsa:ReplyTo><wsa:Address>http://www.example.com/clients/someOtherClient
> </wsa:
> > Address></wsa:ReplyTo>
> > 
> <wsa:FaultTo><wsa:Address>http://www.example.com/clients/yetAnotherClien
> t</wsa:
> > Address></wsa:FaultTo>
> >          <tns:resourceID
> wsa:type="property">DataChunk42</tns:resourceID>
> >          <tns:expires wsa:type="parameter">32000</tns:expires>
> >      </SOAP-ENV:Header>
> >      <SOAP-ENV:Body>
> >         ...
> >      </SOAP-ENV:Body>
> > </SOAP-ENV:Envelope>
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> 
> 
>

Received on Wednesday, 24 November 2004 23:44:51 UTC