Hi I've been looking at the discovery WSDL, and was a bit amazed with how complicated it turned up being. Now I have not been very active in NSI for the last couple of months, and have missed a couple of meeting, but I think we've ended up with something a lot more complex than what we discussed in Oxford and the mailing lists. For the request it looks like this: queryNsaRequest :: QueryNsaRequestType queryNsaRequest :: RequestType filter :: FilterType * nsaId :: NsaIdType * serviceType :: xsd:string * This is my own notation. Sorry if it is tricky to read. For the request it possibly to define summary of detailed request, but I haven't found any documentation on what should be returned for what. Secondly it is possible to have multiple filters, each specifying multiple nsaIds and serviceTypes. The parameters for each filter should be ORed, however there does not appear to be any documentation for how to deal with multiple filters. It also appears to be complete and utterly overkill as most NSAs will host 2 or 3 services. Now, for the response: queryNsaResponse :: QueryNsaResponseType discovery :: NsaDiscoveryType * # nsaId # softwareVersion # startTime # currentTime services :: ServicesType * service :: ServiceType #other :: any description :: xsd:string versions :: VersionsType * version :: VersionType # name # version # endpoint # wsdl # url # other :: any other :: any * capabilities :: CapabilitiesType * capability ft:TypeValuePairType # type :: xsd:string ! # targetNamespace :: xsd:anyURI value :: xsd:string * other :: any * Here we are dealing with a datastructure potentially 9 levels deep. Arguably, some of this is due to the ackward way XML/WSDL handles lists, but there are still 4 levels of nested lists. I won't go into any details here. I am not trying to do a witch-hunt on John here. In fact he may just have been listening to everyone, but what we ended up with here is pretty bad, and is in my opion very far from what we discussed in Oxford. I think we need to setup some review of WSDLs as well in order to ensure that these things do not spin out of control like this. Anyways, something to talk about tomorrow :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
I understand the comments on the query. i was conflicted as well. I am also wondering if I meant AND :-) 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. 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. If you are partial to flatness, I could change everything to OWL and model though assertions and relationships. I certainly LOVE that model ;-) John. On 2012-11-27, at 4:50 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
I've been looking at the discovery WSDL, and was a bit amazed with how complicated it turned up being. Now I have not been very active in NSI for the last couple of months, and have missed a couple of meeting, but I think we've ended up with something a lot more complex than what we discussed in Oxford and the mailing lists.
For the request it looks like this:
queryNsaRequest :: QueryNsaRequestType queryNsaRequest :: RequestType filter :: FilterType * nsaId :: NsaIdType * serviceType :: xsd:string *
This is my own notation. Sorry if it is tricky to read. For the request it possibly to define summary of detailed request, but I haven't found any documentation on what should be returned for what. Secondly it is possible to have multiple filters, each specifying multiple nsaIds and serviceTypes. The parameters for each filter should be ORed, however there does not appear to be any documentation for how to deal with multiple filters. It also appears to be complete and utterly overkill as most NSAs will host 2 or 3 services.
Now, for the response:
queryNsaResponse :: QueryNsaResponseType discovery :: NsaDiscoveryType * # nsaId # softwareVersion # startTime # currentTime services :: ServicesType * service :: ServiceType #other :: any description :: xsd:string versions :: VersionsType * version :: VersionType # name # version # endpoint # wsdl # url # other :: any other :: any * capabilities :: CapabilitiesType * capability ft:TypeValuePairType # type :: xsd:string ! # targetNamespace :: xsd:anyURI value :: xsd:string * other :: any *
Here we are dealing with a datastructure potentially 9 levels deep. Arguably, some of this is due to the ackward way XML/WSDL handles lists, but there are still 4 levels of nested lists. I won't go into any details here.
I am not trying to do a witch-hunt on John here. In fact he may just have been listening to everyone, but what we ended up with here is pretty bad, and is in my opion very far from what we discussed in Oxford. I think we need to setup some review of WSDLs as well in order to ensure that these things do not spin out of control like this.
Anyways, something to talk about tomorrow :-).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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
Hi Just a re-iteration of this issue. There is also an issue with the current discovery service wrt. URLs and NSA identity. So far we have discussed as what is need for bootstrapping is a URL. However the current discovery service allows for several NSAs in the same service. This means that what is needed for bootstrapping is actually a URL and an NSA identity. With the suggestion in the previous email a discovery service (URL) would only represent a single NSA. The "downside" of this is that it requires a multi-NSA deamon to have multiple discovery URLs for each NSA. This somewhat also relates to issue of not having the NSI header in the discovery service (which I think makes sense). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen -
John MacAuley