Hi Right now we have a construction in the reserve request (and confirmations), like hits: <serviceType>http://services.ogf.org/nsi/2013/07/descriptions/EVTS.A-GOLE</serviceType> <p2psrv:evts> <capacity>200</capacity> <directionality>Bidirectional</directionality> <sourceSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:ps</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:uvalight</localId> </destSTP> <mtu>1500</mtu> <burstsize>5000000</burstsize> <sourceVLAN>1780</sourceVLAN> <destVLAN>1780</destVLAN> </p2psrv:evts> AFAICT the serviceType and element name of the service (<p2psrv:evts>) has the exact same purpose: To tell the NSA which type of service is requested. Having serviceType specific to A-GOLE seems a bit weird. It is still an EVTS service. For getting endpoints in the A-GOLE one should just select the right STPs. AFAICT the serviceType field is completely redundant. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
I had originally thought the same until we went through the service definition exercise. The service schema included is related to the service being offered, but does not uniquely define it. For example, we may have multiple independent service definitions reusing the p2p schema for their service even though they are different technologies. This was why I did not use the service element name to uniquely identify the service description. The serviceType identifies the service description that tells you which elements are present in the request (and yes there can be more than one element). John On 2013-09-25, at 7:06 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
Right now we have a construction in the reserve request (and confirmations), like hits:
<serviceType>http://services.ogf.org/nsi/2013/07/descriptions/EVTS.A-GOLE</serviceType> <p2psrv:evts> <capacity>200</capacity> <directionality>Bidirectional</directionality> <sourceSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:ps</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:uvalight</localId> </destSTP> <mtu>1500</mtu> <burstsize>5000000</burstsize> <sourceVLAN>1780</sourceVLAN> <destVLAN>1780</destVLAN> </p2psrv:evts>
AFAICT the serviceType and element name of the service (<p2psrv:evts>) has the exact same purpose: To tell the NSA which type of service is requested. Having serviceType specific to A-GOLE seems a bit weird. It is still an EVTS service. For getting endpoints in the A-GOLE one should just select the right STPs. AFAICT the serviceType field is completely redundant.
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
On Wed, 25 Sep 2013, John MacAuley wrote:
The service schema included is related to the service being offered, but does not uniquely define it.
You mean the service definition does not define the service :-).
For example, we may have multiple independent service definitions reusing the p2p schema for their service even though they are different technologies.
In that case the STPs can represent the technology. Perhaps a better example is with monitored vs. non-monitored link. In this case the syntactical description of the two services are exactly the same, but the semantics of the services are quite different. This can be solved using serviceType, but it could just as well be solved by creating a new schema with MonitoredEVTSType that extends from the existing EVTSType. I really don't think we need two ways of defining services.
The serviceType identifies the service description that tells you which elements are present in the request (and yes there can be more than one element).
I can tell that just fine by looking at the tag of the XML element. SOAP does this just fine. In fact, all schema validating XML parser does this. Btw. why is that on all the calls, we have been speaking about the service definition as there being a single one in a request, and when it pops up in WSDL it is a list? If you want the possiblity of defining multiple services, I'd reckon this construction is much clearer: <multievtsservice> <evts> .. </evts> <evts> ... </evts> </multievtsservice> Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
This was discussed in the weekly NSI meetings but you where not in attendance I remember going over this with Chin and made a comment that we really needed you to work through some of the mechanics. It was during this time we agreed that the SD could specify multiple schema elements. There is always the possibility of defining new schema that encapsulate multiple existing schema elements, but we thought forcing a single would be an unnecessary restriction, especially when building composite services. Also, we wanted the SD name decoupled from the schema element name so you could specify different parameter ranges/defaults and add attributes not directly related to the schema, while still reusing the existing core service untouched. At the moment I could add a monitored attribute that flows untouched through the EVTS service logic, but a monitoring system can pick it up from a secondary mechanism (DB, logs, etc) and begin the monitoring process. Thanks, John On 2013-09-27, at 8:09 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Wed, 25 Sep 2013, John MacAuley wrote:
The service schema included is related to the service being offered, but does not uniquely define it.
You mean the service definition does not define the service :-).
For example, we may have multiple independent service definitions reusing the p2p schema for their service even though they are different technologies.
In that case the STPs can represent the technology.
Perhaps a better example is with monitored vs. non-monitored link. In this case the syntactical description of the two services are exactly the same, but the semantics of the services are quite different. This can be solved using serviceType, but it could just as well be solved by creating a new schema with MonitoredEVTSType that extends from the existing EVTSType.
I really don't think we need two ways of defining services.
The serviceType identifies the service description that tells you which elements are present in the request (and yes there can be more than one element).
I can tell that just fine by looking at the tag of the XML element. SOAP does this just fine. In fact, all schema validating XML parser does this.
Btw. why is that on all the calls, we have been speaking about the service definition as there being a single one in a request, and when it pops up in WSDL it is a list?
If you want the possiblity of defining multiple services, I'd reckon this construction is much clearer:
<multievtsservice> <evts> .. </evts> <evts> ... </evts> </multievtsservice>
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
participants (2)
-
Henrik Thostrup Jensen -
John MacAuley