RE: Another way of thinking about EPRs

<snip />

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

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.


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

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

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.

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

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). Only services
are addressed. But that's just me and as you say this may not be
directly related to the discussion.

Best regards,
.savas.

Received on Friday, 10 December 2004 19:56:02 UTC