To Henrik Thostrup Jensen****** ** ** I am very sorry for our inconvenient log file and ambiguous indication about name space problem.**** ** ** We developed our web services with JAX-WS2.0 based Metro engine, which supports WSDL to Java generation tool.**** To confirm the usage of name spaces in NSI messages, we also used AXIS2 and CFX engines to generate two more Java source codes from the WSDL document.** ** All three engines generated the same reservationRequest message which has two name spaces as attributes of the reservationRequest element and does not have prefixes for all children elements(e.g., requesterNSA, providerNSA, …): **** ** ** <ns5:reservationRequest xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion"*** * xmlns:ns3="http://www.w3.org/2001/04/xmlenc#"**** xmlns:ns4="http://www.w3.org/2000/09/xmldsig#"**** xmlns:ns5=" http://schemas.ogf.org/nsi/2011/07/connection/interface"**** xmlns:ns6=" http://schemas.ogf.org/nsi/2011/07/connection/types">**** <ns5:correlationId>78729d97-8264-4a4b-ad53-8fec5ad529fb</ns5:correlationId>* *** <ns5:replyTo> http://220.69.240.218:2000/kreonet/ConnectionServiceRequester</ns5:replyTo>* *** <ns6:reservation>**** <requesterNSA>urn:ogf:network:NSnetwork:kreonet</requesterNSA>**** <providerNSA>urn:ogf:network:NSnetwork:dynamicKL</providerNSA>**** <reservation>**** ** ** Our implementation utilizes Metro engine to parse NSI messages.**** For your latest trail with ns2 name space for all children elements of reservation element,**** Metro engine returns null value when our implementation asks it to parse requesterNSA element of your reservationRequest message.**** Syntax error was marked in our log because of null value.**** We also have great difficulty to understand why Metro engine returns null value.**** ** ** When we use AXIS2(Jaxb) to parse your message, it returns an exception with unexpected element cause.**** ** ** To fix out this problem, we are studying unprefixed attribute ( http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4), but we felt deeply our limitation about WSDL and name space knowledge.**** ** ** We sincerely ask someone to give us some comments about this problem.**** ** ** Best regards. **** On Tue, Sep 6, 2011 at 6:09 AM, Henrik Thostrup Jensen <htj@ndgf.org> wrote:
Hi
(sorry for mixing my ndgf and nordunet mail addresses, use htj@nordu.netif in doubt, but they end up the same place :-) ).
On Mon, 5 Sep 2011, ???(YoungWook Cha) wrote:
SyntaxError(Cause : ProviderNSA) was not generated by URN problem.
This error was generated by the name space mismatch.
Okay. Do you think it would be possible to add some information to the log. It is very difficult to understand the errors currently loged.
I want to show you a query message from autoBahn that was recently dumped
by our log system.
You can find out that ns2 and ns6 name spaces are defined as attributes of the queryRequest element.
[snip]
The following is a reservationRequest message generated by dynamicKL,
which has two name spaces defined as attributes of the reservationRequest element.
[snip]
In case of your message, ns1 is defined in the Envelope element.
On the other hand, default name space("http://schemas.ogf.org/** nsi/2011/07/connection/types<http://schemas.ogf.org/nsi/2011/07/connection/types>") is defined in the reservation element.
Will you check out the usage of name spaces?
I fail to see the problem. This is a slightly odd, but semantically okay for specifying the default xml namespace for an element and its children. See http://www.w3.org/TR/xml-**names/#defaulting<http://www.w3.org/TR/xml-names/#defaulting>
<SOAP-ENV:Envelope
xmlns:ns0="http://schemas.ogf.**org/nsi/2011/07/connection/**types<http://schemas.ogf.org/nsi/2011/07/connection/types> " xmlns:ns1="http://schemas.ogf.**org/nsi/2011/07/connection/**interface<http://schemas.ogf.org/nsi/2011/07/connection/interface> " xmlns:ns2="http://schemas.**xmlsoap.org/soap/envelope/<http://schemas.xmlsoap.org/soap/envelope/> " xmlns:xsi="http://www.w3.org/**2001/XMLSchema-instance<http://www.w3.org/2001/XMLSchema-instance> " xmlns:SOAP-ENV="http://**schemas.xmlsoap.org/soap/**envelope/<http://schemas.xmlsoap.org/soap/envelope/> "> <SOAP-ENV:Header/> <ns2:Body> <ns1:reservationRequest> <ns1:correlationId>**565619269916347590382575075391** 81676754</ns1:correlationId> <ns1:replyTo>http://orval.**grid.aau.dk:7080/NSI/services/** ConnectionService<http://orval.grid.aau.dk:7080/NSI/services/ConnectionService> </ns1:**replyTo> <reservation xmlns="http://schemas.ogf.org/** nsi/2011/07/connection/types<http://schemas.ogf.org/nsi/2011/07/connection/types> "> <requesterNSA>urn:ogf:network:**nsa:OpenNSA-testclient</** requesterNSA> <providerNSA>urn:ogf:network:**nsa:Martinique-DynamicKL</** providerNSA> <reservation>
I ran the SOAP envelope through an XML parser, and dumped the tree. It looks like this:
<ns0:Envelope xmlns:ns0="http://schemas.**xmlsoap.org/soap/envelope/<http://schemas.xmlsoap.org/soap/envelope/>" xmlns:ns1="http://schemas.ogf.**org/nsi/2011/07/connection/**interface<http://schemas.ogf.org/nsi/2011/07/connection/interface>" xmlns:ns2="http://schemas.ogf.**org/nsi/2011/07/connection/**types<http://schemas.ogf.org/nsi/2011/07/connection/types> "> <ns0:Header /> <ns0:Body> <ns1:reservationRequest> <ns1:correlationId>urn:uuid:**d41e5c6a-d7ff-11e0-ac34-** 00144f20a8d2</ns1:**correlationId>
<ns1:replyTo>http://orval.**grid.aau.dk:7080/NSI/services/** ConnectionService<http://orval.grid.aau.dk:7080/NSI/services/ConnectionService> </ns1:**replyTo> <ns2:reservation> <ns2:requesterNSA>urn:ogf:**network:nsa:OpenNSA-** testclient</ns2:requesterNSA> <ns2:providerNSA>urn:ogf:**network:nsa:Aruba-OpenNSA</** ns2:providerNSA> <ns2:reservation> <ns2:globalReservationId>gid-** 0962</ns2:globalReservationId> <ns2:description>Test Connection</ns2:description> <ns2:connectionId>conn-510</**ns2:connectionId> <ns2:serviceParameters> <ns2:schedule> <ns2:startTime>2011-09-05T20:**46:19Z</ns2:startTime> <ns2:endTime>2011-09-05T20:48:**19Z</ns2:endTime> </ns2:schedule> <ns2:bandwidth> <ns2:desired>1000</ns2:**desired> </ns2:bandwidth> </ns2:serviceParameters> <ns2:path> <ns2:directionality>**unidirectional</ns2:** directionality> <ns2:sourceSTP> <ns2:stpId>urn:ogf:network:**stp:Aruba:A1</ns2:stpId> </ns2:sourceSTP> <ns2:destSTP> <ns2:stpId>urn:ogf:network:** stp:Martinique:M3</ns2:stpId> </ns2:destSTP> </ns2:path> </ns2:reservation> </ns2:reservation> </ns1:reservationRequest> </ns0:Body> </ns0:Envelope>
This uses more common xmlns declarations, but is sementically identical. I tried using the above payload instead, but it fails with the same message.
If I'm doing something wrong, could you point it out clearly, and try to show how it should look like instead.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
-- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon@hotmail.com "Expect Great Things from God Attempt Great Things for God"
Hi again On Tue, 6 Sep 2011, jeonghoon moon wrote:
I am very sorry for our inconvenient log file and ambiguous indication about name space problem.
We are all trying to figure out what is going on here :-).
We developed our web services with JAX-WS2.0 based Metro engine, which supports WSDL to Java generation tool.
To confirm the usage of name spaces in NSI messages, we also used AXIS2 and CFX engines to generate two more Java source codes from the WSDL document.
All three engines generated the same reservationRequest message which has two name spaces as attributes of the reservationRequest element and does not have prefixes for all children elements(e.g., requesterNSA, providerNSA, …):
Mm... okay. I am using SUDS. So far I have found two bugs in SUDS. It is quite likely that there are more.
<ns5:reservationRequest xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2001/04/xmlenc#" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns6="http://schemas.ogf.org/nsi/2011/07/connection/types"> <ns5:correlationId>78729d97-8264-4a4b-ad53-8fec5ad529fb</ns5:correlationId> <ns5:replyTo>http://220.69.240.218:2000/kreonet/ConnectionServiceRequester</ns5:replyTo> <ns6:reservation> <requesterNSA>urn:ogf:network:NSnetwork:kreonet</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:dynamicKL</providerNSA> <reservation>
This strikes me as incorrect. I would expect a default namespace declaration or an explicit namespace in front of the requesterNSA, providerNSA, and reservation elements. But I could very well be wrong.
Our implementation utilizes Metro engine to parse NSI messages.
For your latest trail with ns2 name space for all children elements of reservation element,
Metro engine returns null value when our implementation asks it to parse requesterNSA element of your reservationRequest message.
Syntax error was marked in our log because of null value.
We also have great difficulty to understand why Metro engine returns null value.
When we use AXIS2(Jaxb) to parse your message, it returns an exception with unexpected element cause.
Since you have tried two different implementations it does point to the SOAP stack I'm using. However my impression from reading the WSDL manually is that everything under the <ns6:reservation> should be under the xmlns:ns6="http://schemas.ogf.org/nsi/2011/07/connection/types namespace as well. John, can you comment here?
To fix out this problem, we are studying unprefixed attribute (http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4), but we felt deeply our limitation about WSDL and name space knowledge.
This is my first venture into WSDL as well, so I am puzzled as well.
We sincerely ask someone to give us some comments about this problem.
+1 from here as well. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
All, I generated a request through OpenDRAC and here is the format of the reservation message. I have compared it to Henrik's message and there is definitely an issue with the "<ns6:reservation>" in my message and the "<ns0:reservation>" in his message since they are from two separate namespaces. If you look in the file ogf_nsi_connection_interface_v1_0.wsdl you will see that ReservationRequestType is referencing the reservation message definition (ref="types:reservation") from the type namespace. This means that <ns6:reservation> shown below is correct. Henrik's implementation seems to be using the interface namespace. Looks like there is a bug in his SOAP stack. Now we can get around it but I will need to modify the WSDL definition to not reference elements, but use imported types instead. This will require everyone to make changes to their implementations. I assume this is too risky for Rio... John. <?xml version='1.0' encoding='utf-8'?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns5:reservationRequest xmlns:ns6="http://schemas.ogf.org/nsi/2011/07/connection/types" xmlns:ns5="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2001/04/xmlenc#" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#"> <ns5:correlationId>urn:uuid:5d2a2bc0-a51a-4418-b5d4-322807247593</ns5:correlationId> <ns5:replyTo>http://localhost:8084/nsi-v1/ConnectionServiceRequester</ns5:replyTo> <ns6:reservation> <requesterNSA>urn:ogf:network:nsa:ferb.surfnet.nl</requesterNSA> <providerNSA>urn:ogf:network:nsa:phineas.surfnet.nl</providerNSA> <sessionSecurityAttr> <ns4:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="globalUserName"> <ns4:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">jrv@internet2.edu</ns4:AttributeValue> </ns4:Attribute> </sessionSecurityAttr> <reservation> <globalReservationId>urn:ogf:network:service:1ae919be-bff0-4053-bf1f-3b629f694197</globalReservationId> <description>This is a test schedule connecting Aiden to Ashley</description> <connectionId>urn:uuid:5d2a2bc0-a51a-4418-b5d4-322807247593</connectionId> <serviceParameters> <schedule> <startTime>2011-09-08T00:00:00.000-04:00</startTime> <endTime>2011-09-09T00:00:00.000-04:00</endTime> </schedule> <bandwidth> <desired>200</desired> </bandwidth> </serviceParameters> <path> <directionality>Bidirectional</directionality> <sourceSTP> <stpId>urn:ogf:network:stp:Aruba:Aiden</stpId> </sourceSTP> <destSTP> <stpId>urn:ogf:network:stp:Aruba:Ashley</stpId> </destSTP> </path> </reservation> </ns6:reservation> </ns5:reservationRequest> </S:Body> </S:Envelope> ----- Original Message -----
From: "Henrik Thostrup Jensen" <htj@nordu.net> To: "jeonghoon moon" <otello90@gmail.com> Cc: "Henrik Thostrup Jensen" <htj@ndgf.org>, "???(YoungWook Cha)" <ywcha@andong.ac.kr>, "Jerry Sobieski" <jerry@nordu.net>, "JongUk Kong" <jonguk.kong@gmail.com>, "John MacAuley" <john.macauley@surfnet.nl>, "NSI Working Group" <nsi-wg@ogf.org> Sent: Tuesday, September 6, 2011 9:26:39 AM Subject: Re: [Nsi-wg] Open dynamicKL NSA
Hi again
On Tue, 6 Sep 2011, jeonghoon moon wrote:
I am very sorry for our inconvenient log file and ambiguous indication about name space problem.
We are all trying to figure out what is going on here :-).
We developed our web services with JAX-WS2.0 based Metro engine, which supports WSDL to Java generation tool.
To confirm the usage of name spaces in NSI messages, we also used AXIS2 and CFX engines to generate two more Java source codes from the WSDL document.
All three engines generated the same reservationRequest message which has two name spaces as attributes of the reservationRequest element and does not have prefixes for all children elements(e.g., requesterNSA, providerNSA, …):
Mm... okay. I am using SUDS. So far I have found two bugs in SUDS. It is quite likely that there are more.
<ns5:reservationRequest xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2001/04/xmlenc#" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns6="http://schemas.ogf.org/nsi/2011/07/connection/types"> <ns5:correlationId>78729d97-8264-4a4b-ad53-8fec5ad529fb</ns5:correlationId> <ns5:replyTo>http://220.69.240.218:2000/kreonet/ConnectionServiceRequester</ns5:replyTo> <ns6:reservation> <requesterNSA>urn:ogf:network:NSnetwork:kreonet</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:dynamicKL</providerNSA> <reservation>
This strikes me as incorrect. I would expect a default namespace declaration or an explicit namespace in front of the requesterNSA, providerNSA, and reservation elements.
But I could very well be wrong.
Our implementation utilizes Metro engine to parse NSI messages.
For your latest trail with ns2 name space for all children elements of reservation element,
Metro engine returns null value when our implementation asks it to parse requesterNSA element of your reservationRequest message.
Syntax error was marked in our log because of null value.
We also have great difficulty to understand why Metro engine returns null value.
When we use AXIS2(Jaxb) to parse your message, it returns an exception with unexpected element cause.
Since you have tried two different implementations it does point to the SOAP stack I'm using. However my impression from reading the WSDL manually is that everything under the <ns6:reservation> should be under the xmlns:ns6="http://schemas.ogf.org/nsi/2011/07/connection/types namespace as well.
John, can you comment here?
To fix out this problem, we are studying unprefixed attribute (http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4), but we felt deeply our limitation about WSDL and name space knowledge.
This is my first venture into WSDL as well, so I am puzzled as well.
We sincerely ask someone to give us some comments about this problem.
+1 from here as well.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
On Wed, 7 Sep 2011, John MacAuley wrote:
Looks like there is a bug in his SOAP stack.
Correct. SUDS appears to have some issues there (there is a bug entry for this problem, but the proposed patch is wrong). I've managed to come up with a patch which fixes the issue in SUDS, though I don't quite understand it :-/. Thanks for everyones patienece with this. Especially the DynamicKL guys. Payload looks like this now: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:ns0="http://schemas.ogf.org/nsi/2011/07/connection/types" xmlns:ns1="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <ns2:Body> <ns1:reservationRequest> <ns1:correlationId>urn:uuid:1180666e-da0a-11e0-a118-00144f20a8d2</ns1:correlationId> <ns1:replyTo>http://orval.grid.aau.dk:7080/NSI/services/ConnectionService</ns1:replyTo> <ns0:reservation> <requesterNSA>urn:ogf:network:nsa:Aruba-OpenNSA</requesterNSA> <providerNSA>urn:ogf:network:nsa:Aruba-OpenNSA</providerNSA> <reservation> <globalReservationId>gid-0408</globalReservationId> <description>Test Connection</description> <connectionId>conn-504</connectionId> <serviceParameters> <schedule> <startTime>2011-09-08T11:04:39Z</startTime> <endTime>2011-09-08T11:06:39Z</endTime> </schedule> <bandwidth> <desired>1000</desired> </bandwidth> </serviceParameters> <path> <directionality>Bidirectional</directionality> <sourceSTP> <stpId>urn:ogf:network:stp:Aruba:A1</stpId> </sourceSTP> <destSTP> <stpId>urn:ogf:network:stp:Aruba:A2</stpId> </destSTP> </path> </reservation> </ns0:reservation> </ns1:reservationRequest> </ns2:Body> </SOAP-ENV:Envelope> Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
To Henrik We just fixed implementation, and try again access ! best regards On Tue, Sep 6, 2011 at 10:26 PM, Henrik Thostrup Jensen <htj@nordu.net>wrote:
Hi again
On Tue, 6 Sep 2011, jeonghoon moon wrote:
I am very sorry for our inconvenient log file and ambiguous indication
about name space problem.
We are all trying to figure out what is going on here :-).
We developed our web services with JAX-WS2.0 based Metro engine, which
supports WSDL to Java generation tool.
To confirm the usage of name spaces in NSI messages, we also used AXIS2 and CFX engines to generate two more Java source codes from the WSDL document.
All three engines generated the same reservationRequest message which has two name spaces as attributes of the reservationRequest element and does not have prefixes for all children elements(e.g., requesterNSA, providerNSA, …):
Mm... okay. I am using SUDS. So far I have found two bugs in SUDS. It is quite likely that there are more.
<ns5:reservationRequest xmlns:**ns2="urn:oasis:names:tc:SAML:**
2.0:assertion" xmlns:**ns3="http://www.w3.org/2001/**04/xmlenc#<http://www.w3.org/2001/04/xmlenc#> " xmlns:**ns4="http://www.w3.org/2000/**09/xmldsig#<http://www.w3.org/2000/09/xmldsig#> " xmlns:**ns5="http://schemas.ogf.org/** nsi/2011/07/connection/**interface<http://schemas.ogf.org/nsi/2011/07/connection/interface> " xmlns:**ns6="http://schemas.ogf.org/** nsi/2011/07/connection/types<http://schemas.ogf.org/nsi/2011/07/connection/types> "> <ns5:correlationId>**78729d97-8264-4a4b-ad53-**8fec5ad529fb</ns5:** correlationId> <ns5:replyTo>http://220.**69.240.218:2000/kreonet/** ConnectionServiceRequester<http://220.69.240.218:2000/kreonet/ConnectionServiceRequester> </**ns5:replyTo> <ns6:reservation> <requesterNSA>urn:ogf:**network:NSnetwork:kreonet</** requesterNSA> <providerNSA>urn:ogf:**network:NSnetwork:dynamicKL</** providerNSA> <reservation>
This strikes me as incorrect. I would expect a default namespace declaration or an explicit namespace in front of the requesterNSA, providerNSA, and reservation elements.
But I could very well be wrong.
Our implementation utilizes Metro engine to parse NSI messages.
For your latest trail with ns2 name space for all children elements of reservation element,
Metro engine returns null value when our implementation asks it to parse requesterNSA element of your reservationRequest message.
Syntax error was marked in our log because of null value.
We also have great difficulty to understand why Metro engine returns null value.
When we use AXIS2(Jaxb) to parse your message, it returns an exception with unexpected element cause.
Since you have tried two different implementations it does point to the SOAP stack I'm using. However my impression from reading the WSDL manually is that everything under the <ns6:reservation> should be under the xmlns:ns6="http://schemas.ogf.**org/nsi/2011/07/connection/**types<http://schemas.ogf.org/nsi/2011/07/connection/types>namespace as well.
John, can you comment here?
To fix out this problem, we are studying unprefixed attribute
(http://www.rpbourret.com/xml/**NamespaceMyths.htm#myth4<http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4>), but we felt deeply our limitation about WSDL and name space knowledge.
This is my first venture into WSDL as well, so I am puzzled as well.
We sincerely ask someone to give us some comments about this problem.
+1 from here as well.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
-- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon@hotmail.com "Expect Great Things from God Attempt Great Things for God"
Hi On Thu, 8 Sep 2011, jeonghoon moon wrote:
We just fixed implementation, and try again access !
This is what I see from the log: [2011-09-08 21:59:25] INFO [reservation] connectionId : urn:uuid:9376575a-da19-11e0-b7bb-00144f20a8d2, path : urn:ogf:network:stp:Martinique:M1 -> urn:ogf:network:stp:Martinique:M3 [2011-09-08 21:59:25] INFO [reservation] replyTo : http://orval.grid.aau.dk:7080/NSI/services/ConnectionService [2011-09-08 21:59:25] ERROR [server Exception] connectionId : urn:uuid:9376575a-da19-11e0-b7bb-00144f20a8d2 It is getting a lot further than before, which is good. Again, it is difficult to see what is the actual error here. Not sure with the duplicate connetionId (in the previous logs) is about, I am generating a uuid with each request. I am not getting a callback. I am not sure if it is issued or there is a firewall problem (I don't have any firewall in my end). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
To Henrik Thostrup Jensen****** ** ** We are sorry again for our unclear log file.**** ** ** Our implementation is based on *XML Gregolian Calendar* type to make reservation.**** Will you check out your schedule parameters(startTime, endTime).**** ** ** Best regards. On Thu, Sep 8, 2011 at 10:03 PM, Henrik Thostrup Jensen <htj@nordu.net>wrote:
Hi
On Thu, 8 Sep 2011, jeonghoon moon wrote:
We just fixed implementation, and try again access !
This is what I see from the log:
[2011-09-08 21:59:25] INFO [reservation] connectionId : urn:uuid:9376575a-da19-11e0-**b7bb-00144f20a8d2, path : urn:ogf:network:stp:**Martinique:M1 -> urn:ogf:network:stp:**Martinique:M3 [2011-09-08 21:59:25] INFO [reservation] replyTo : http://orval.grid.aau.dk:7080/**NSI/services/ConnectionService<http://orval.grid.aau.dk:7080/NSI/services/ConnectionService> [2011-09-08 21:59:25] ERROR [server Exception] connectionId : urn:uuid:9376575a-da19-11e0-**b7bb-00144f20a8d2
It is getting a lot further than before, which is good.
Again, it is difficult to see what is the actual error here.
Not sure with the duplicate connetionId (in the previous logs) is about, I am generating a uuid with each request.
I am not getting a callback. I am not sure if it is issued or there is a firewall problem (I don't have any firewall in my end).
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
-- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon@hotmail.com "Expect Great Things from God Attempt Great Things for God"
Hi On Thu, 8 Sep 2011, jeonghoon moon wrote:
Our implementation is based on XML Gregolian Calendar type to make reservation.
Will you check out your schedule parameters(startTime, endTime).
This is what I am sending for startTime and endTime: 2011-09-08T12:55:40Z 2011-09-08T12:57:40Z Which should be valid xsd:dateTime values. (I don't see the importance of the implementation calendar). You can parse the timestamps as ISO timestamps (a superset of xsd:dateTime) to get them into your format. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
To Henrik Thostrup Jensen NSI schedule parameters(startTime, endTime) have to use xsd:dateTime(XMLGregorianCalendar) as defined in the ogf_nsi_connection_types_v1_0.xsd. Unfortunately, we cannot support your schedule parameters in our implementation. Development members are now on board to Rio. Best regards. =================================== http://ngn.andong.ac.kr NGN Lab. Comp. Engineering Dept. Andong National University +82-10-2456-3237, +82-54-820-5714 =================================== ----- Original Message ----- From: "Henrik Thostrup Jensen" <htj@nordu.net> To: "jeonghoon moon" <otello90@gmail.com> Cc: "???(YoungWook Cha)" <ywcha@andong.ac.kr>; "JongUk Kong" <jonguk.kong@gmail.com>; "NSI Working Group" <nsi-wg@ogf.org> Sent: Thursday, September 08, 2011 10:50 PM Subject: Re: [Nsi-wg] Open dynamicKL NSA
Hi
On Thu, 8 Sep 2011, jeonghoon moon wrote:
Our implementation is based on XML Gregolian Calendar type to make reservation.
Will you check out your schedule parameters(startTime, endTime).
This is what I am sending for startTime and endTime:
2011-09-08T12:55:40Z 2011-09-08T12:57:40Z
Which should be valid xsd:dateTime values. (I don't see the importance of the implementation calendar). You can parse the timestamps as ISO timestamps (a superset of xsd:dateTime) to get them into your format.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
To Henrik Thostrup Jensen Please retry to access our server We just fixed some issues our server implement see you in rio best regards On Thu, Sep 8, 2011 at 10:50 PM, Henrik Thostrup Jensen <htj@nordu.net>wrote:
Hi
On Thu, 8 Sep 2011, jeonghoon moon wrote:
Our implementation is based on XML Gregolian Calendar type to make
reservation.
Will you check out your schedule parameters(startTime, endTime).
This is what I am sending for startTime and endTime:
2011-09-08T12:55:40Z 2011-09-08T12:57:40Z
Which should be valid xsd:dateTime values. (I don't see the importance of the implementation calendar). You can parse the timestamps as ISO timestamps (a superset of xsd:dateTime) to get them into your format.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
-- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon@hotmail.com "Expect Great Things from God Attempt Great Things for God"
Hi On Sun, 11 Sep 2011, jeonghoon moon wrote:
Please retry to access our server
We just fixed some issues our server implement
OK, things are looking really good. There is however a problem with your reservationConfirmed reply. It looks like this: Received SOAP request. Action: "http://schemas.ogf.org/nsi/2011/07/connection/service/reservationConfirmed". Length: 1391 RC (reply){ correlationId = "21b705ff-940c-4085-bd5d-6026df1b398d" reservationConfirmed = (ReservationConfirmedType){ requesterNSA = "urn:ogf:network:nsa:Martinique-DynamicKL" providerNSA = "urn:ogf:network:nsa:Aruba-OpenNSA" reservation = (ReservationInfoType){ [snip] You are mixing up requester and provider role. As I am requesting a connection, OpenNSA should be the requester, and the DynamicKL the provider as it provides the connection.
see you in rio
I won't be in Rio, but will skype in when possible. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
To Henrik Retry access dynamicKL, we fixed some issues best regards On Mon, Sep 12, 2011 at 5:33 PM, Henrik Thostrup Jensen <htj@nordu.net>wrote:
Hi
On Sun, 11 Sep 2011, jeonghoon moon wrote:
Please retry to access our server
We just fixed some issues our server implement
OK, things are looking really good. There is however a problem with your reservationConfirmed reply. It looks like this:
Received SOAP request. Action: "http://schemas.ogf.org/nsi/** 2011/07/connection/service/**reservationConfirmed<http://schemas.ogf.org/nsi/2011/07/connection/service/reservationConfirmed>". Length: 1391 RC (reply){ correlationId = "21b705ff-940c-4085-bd5d-**6026df1b398d" reservationConfirmed = (ReservationConfirmedType){ requesterNSA = "urn:ogf:network:nsa:**Martinique-DynamicKL"
providerNSA = "urn:ogf:network:nsa:Aruba-**OpenNSA" reservation = (ReservationInfoType){ [snip]
You are mixing up requester and provider role. As I am requesting a connection, OpenNSA should be the requester, and the DynamicKL the provider as it provides the connection.
see you in rio
I won't be in Rio, but will skype in when possible.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
-- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon@hotmail.com "Expect Great Things from God Attempt Great Things for God"
participants (4)
-
???(YoungWook Cha) -
Henrik Thostrup Jensen -
jeonghoon moon -
John MacAuley