RE: Another way of thinking about EPRs

<snip />

> So, you are saying that we should have something like this?
> <wsa:EndpointReference>
>  <wsa:Address></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
> 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 :-) -->

  <xsd:element name="header1">
        <xsd:element name="ServiceLevel" fixed="GOLD" />
        <xsd:element name="TxId" fixed="1234" />
  <xsd:element name="body1">

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

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
> 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. 


Received on Saturday, 11 December 2004 06:56:02 UTC