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

Martin,

Problem is my intermediary has neither control of X or of Y. All it does
is get the soap messages on the wire, look for refp's and store them for
later off line analysis. Period. And we need information in the soap
message that a soap header is present because it was part of an EPR and
whether it is a RefParameter or a RefProperty. As Mark put it, it is a
question of "self-description and visibility."

When Chris told me that we lose the ability to subject the soap headers
to the SOAP Processing model if we have a wrapper, I stopped right there
when I understood the problem. At this point, please give me such an
answer for why we can't mark the refp's using attributes (something
other than, it's not in the original spec / we'd have to change code in
.NET and Websphere)

Thanks,
dims

-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
Sent: Thursday, November 25, 2004 9:36 AM
To: Srinivas, Davanum M; Christopher B Ferris
Cc: public-ws-addressing@w3.org
Subject: 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 15:02:25 UTC