[Nsi-wg] Issue 55 in ogf-nsi-project: correlationId is unneeded and complicates implementation significantly

[ogf-nsi-project at googlecode.com]

Status: Accepted
Owner: ----
Labels: Type-Review Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1

New issue 55 by thost... at gmail.com: correlationId is unneeded and  
complicates implementation significantly
http://code.google.com/p/ogf-nsi-project/issues/detail?id=55

Description of Issue:

The correlationId attribute in the WSDL messages is unneeded. Furthermore  
it requires correct implementations to persistently keep track of the  
correlationsIds of active requests.

Discussion of Issue:

The WSDL adds a correlationId to track the correspondence between a request  
and the subsequent update for the status. However this correspondence is  
unneeded as the request already contains information about the connection  
in question.

However having the correlationId requires both the requester and provider  
to keep a persistent (as in on-disk) record of currently active requests,  
in order to be crash and restart safe, i.e., the service must be able to  
respond to requests that came before it crashed/restarted. The  
correlationId also means that state updates are not idempotent as the  
client can only receive a request (state update) once. However it cannot be  
guaranties that a message with a state update will only be send once due to  
the coordination of message dispatching and updating this information  
persistently, where there will always be a window which can lead to  
inconsistency, where the message must be retransmitted.

Having to keep track of requests in this way, is called a state-full  
protocol (note that this does not mean a non state-full protocol doesn't  
have any state), and is usually considered a bad idea do implementation  
complexity and poor scalability in high-performance systems (arguably this  
is not what we have though), as it makes load balancing and redundancy  
significantly more tricky.

Furthermore it must be remembered that not all requests will have a  
callback. E.g., a provision before start time (i.e., auto-provision)  
followed by subsequent terminate request, will result in a callback for  
terminate, but not for the provision request. Here the client must then  
clear all pending correlationIds, complicating the implementation (the  
client side issues are simple though).

All this is further complicated by the fact that we haven't established if  
it is the provider or requester which is responsible for ensuring that  
correct connection state is updated.


Resolution of Issue:

Remove correlationId from the WSDL. This will make the state update  
messages (reserveConfirmed, etc.) idempotent, meaning they can be repeated.  
The requester will then update any state references about the remote  
connection to fit with the last received message (this also has problems,  
but none that doesn't exist in the current protocol).