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

Gudge,

Yes, There are other ways of implementing things. But right now as it
stands WS-A's lack of a way to mark refp's will make me do things the
hard way. I feel a bit like Don Quixote. If I come up with other
scenario's, am sure you or chris or others will find alternative ways to
doing things or find problems with the scenario itself. My point is we
are not sure all the ways in which people are going to use WS-A. I know
I am facing a problem between doing things the hard way and the easy
way. Am sure others will face the same or similar problems in the
future. 

So my question is What would you guys want from me or Rich or Glen that
would make you change your mind? A Bullet-Proof scenario? 

Thanks,
dims

-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
Sent: Thursday, November 25, 2004 6:38 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

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 13:53:27 UTC