[Nsi-wg] Feedback for WS protocol

[Henrik Thostrup Jensen]

Hi again

On Wed, 13 Jul 2011, John MacAuley wrote:

> Responses in-line.
> One note - keep a clear mental separation of the XSD and the WSDL.  The XSD represents the generic modelling of
> the NSI protocol independent of transport.  The WSDL attempts to provide an instance of reliable transport for
> implementation prototyping.

Ack.

> On 2011-07-13, at 7:16 AM, Henrik Thostrup Jensen wrote:
>
>       1. Odd request/reply structure.
>
>       The request/reply structure is somewhat odd. It seems that for every
>       request there is an message to imply that the message itself has been
>       received as well as the actual response, which also has a response. I.e.,
>       the interaction will look like this for a reservation (AFAICT)
>
> You are correct.  Four messages will be exchanged per request/confirmed/failed interaction, however, these are
> only two operations from an XSD perspective.  Remember to separate the NSI operations from the WSDL transport.
>  The reservationRequest is carried across in a SOAP POST operation, it gets accepted on the remote NSA, and the
> remote NSA returns either reservationResponse or SOAP fault in the POST result.  We need this reservationResponse
> to acknowledge the remote NSA has received the reservationRequest otherwise we will keep trying to send.
> 
> This request/acknowledgement model was needed to address the requirement that many of the NSI operation are long
> duration, taking seconds to minutes, to days for the confirm/failed response to return.  For any reasonable error
> handling to be achieved we needed to introduce an acknowledgement of some type.  The GenericResponseType message
> returned as the acknowledgement is an empty sequence, but at least provides a positive indication that the
> request was received (hmmm... I had transactionId in there at one point - I might put it back in).
> 
> Can I get a confirm back before the the ack for the request?  Yes you could depending on the remote NSA design
> but this is not an issue since the transactionId models the request/confirm/failed interaction, so I can easily
> handle this in software logic.
> 
> If I had been doing the NSI protocol from scratch as an web service it would be quite different.  Doing the
> generic abstract protocol first is always tough for implementation given you end up with the worse of both worlds
> :-)

OK, with the seperation in time it makes a lot more sense.

Still, the underlying SOAP transport (HTTP/TCP or SMTP, and I'm not sure 
we even have to consider the last) will take care of delivering the 
message, and if an ack isn't received you will get an error message 
(losing the connection for HTTP, getting a delivery error for SMTP). 
Unless we are planning to use SOAP over UDP it really isn't needed.

>       2. Moving pathObject out of ServiceParameters
>
>       I would very much like to move pathObject out of serviceParameters and
>       into the top-level attributes. As a reservation is created the pathObject
>       send around changes, where as the rest of the ServiceParameters does not.
>       This also reflects itself in data structures where this becomes somewhat
>       backwards to keep track of the path in aggregate connections. It is of
>       course completely possible to keep the current structure, but it would
>       simplify the implementation to move the path out of the service
>       parameters.
> 
> We placed the path object into the service parameters is part of the specific service attributes used to guide
> the service request, and therefore, seemed relevant with other service specific attributes.  I don't specifically
> understand your concerns with respect to implementation, but you are probably further along than I am.  I think
> we will need to get additional input from the team.

Hmm.. it really depends a lot on how one couples the information. So far 
I've seen serviceParameters as parameters for finding a path given a 
source and dest. However one can also see the serviceParamemters and path 
as the parameters for making a connection.

Consider that the path and reminder of the serviceParameters are 
orthogonal in the sense that it is possible to make multiple connections 
using the same serviceParameters. In fact this is typically the case in 
the implementation where a path is split up into smaller paths, which are 
then reserved. Not having the two spliced together makes this operation 
simpler.

Also could some one come up with a use case for guaranteed and preferred, 
I can't quite see the rationale for them.

>       4. The transactionId
>
>       The transactionId is not mentioned in the spec., but is used to denote
>       session due to SOAPs lack of it. Could we call it something less
>       misleading? It has nothing to do with transactions. E.g., sessionId,
>       requestId (i prefer the latter as a session could technically consist of
>       several requests).
> 
> 
> The transactionId is for an NSA to correlate a request to a confirm/failed.  If you get a confirm or failed back
> before the ack to the request then you can still correlated it based in transactionId.  The transactionId does
> not represent a session.  Only a single message exchange between a pair of NSA.  I have baounce

baounce?

I get what it is used for, and yes it isn't a session, but it certainly 
isn't a transaction either (NSI is not a transactional protocol and 
doesn't introduce the concept of a transaction). I suggest requestId :-).


     Best regards, Henrik

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