[Nsi-wg] TransactionId

[Henrik Thostrup Jensen]

Hi

On Tue, 19 Jul 2011, John MacAuley wrote:

> This weekend we had a lively discussion on transactionId.  In the end itwas agreed that we would continue
> to support this identifier, however it will be renamed.  I have currently defined it as a uuid for
> uniqueness as is done in many implementations using a transactionId.

I'm going to chip in a bit here.

I think a big source of the confusion (and also for the failed messages) 
is that the protocol has switched from RPC to message based, and is now 
being wrapped into an RPC protocol (WSDL/SOAP). I think this is giving us 
the worst of both worlds and is needlessy complicated.

If we choose a message-based protocol, there shouldn't be any direct 
responses to requests as such. Instead the requester would receive 
messages when the state is updated at the provider, e.g.:

R -> Reserve -> P
P -> Status  -> R (switched from INITIAL to RESERVING)
P -> Status  -> R (switched from RESERVING to RESERVED)

That way there would only be one message type from provider to requester 
(StateUpdate), and there is no need for a request/correlation id, only 
connection id. Messages can also be duplicated without any risk if the 
protocol is designed properly.

If we go with an RPC based model it would look like this:

R reserves at P
R blocks until P answers created or failed.

As it can take some time for a reservation to complete this is also an 
option:

R reserves at P
P answers to R that the reservation request has been received
R polls P in regular intervals for state updates.

Note that since we have an RPC design, only the requester initiates a 
session. As RPC is session based per definition, there is not an actual 
need for a session/correlation id at NSA level, though it might be the 
case for the protocol (many protocols do this in order to make multiple 
requests per connection, but thats a detail).

What we have now is a very odd design with RPCs going in both directions, 
which is odd to say at least.

The current design is a bit wrt. to failure handling, e.g. what happens if 
a reserveConfirmed message/request is not delivered (if the requesting NSA 
is unavailable for some reason). This can probably addresses using query, 
but it is not specified in the protocol what should happen.

> Now Inder asked if we could make it a sequence I'd to help with processing on the RA side.  Comments?

I'm glad you decided not to on this one. Sequences usually end up having 
to deal with holes by introducing hold-back queues and bending over 
backwards to avoid duplicates etc. (and if holes or duplicats are okay, 
one should not have used sequences anyway).


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at ndgf.org>
  NORDUnet / Nordic Data Grid Facility.