RE: Another way of thinking about EPRs

 

> -----Original Message-----
> From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk] 
> Sent: 10 December 2004 11:56
> To: Martin Gudgin; public-ws-addressing@w3.org
> Subject: RE: Another way of thinking about EPRs
> 
> <snip />
<Snip/>
> 
> Cool. Yes, I understand the difference. However, wouldn't 
> something like
> this
> 
>    <xs:element>
>       <xs:complexType>
>          <xs:sequence>
>             <xs:element name="serviceLevel" fixed="GOLD" />
>          </xs:sequence>
>       </xs:complexType>
>    </xs:element>
> 
> in an appropriate message description language be sufficient? 
> Since the
> value of the element is fixed and it's included in the description of
> the message, there is no need for the message sender to understand its
> semantics. It's just required. That way the metadata about the message
> exchange (i.e. the description of the message format) is left to the
> appropriate metadata description languages.

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?


> 
> 
> <snip />
> 
> > 
> > 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...
> > 
> 
> Foo and Bar are always our friends :-)

;-)

<snip/>
> 
> A! ok. I understand now. I don't think that the above description came
> out of your previous example. 
> Here you are using an EPR as a way to
> reference a particular transaction. Your previous example 
> suggested that
> the TxID was passed as part of an interaction with a 
> particular service,
> other than the Transaction Manager.

Sorry I wasn't clear.

<SNIP/>
> 
> I agree that this may be getting off track but at the same time we are
> also homing in on how EPRs will probably be used in the future. I
> personally see a transaction as an entity that is named rather than
> having its own address; the difference between talking to the
> Transaction Manager _about_ the transaction and talking to the
> transaction directly. I personally prefer a world where each entity is
> named (e.g. it has a URN) but not referenced/addressed in a technology
> specific manner (e.g. through an EPR, a CORBA IOR, a URL). 

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

Cheers

Gudge

Received on Saturday, 11 December 2004 03:38:44 UTC