RE: Another way of thinking about EPRs

 

> -----Original Message-----
> From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk] 
> Sent: 10 December 2004 04:18
> To: Martin Gudgin; public-ws-addressing@w3.org
> Subject: RE: Another way of thinking about EPRs
> 
> Hey Gudge,
> 
> Yes, your examples make sense but here are three counterarguments to
> them:
> 
> 1. Message structure (and perhaps contents of some elements) can be
> described in a message description language. From WSDL and 
> WS-Policy we
> can infer the structure and contents of the messages we want to
> exchange. Are you suggesting that WS-Addressing should be yet another
> way of describing message format?

Well in a way, an EPR does describe (some of) the message format. It at
least describes the wsa:To, and possibly additional headers aswell
depending on whether it contains RefProps and/or RefParmas. I think the
difference between the headers that result from an EPR and the headers
that result from reading WSDL/Policy is that the sender probably has
some input into the content of the headers specified by WSDL/Policy. For
example, if I have a policy statement that says 'Use WS-Security' the
the client needs to be able to form a wsse:Security header per the WSS
spec. And it probably needs to generate signatures and put those in that
header, perhaps include a security token, etc. Some headers specified in
WSDL would have similar characteristics. But in the case of
RefProps/Params, they don't *need* to be understood by the client, that
is the client doesn't need to know how they are constructed or how they
are interpreted by the endpoint. 

> 
> According to your examples bellow, it was a requirement of 
> the receiving
> service to see those particular headers in a message. But the 
> receiving
> service may need to see more headers there as well (e.g. WS-Security,
> WS-Context, etc.). Should those be included in the EPR too?

I don't think so. I think I would specify stuff that the client needs
'smarts' to generate in WSDL/Policy. And the other stuff, which really
is nailed down by the endpoint I'd specify in the EPR. 

> 
> 2. Yes, I understand the arguments of not having to decrypt 
> the message
> body to get access to this information and to take advantage of
> infrastructure etc. However, the "GOLD/SILVER/PLATINUM" 
> example has been
> presented before and I don't understand its motivation. Is there a
> suggestion that just because someone included the
> <m:ServiceLevel>GOLD</m:ServiceLevel> header they will automatically
> receive that kind of service? Obviously some authentication 
> will have to
> take place (e.g. the message carries an appropriate security 
> token). An
> architect will design a system to determine whether GOLD 
> service will be
> provided to the requestor only after authentication. In such 
> a case, we
> don't really need the extra header. 
> 
> The only related use case I can think of is to have an EPR from which
> one could get access (using WS-MetadataExchange) to the 
> metadata of the
> PLATINUM service even though they are not allowed to use it (e.g. look
> what you can have if you subscribe to our PLATINUM service).

Perhaps the Gold/Silver/Bronze header is not a good example, I put it in
because I've heard other people mention it and I wanted two headers!
Maybe I should have just used m:Foo and m:Bar... 

> 
> 3. Finally, is it the case that you couple the TxId to a particular
> endpoint and you hide the transaction from the services that use that
> EPR (opaqueness of the EPR)? 

I'm not sure I understand the question. Let me take a stab;

A sends a CreateTransaction request message to B. B responds with an EPR
containing the TxID. That EPR can be used by other participants to
register with that transaction. A can then pass that EPR to anyone else
that A wants to join the transaction. 

Now, because it's an EPR, the actual format of the TxId doesn't need to
be contrained. B can define the TxId any way it likes. And if there is
another node C that also supports CreateTransaction, it would also use
EPRs and it can define a completely different structure for the TxId; it
might choose to use multiple RefProps/Params for example.

> What if the transaction spanned multiple
> endpoints? Would you have to issue multiple EPRs with different TxIDs?

I think I'd probably issue multiple EPRs with the same TxID ( but
perhaps different wsa:Address ). That said, I could see a bunch of
different ways of configuring a transaction system, including using
different TxIds and having the TM track which ones are assigned to which
actual transaction ( but I think we're getting off track ).

Gudge

> 
> Best regards,
> --
> Savas Parastatidis
> http://savas.parastatidis.name
>  
> 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-
> > request@w3.org] On Behalf Of Martin Gudgin
> > Sent: 09 December 2004 23:47
> > 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 16:53:23 UTC