[Nsi-wg] Overly complex discovery WSDL

[Henrik Thostrup Jensen]

Hi

(sorry for the long email)

On Tue, 27 Nov 2012, John MacAuley wrote:

> I understand the comments on the query.  i was conflicted as well.  I am 
> also wondering if I meant AND :-)

I think this is ultimately a question on how people relate to risk. The 
argument for the current is that we will not have to change it later. OTOH 
there is the risk that we will have to maintain something complex over a 
long time, and that we will have to changes down the line no matter what 
(this is more how I see things).

Right now, I see the biggest risk for NSI that we are not delivering and 
keep changing & adding things. If we have more demos we might start boring 
people to death. We will never figure out how this thing should look like 
until we had in production for some years. But this is how I see things 
and relate to risks, which is certainly different from the way other 
people see it.

> The original Discovery response was the ServicesType structure, but 
> based on the Chicago OGF/GLIF feedback I wrapped it with the 
> NsaDiscoveryType to remove the need for the header.  Other than this 
> minor change it is the exact same as discussed in the last three or four 
> OGF.

Aye, I just never had a look at it.

> Now with this said, let us focus on the "9 levels deep" comment.  This 
> is probably the result of my specific XSD style.  I like to wrap any 
> multi-valued elements in a list type for containment.  For example, the 
> ServicesType wrapping the ServiceType, and the VersionsType wrapping the 
> VersionType.  Removing this containment can reduce the nesting by a few 
> levels without any loss of data structure.  However, this is the pattern 
> I followed in the NSI-CS so I also followed it here.

I'm okay with that pattern. One thing I stumbled over was the heavy usage 
of attributes, but I could never figure out when to use elements and 
attributes in XML anyway.

Now, things that stand out to me:

The requestType and filtering seems completely overkill. Most services 
will only host 2 (CS and topology), perhaps 3 or 4 services. Maintaining 
multiple protocols stacks is tricky and will probably only be done for 
transitioning. This way of designing interfaces to be pretty popular 10 
years ago, but these days things are typically modelled with complete, or 
most recent lists. I.e. less generic and more tailored to actual usage (I 
can dig up some articles on this if someone are interested).

Given the low number of services modelling versions explicit seems 
overkill. Sure, there might be multiple ConnectionServices, but I can live 
with having NSI1SOAP and NSI2SOAP services types (or whatever we'll call 
them).

The way capabilities are modelled also seems like overkill to me. They are 
binary, i.e., either they are there are not. Having looked at your slides 
I realize that you actually model it like that, but in slightly more 
complex way than I would. I'd probably do something like:

<capabilities>
     <capability>release</capability>
     <capability>modify</capability>
<capability>

We might have QNames here. Or require it for 3rd party extensions. Not 
overly important.

I honestly don't know if we need the capability stuff, but I am okay with 
it being there. It does seem broken to me though, as it typically won't be 
either or for these things. How do I represent that I can only do time 
extensions in modify, but not change the bandwidth. Or how do I specify 
that I can only increase link capacity, and not decrease it. Or that I 
cannot modify it beyond a limit? Or that I can only do modify on some 
ports, and not others. The capabilities stuff just strikes me as a bit 
naive, as the only way you can figure out of something can be done, is to 
fire off the action and see what happens.

Similarly the ##other attributes strikes me as wrong, but I can for all 
purposes just ignore them for now. But if we keep the ##other attributes, 
we might as well make the base thing simple.

I know that currently we support multiple providers at a single endpoint. 
This causes us to have nsaId in discovery and providerNSA in the CS 
header. While these things are relatively minor, I wondering if supporting 
this was a deliberate decision or it just ended up like that. It isn't 
like URLs are expensive, and it does cause a wee bit of extra complexity 
to support this.

Btw. URL and endpoint - what is the difference? Is this just soap / 
non-soap services?

> If you are partial to flatness, I could change everything to OWL and 
> model though assertions and relationships.  I certainly LOVE that model 
> ;-)

I'd be okay if someone took OWL out back and shot it :-). (and I would not 
cry if they took N3 with them).


So, in all I could see something like this for the discovery service:

queryNsaRequest :: QueryNsaRequestType

queryNsaResponse :: QueryNsaResponseType
     discovery :: NsaDiscoveryType *
         # softwareVersion
         # startTime
         # currentTime
         services :: ServicesType *
             service :: ServiceType
                 # type :: xsd:string
                 # url
                 # wsdl
                 # other :: any
                 other :: any *
                 capabilities :: CapabilitiesType *
                     capability :: xsd:string


It is a suggestion, but we don't really lose any functionality AFACIT.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet