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

RE: Another way of thinking about EPRs

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Sat, 11 Dec 2004 06:55:48 -0000
Message-ID: <37E80E80B681A24B8F768D607373CA800197A838@largo.campus.ncl.ac.uk>
To: "Martin Gudgin" <mgudgin@microsoft.com>, <public-ws-addressing@w3.org>

<snip />

> 
> So, you are saying that we should have something like this?
> 
> <wsa:EndpointReference>
>  <wsa:Address>http://example.org/service</wsa:Address>
>  <wsa:ReferenceProperties>
>    <xs:element>
>     <xs:complexType>
>       <xs:sequence>
>        <xs:element name="serviceLevel" fixed="GOLD" />
>       </xs:sequence>
>      </xs:complexType>
>    </xs:element>
>  </wsa:ReferenceProperties>
> </wsa:EndpointReference>
> 
> There are some issues with the above, right? For example, what
namespace
> is the serviceLevel element in?
> 
> 

Ooops. Sorry, I wasn't clear. I was suggesting that the <xs:element>
with the fixed value could have been part of a metadata document like
WSDL and not part of the RefProperties. Describing parts of a message
using something like the schema above still achieves the same
requirement of asking the message-senders to include a fixed-value
header in the message. Sorry I wasn't clear.

<!-- Caution: I am assuming a pseudo Web Services Contract Language
bellow that easily supports header description... unlike another one we
know :-) -->

<wscl:types>
  <xsd:element name="header1">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="ServiceLevel" fixed="GOLD" />
        <xsd:element name="TxId" fixed="1234" />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="body1">
    ...
  </xsd:element>
</wscl:types>

<wscl:messages>
  <wscl:message name="message1">
    <wscl:header ref="tns:header1" />
    <wscl:header ref="..." />
    <wscl:body ref="tns:body1" />
  </wscl:message>
</wscl:message>


I think you get the idea. The structure of the message is left to the
metadata (please ignore the fact that I had to devise a metadata
language in order to simply illustrate my point). There is now a clear
separation of how the structure of a message is described and how the
receiving endpoint is addressed.

<snip /> 

> I think the EPR design supports both the way you describe above ( just
> use wsa:Address ) and also the examples I've noted ( wsa:Address +
> RefProps/Params ). And I think that the fact that it supports both is
a
> good thing.
> 
> > Only services
> > are addressed. But that's just me and as you say this may not be
> > directly related to the discussion.
> 
> I think of a service as something I can send messages to. But I think
> it's OK for that service to pass out many different EPRs ( as in the
> transaction manager case, where each EPR contains a different
> transaction id ).

Yup, I can see where you are coming from. Thanks! I am just worried
about the possible ways this can be abused and how EPRs can become the
"object pointers" that were never meant to be :-) But ce la vie. 

Regards,
.savas.
Received on Saturday, 11 December 2004 06:56:02 GMT

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