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:31:16 UTC