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

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 13:58:59 UTC