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

Dims,

I don't understand that scenario. A given endpoint X expects certain
SOAP headers to be in a message. Some of those are specified in
WSDL/policy/whatever. Others are specified in an EPR issued by Y (your
'partner'). But X still needs the software to process those headers. Now
X could be coded to 'know' that a given header was present in a message
because it's a ref prop, or not. X's choice (not Y's). If Y specifies a
reference property that X doesn't understand/recognise then that header
won't get processed... Not much X can do about that...

Gudge

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Srinivas, Davanum M
> Sent: 25 November 2004 14:31
> To: Christopher B Ferris
> Cc: public-ws-addressing@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> 
> Chris,
> 
> Slight variation, If my partner is creating the original EPR and
> specifies my endpoint as ReplyTo, I will get the soap headers and I
> don't know which ones are because my partner specified it in the EPR. 
> 
> -- dims
> 
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Thursday, November 25, 2004 9:24 AM
> To: Srinivas, Davanum M
> Cc: public-ws-addressing@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> Dims,
> 
> Ah, correlate you say... that means that you must have the 
> EPR to begin
> with.
> Slurp out all EPRs (e.g. wsa:ReplyTo). The EPR contains ref
> props/params... you know which is which from the EPR. On messages
> travelling in the reverse direction, scan the SOAP Header for header
> blocks matching the ref props/params in the EPR. 
> 
> Of course, for correlation, you also have
> wsa:RelatesTo/[@RelationshipType="wsa:Reply"]/@text
> and wsa:MessageId and you can match the wsa:ReplyTo EPR ref 
> props/params
> with the SOAP header blocks in the reply message:-)
> 
> Of course, had any of the ref props/params been targetted at any node
> other than the ultimate recipient, some of the SOAP header blocks may
> already have been processed in the SOAP sense and removed from the
> message depending on where you placed your STEM (scanning, tunnelling
> electron microscope) intermediary.
> 
> 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/25/2004
> 08:58:57 AM:
> 
> > Chris,
> > 
> > Simple. The ONLY reason a refp is in the soap message is on 
> the wire 
> > is BECAUSE someone generated an EPR with that refp inside 
> it. I'd like
> 
> > to correlate this connection. Right now looking at the soap 
> message, I
> 
> > cannot figure out which soap headers are added explicitly and which 
> > ones are present because they were part of an EPR wihtout having an 
> > offline mechanism to input (or keep track of) which endpoints are 
> > spewing which refp in their EPR's.
> > 
> > -- dims
> > 
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Thursday, November 25, 2004 6:37 AM
> > To: Srinivas, Davanum M
> > Cc: public-ws-addressing@w3.org
> > Subject: RE: Using attributes to mark RefProp's and RefParam's
> > 
> > Dims,
> > 
> > It isn't outlandish, but couldn't you accomplish this by simply 
> > harvesting all SOAP header blocks that were not well-known WS-* 
> > protocol headers and achieve the same thing?
> > Again, what I fail to
> > understand is why it is important to know that they are/were ref 
> > props/params?
> > 
> > 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
> > 09:57:58 PM:
> > 
> > > Chris,
> > > 
> > > Suppose you have a vibrant eco system and web services 
> keep popping 
> > > up
> > 
> > > every now and then. You want something in place to collect 
> > > information
> > 
> > > and here we are collecting all refp's. AFTER say a year or two we 
> > > want
> > 
> > > to run analysis on what's happening in the system. Which query we 
> > > want
> > 
> > > answer for is NOT known before hand. All we know is that all the 
> > > refp's are potential targets for mining usage 
> information. Is this 
> > > so out-landish scenario?
> > > 
> > > -- dims
> > > 
> > > -----Original Message-----
> > > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > > Sent: Wednesday, November 24, 2004 9:43 PM
> > > To: Srinivas, Davanum M
> > > Cc: public-ws-addressing@w3.org
> > > Subject: RE: Using attributes to mark RefProp's and RefParam's
> > > 
> > > Dims,
> > > 
> > > If you want to know how many "gold" members, then clearly 
> you have 
> > > some knowledge that there is a specific header with 
> "gold" semantics
> 
> > > and you simply scan the message for that particular header.
> > > Why need it be identified as being a ref prop/param?
> > > 
> > > 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>
> > > 11/24/2004 09:15 PM
> > > 
> > > To
> > > Christopher B Ferris/Waltham/IBM@IBMUS cc 
> > > <public-ws-addressing@w3.org> Subject
> > > RE: Using attributes to mark RefProp's and RefParam's
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > That was just an example off the top of my head. How about 
> > > collecting management information of all the refp's 
> flowing in the 
> > > system for analysis? (How many "gold" members accessed 
> which service
> 
> > > and how many times). In this scenario, we should not have 
> to type in
> 
> > > all the qnames of all possible refp's in advance.
> > > 
> > > -- dims
> > > 
> > > -----Original Message-----
> > > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > > Sent: Wednesday, November 24, 2004 9:06 PM
> > > To: Srinivas, Davanum M
> > > Cc: public-ws-addressing@w3.org
> > > Subject: RE: Using attributes to mark RefProp's and RefParam's
> > > 
> > > Dims,
> > > 
> > > Can you give me an example of a SOAP header that you 
> would not sign?
> > The
> > > security considerations section recommends signing all relevant
> > headers.
> > > 
> > > 
> > > Keep in mind that any header not signed is subject to 
> tampering. Any
> 
> > > message that travels through an intermediary is subject to header 
> > > insertion (and deletion) attacks.
> > > Hence, a service that receives
> > > messages should be highly suspect of any headers, regardless of 
> > > type, that are not signed. It may even implement a policy that 
> > > precludes processing of any header that is not signed by a trusted
> source (e.g.
> > > the sender (which has presumably been authenticated and 
> authorized) 
> > > and/or a trusted intermediary).
> > > 
> > > 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> Sent by:
> > > public-ws-addressing-request@w3.org
> > > 11/24/2004 07:52 PM
> > > 
> > > To
> > > Christopher B Ferris/Waltham/IBM@IBMUS cc 
> > > <public-ws-addressing@w3.org>, 
> <public-ws-addressing-request@w3.org>
> > > Subject
> > > RE: Using attributes to mark RefProp's and RefParam's
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Ok. Then here's one scenario. I'd like my security 
> > > proxy/intermediary
> > to
> > > check if all ReferenceParameters are signed and throw 
> faults for the
> 
> > > rest and I don't want to keep adding new Qnames for every service 
> > > that gets added to the system.
> > > 
> > > -- dims
> > > 
> > > -----Original Message-----
> > > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > > Sent: Wednesday, November 24, 2004 6:45 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
> > > 
> > > 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/someOtherClie
> > > > nt
> > > > </wsa:
> > > > > Address></wsa:ReplyTo>
> > > > > 
> > > >
> > 
> <wsa:FaultTo><wsa:Address>http://www.example.com/clients/yetAnotherCli
> > > > en
> > > > 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 Thursday, 25 November 2004 14:35:38 UTC