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 11:37:54 UTC