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

RE: Another way of thinking about EPRs

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Fri, 10 Dec 2004 09:02:08 -0500
To: "Srinivas, Davanum M" <Davanum.Srinivas@ca.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF061FBED8.73CC5E5D-ON85256F66.004A1473-85256F66.004D199B@us.ibm.com>

Dims,

You wrote:
>Section 2.4 of submission[1] talks about
> comparing 2 EPR's. If I have to write a completely transparent BPEL or
> WS-Choreography monitoring solution, I need to be able to look at the
> wire and be able to figure out who is talking to who and keep track of
> interactions between entities in the system. *IF* from the soap message
> on the wire I can figure out the "who" portion..then I am all set.

Again, I must ask; why aren't <wsa:To/> and <wsa:From/> sufficient to 
achieve this objective? 

I could be using the refps for applying the implied resource pattern 
(WS-RF), but that is not a required
application of refps. Does your monitoring of SOAP traffic have intimate 
knowledge about
PONumber embedded in the soap:Body? I doubt it would be even remotely 
practical as it would
require domain knowledge of all application-domains on the part of the 
monitoring software.
Yet, a soap:Body//PONumber identifies a resource relevant to the service 
just as a refp
might do.

Bottom line, what is the "who" you think you are tracking? The resource(s) 
behind a service endpoint
or the service itself? If the former, then frankly, unless refps are used 
exclusively for application
of the WS-RF implied resource pattern, you are probably making a false 
assumption.

If you are tracking for purposes of matching requests with responses, then 
you have wsa:MessageId
and wsa:RelatesTo. The address becomes immaterial. 

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 12/09/2004 10:13:24 PM:

> 
> Martin, All,
> 
> Yes, I get it...Here's a variation of the argument I have been making
> for i008 (not sure about i001). Section 2.4 of submission[1] talks about
> comparing 2 EPR's. If I have to write a completely transparent BPEL or
> WS-Choreography monitoring solution, I need to be able to look at the
> wire and be able to figure out who is talking to who and keep track of
> interactions between entities in the system. *IF* from the soap message
> on the wire I can figure out the "who" portion..then I am all set.
> According to 2.4, I can use the combination of [address] and [reference
> properties] to figure out A is sending the message to B. BUT if I don't
> have access to the EPR's themselves or list of all the Qname's that are
> definitely reference properties, I cannot find out the "who". IF there
> is some "annotation" (word used by Jonathan on IRC) on the soap message
> on the wire then I can do this VERY easily.
> 
> So the basic question is - Is there consensus on whether we need some
> "annotation"? (could be wrappers, could be attributes, could be
> something else entirely). 
> 
> [1] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Martin Gudgin
> Sent: Thursday, December 09, 2004 6:47 PM
> To: public-ws-addressing@w3.org
> Subject: Another way of thinking about EPRs
> 
> 
> I've noticed that whenever we talk about issues i001 and i008, that
> there is an implicit assumption that we start with an EPR and go from
> that to the message. I think that in many cases, the reverse is actually
> true, that is, people start with SOAP messages with headers in and then
> decide how to communicate to a potential sender what those messages
> should look like ( WRT the headers ).
> 
> For example, I want to have people send me messages that look like the
> three below. 
> 
> <soap:Envelope>
>  <soap:Header>
>    <wsa:To>http://example.org/weather</wsa:To>
>    <m:ServiceLevel>Gold</m:ServiceLevel>
>    <m:TxId>1234</m:TxId>
>  </soap:Header>
>  <soap:Body>
>  . . .
>  </soap:Body>
> </soap:Envelope>
> 
> <soap:Envelope>
>  <soap:Header>
>    <wsa:To>http://example.org/weather</wsa:To>
>    <m:ServiceLevel>Silver</m:ServiceLevel>
>    <m:TxId>1234</m:TxId>
>  </soap:Header>
>  <soap:Body>
>  . . .
>  </soap:Body>
> </soap:Envelope>
> 
> <soap:Envelope>
>  <soap:Header>
>    <wsa:To>http://example.org/weather</wsa:To>
>    <m:ServiceLevel>Gold</m:ServiceLevel>
>    <m:TxId>4567</m:TxId>
>  </soap:Header>
>  <soap:Body>
>  . . .
>  </soap:Body>
> </soap:Envelope>
> 
> How can I communicate to my users that I want the messages to look like
> this? Ah, I know, I'll send them an EPR. Here are the three EPRs for the
> messages above ( my seperation between Props/Params is arbitrary ).
> 
> <wsa:EndpointReference>
>  <wsa:Address>http://example.org/weather</wsa:Address>
>  <wsa:ReferenceProperties>
>   <m:ServiceLevel>Gold</m:ServiceLevel>
>  </wsa:ReferenceProperties>
>  <wsa:ReferenceParameters>
>   <m:ServiceLevel>1234</m:ServiceLevel>
>  </wsa:ReferenceParameters>
> </wsa:EndpointReference>
> 
> <wsa:EndpointReference>
>  <wsa:Address>http://example.org/weather</wsa:Address>
>  <wsa:ReferenceProperties>
>   <m:ServiceLevel>Silver</m:ServiceLevel>
>  </wsa:ReferenceProperties>
>  <wsa:ReferenceParameters>
>   <m:ServiceLevel>1234</m:ServiceLevel>
>  </wsa:ReferenceParameters>
> </wsa:EndpointReference>
> 
> <wsa:EndpointReference>
>  <wsa:Address>http://example.org/weather</wsa:Address>
>  <wsa:ReferenceProperties>
>   <m:ServiceLevel>Gold</m:ServiceLevel>
>  </wsa:ReferenceProperties>
>  <wsa:ReferenceParameters>
>   <m:ServiceLevel>4567</m:ServiceLevel>
>  </wsa:ReferenceParameters>
> </wsa:EndpointReference>
> 
> Does this make any sense?
> 
> Gudge
> 
> 
> 
> 
Received on Friday, 10 December 2004 14:02:42 GMT

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