W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

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

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Thu, 25 Nov 2004 03:37:46 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B63380413FEDE@RED-MSG-43.redmond.corp.microsoft.com>
To: "Srinivas, Davanum M" <Davanum.Srinivas@ca.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>
Cc: <public-ws-addressing@w3.org>

If you don't know what query you want to run in advance, wouldn't it be
more useful just to log *all* the headers? Or perhaps even each entire
message? That way I could even ask questions like 'how many messages
used the anonymous wsa:ReplyTo?' or 'how many messages used WSS?'

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 02:58
> To: Christopher B Ferris
> Cc: public-ws-addressing@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> 
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:00 GMT