FW: RE: [ws-caf] Questions on WS-CAF

["Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>]

For the benefits of the members of the list, here's Andy's reply to
Mark's message.

> 
> >===== Original Message From Mark Little <Mark.Little@arjuna.com>
=====
> >> > 1) If the context is changed via the setContents operation of the
> >> Context
> >> > Manager Port and the identifying URI is changed, how should the
reply
> >> > message
> >> > be formatted? Should this be relying on the correlation-id to
> >> associate
> >> > the
> >> > reply with the request, or should the original context URI be
sent in
> >> the
> >> > SOAP
> >> > header to indicate that it is part of the same operation?
> >
> >If by identifying URI you mean the value of context-identifier then
at
> the
> >moment there's been the implicit assumption that this doesn't change
once
> >created. This goes for whether the context is passed by reference or
by
> >value.
> >
> 
> This is good news for me, as being able to change the
context-identifier
> creates a lot of problems. I will assume that the context-identifier
is
> unchangeable, and any requests trying to modify it will return a
fault.
> 
> 
> >> > 2) For all operations with the context service itself, should
replies
> >> rely
> >> > solely on the correlation id to associate a reply with a
response, or
> >> > should
> >> > they use a combination of this and the context identifier?
> >> >
> >
> >Can you give an example of the specific interactions you mean?
> >
> 
> Consumer X sends a request to to WS-CTX service updating the value of
the
> context. It places the abbreviated context information in the SOAP
header
> in
> this request. The receiving WS-CTX service executes the request and
forms
> the
> reply messages to be sent to the respondants... At this point what
> information
> should go into this response to identify it as the response to this
> specific
> request? For example if a consumer is sending out several operations
to
> the
> context service and receiving replies on the appropriate respondant
port
> how
> should the replies be associated with the correct original request?
> 
> Should the respondant rely on the correlation-id as a unique value
> associating
> the request and response? Should the context information be placed in
the
> SOAP
> header of the request alongside the correlation-id? Should the sender
> address
> of the the response be the same as the address to which the request
was
> sent?
> 
> At the moment I am using just the correlation-id and I am also passing
the
> same context information in the SOAP header of the reply. I cannot see
any
> problems with this way of doing it, but I would like to know how the
> specification itended this to be done.
> 
> Further more, the Assertion type that is received by the context
specifies
> a
> sender-address and recipient-address(es). To where should the reply be
> from
> the WS-CTX service be sent?
> 
> Should it be sent to each of the addresses in the recipient-address,
> assuming
> these are all pointing to the correct respondant port? Or should the
reply
> address be created from the sender?
> 
> I have assumed that that the reply is sent to all addresses in the
> recipient-address, but it has occured to me that this could also be
used
> to
> identify where the request was sent, and I would also like to clarify
how
> the
> specification intended these elements to be used. Sorry if this seems
like
> a
> very basic question, but I could not determine this from the current
> specification document.
> 
> >> > 3) What should the sender address be set to in replies? i.e.
should
> >> this
> >> > point
> >> > to the address that was called, or expanded to give details of
the
> >> > operation
> >> > that is actually being called etc?
> >
> >This is up to the specific implementation, but I don't see why it
would
> >include details of the operation being called (that's receiver
specific
> if
> >anything).
> >
> 
> This is ok, I will try to use an appropriate way to implement it.
> 
> >> >
> >> > 4) for the details in the Fault types that are returned, are
there
> any
> >> > restrictions on what should be placed within the originator and
error
> >> code
> >> > elements or is this entirely implementation specific?
> >
> >Currently it's implementation specific at the level of WS-Context.
> Utilising
> >specifications, like WS-CF and WS-TXM may define specific fault types
> with
> >definite values.
> >
> >Mark.
> >
> >----
> >Mark Little,
> >Chief Architect, Transactions,
> >Arjuna Technologies Ltd.
> >
> >www.arjuna.com
> 
> 
> Thank you again for this clarification.
> 
> Andy
>