There is a comment at the top of this method that reads the following: /* * In doc/lit style pName is the name of the type instance "result" * <result> * <name>Widgets Inc.</name> * <symbol>WID</symbol> * <public>true</public> * </result> * But in rpc/encoded style pName is the name of the type "QuoteInfoType" * <tns:QuoteInfoType xmlns:tns="http://www.getquote.org/test"> * <name xsi:type="xsd:string">Widgets Inc.</name> * <symbol xsi:type="xsd:string">WID</symbol> * <public xsi:type="xsd:boolean">true</public> * </tns:QuoteInfoType> * */
Can someone please refer me to the soap specification document and section that points out this rule? Why does pName behaves differently in doc/lit and rpc style? This triggered the other question below! Question 2, I noticed in simple types, the part name in the response could be arbitrary ( I didn't see it in the wsdl). The samples work because it looks like the soapdeserializer, deliberately, skipping parsing them. For example, here are some snippets from my tcpmonitor when I ran the base service sample: //where did echoStringReturn come from? shouldn't be called "return"? //from base.wsdl: //<message name="echoStringResponse"> // <part name="return" type="xsd:string"/> //</message> <ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/"> <echoStringReturn xsi:type="xsd:string">hello world</echoStringReturn> //where did echoIntegerReturn come from? //from base.wsdl: //<message name="echoIntegerResponse"> // <part name="return" type="xsd:int"/> //</message> <ns1:echoIntegerResponse xmlns:ns1="http://soapinterop.org/"> <echoIntegerReturn xsi:type="xsd:int">56</echoIntegerReturn> However, from the calculator service, the response was more consistent with the wsdl that describes the service, for example, this response: <ns1:addResponse xmlns:ns1="http://localhost/axis/Calculator"> <addReturn xsi:type="xsd:int">3</addReturn> is consistent with the calculator.wsdl response message: <wsdl:message name="addResponse"> <wsdl:part name="addReturn" type="xsd:int"/> </wsdl:message> Why is this inconsistency between the base and calculator services in the format of the return parameters and the arbitrariness of choosing names. I'm trying to understand this betcause if I deploy apache with axis-c as my webservice, but use a client from a different tool, it could break the client's code that is trying to parse the response for a certain "part" but finding something else. Thanks in advance. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/