[Nsi-wg] Feedback for WS protocol
Henrik Thostrup Jensen
htj at nordu.net
Wed Jul 13 06:16:39 CDT 2011
Hi everyone
(I'm the NORDUnet developer creating the OpenNSA NSI implementation).
(Also, please ignore a potential double post due to wrong sender email)
I have some feedback/changes/wishes/questions for the WS-rendering of the
NSI protocol.
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)
A -> B: reserveRequest
A <- B: reserveResponse
A <- B: reserveConfirmed
A -> B: reserveConfirmedResponse
This means that 4 messages are exchanged, when 2 would be enough. This is
silly in my opinon, and only adds complexity to the implementation without
adding any value. Also, at some point in time the reserveResponse and
reserveConfirmed will get reordered as they don't have any ordering
between them, meaning the requester will have to understand that case. It
also seems to against the spec, which defines the primitives
reserveRequest, reserveConfirmed, and reserveFailed.
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.
Also: Rename pathObject to path everywhere. We do not put the object
suffix on other things either.
Also(2): Rename OrderedStpListType to StpListType in spec. and protocol. A
list is by definition ordered, otherwise it would be called a multiset or
bag.
3. Protocol service parameters differ spec service parameters
In the spec. schedule is in service parameters, in the WS protocol it is
in the ReservationRequestType. I don't have any strong opions on where it
should be, but I think it should be consistent.
Somewhat similarly the spec. has guarenteed and preferred under
serviceAttrs (which is under ServiceParameters). In the WS protocol
guaranteed and preferred are directly under ServiceParameters. Again I
don't have any strong opions on what is correct, but I think it should be
consistent.
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).
5. Inconsistent path description
The spec. introduces the notion of a service demarcation point as a pair
of connected STPs. Could we introduce this type (essentially a
tuple/struct/complextype with two STPs), and use it for describing paths,
such that a path is a (sourceSTP, destSTP, SDPList).
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org>
NORDUnet / Nordic Data Grid Facility.
More information about the nsi-wg
mailing list