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:24:43 UTC