- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Thu, 25 Nov 2004 03:37:46 -0800
- 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 UTC