Peoples, I am making changes to the WSDL this week to close some of the open issues for version 1.1. I would also like to restructure the message definition to simplify the handling code we have written. There was a lot of feedback that the XML definition forced coders to write duplicate code to handle common attributes. This restructuring would clean up the compiled objects so there would be less duplication of code. My proposed changes would not modify the contents or behaviour of the messages, just restructure them a bit to pull out the common attributes into dedicated named structures. I have two possible approaches to this problem: 1. Place the common attributes into the SOAP header and place the operation specific data into the SOAP body. This would be more in line with the intended protocol structure. Common framework header parameters in the SOAP header, and NSI CS operation specific data in the body. 2. Continue to just use the SOAP body and restructure the message definition so that the WSDL compiler generates common code for the common NSI parameters, which will be included in the operation specific XML type. Does anyone have issues accessing data in the SOAP header? Delayed at the airport for 4 hours :-/ Thanks, John.
On Mon, 23 Jan 2012, John MacAuley wrote:
I am making changes to the WSDL this week to close some of the open issues for version 1.1. I would also like to restructure the message definition to simplify the handling code we have written. There was a lot of feedback that the XML definition forced coders to write duplicate code to handle common attributes.
This restructuring would clean up the compiled objects so there would be less duplication of code.
Not everyone uses compiled objects :-).
My proposed changes would not modify the contents or behaviour of the messages, just restructure them a bit to pull out the common attributes into dedicated named structures.
I have two possible approaches to this problem:
1. Place the common attributes into the SOAP header and place the operation specific data into the SOAP body. This would be more in line with the intended protocol structure. Common framework header parameters in the SOAP header, and NSI CS operation specific data in the body.
2. Continue to just use the SOAP body and restructure the message definition so that the WSDL compiler generates common code for the common NSI parameters, which will be included in the operation specific XML type.
What exactly would be removed around. I don't quite follow this distinction (should data go in the SOAP header at all?). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> NORDUnet
participants (2)
-
Henrik Thostrup Jensen -
John MacAuley