Earlier blog articles have mentioned many compatibility issues related to the implementation of web service clients in the same language or different languages due to different implementation details. The problem solved yesterday is explained again in a boundary issue that the interconnection standards of such heterogeneous environments are implemented in different ways. Different understandings may cause some compatibility problems. Problem: when the interface return type is an object and an attribute of this object is an array type, the object of this array type cannot be correctly parsed in the returned SOAP message. An object is defined as follows:
Public
ClassDemostruct
ImplementsSerializable {
PrivateRecordtype [] recordarr;
PrivateString name;
PublicRecordtype [] getrecordarr (){
ReturnRecordarr ;}
Public
VoidSetrecordarr (recordtype [] recordarr ){
This. Recordarr = recordarr ;}
PublicString getname (){
ReturnName ;}
Public
VoidSetname (string name ){
ThisThe. Name = Name ;}} interface is defined as follows:
Public
InterfaceIdemotest {demostruct queryaccountrecord (string account);} problem analysis: the problem of returning the array object has been solved earlier, but when the array belongs to the object and acts as an attribute, an error occurred. First, there are two ways to define an array in the WSDL: 1. Define maxoccurs = "unbounded ". <XSD: complextype name = "arrayofrecordtype"> <XSD: sequence> <XSD: element maxoccurs = "unbounded" minoccurs = "0" name = "recordtype" nillable = "true" type = "NS1: recordtype"/> </XSD: sequence> </XSD: complextype> 2. defines the arraytype type in soap encoding. <Xs: complextype name = "arrayofrecordtype"> <Xs: complexcontent> <Xs: Restriction base = "soapenc: array"> <Xs: attribute ref = "soapenc: arraytype" WSDL: arraytype = "ax22: recordtype []"> </Xs: attribute> </Xs: Restriction> </Xs: complexcontent> </Xs: complextype> for Java clients and servers, there is no big difference between the two configuration methods. net, the latter is better, it can generate the array segment type of arrayofrecordtype, and manually parse the internal information of the array. First, the service framework of axis2 is integrated in ASF. Therefore, this type of problem should be determined whether the customization in the integration causes a problem in the SOAP message or the issue occurs when the axis2 server parses the message itself. Build two tomcat-based axis2 and xfire release environments and ASF Service Release environments, and use the soapui tool to intercept the message return package, based on the returned results, we can confirm that the soap messages returned by axis2 and ASF are the same, and the messages returned by xfire are in another form. SOAP message package returned by xfire: <soap: envelope xmlns: Soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: XSD = "http://www.w3.org/2001/XMLSchema" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"> <soap: body> <queryaccountrecordresponse xmlns = "http://cmptest2.webservice.asf.xplatform.alisoft.com"> <out> <name xmlns = "http://cmptest.webservice.asf.xplatform.alisoft.com"> 1 </Name> <recordarr xmlns = "http: // cmptest Balance "> <recordtype> <accountbalance> 12.12 </accountbalance> <accountid> 1 </accountid> <isdeleted> false </isdeleted> </recordtype> <accountbalance> 12.12 </accountbalance> <accountid> 1 </accountid> <isdeleted> false </isdeleted> </recordtype> </recordarr> </out> </queryaccountrecordresponse> </soap: body> </soap: envelope> message package returned by axis2 and ASF: <soapenv: envelope xmlns: So Apenv = "http://schemas.xmlsoap.org/soap/envelope/"> <soapenv: Body> <ns: queryaccountrecordresponse xmlns: NS = "http://cmptest.webservice.asf.xplatform.alisoft.com"> <ns: return type = "com. alisoft. xplatform. ASF. webService. cmptest. demostruct "xmlns: ax21 =" http://cmptest.webservice.asf.xplatform.alisoft.com/xsd "> <ax21: Name> 1 </ax21: Name> <ax21: recordarr type =" com. alisoft. xplatform. ASF. webService. cmptest. REC Ordtype "> <ax21: accountbalance> 12.12 </ax21: accountbalance> <ax21: accountid> 1 </ax21: accountid> <ax21: isdeleted> false </ax21: isdeleted> </ax21: recordarr> <ax21: recordarr type = "com. alisoft. xplatform. ASF. webService. cmptest. recordtype "> <ax21: accountbalance> 12.12 </ax21: accountbalance> <ax21: accountid> 1 </ax21: accountid> <ax21: isdeleted> false </ax21: isdeleted> </ax21: recordarr> </ns: Return> </ns: queryaccou Ntrecordresponse> </soapenv: Body> </soapenv: envelope> according to the message, axis2 splits the array attribute object into multiple fragments and stores them in soap in parallel, the label of each clip is the name of this array attribute. Xfire uses the array attribute as a separate fragment, and the fragment contains multiple entity fragments. The tag of the fragment is the object name. Considering the definition in WSDL, I think xfire is a reasonable parsing method. In addition, I also advocate the xfire client for Java-developed ISVs in the early stage, therefore, we plan to transform the server and client integrated with axis2 in ASF. Solution to the problem: in fact, axis2 mainly experienced the following parts when making soap output: converting the returned object into a DOM tree and then converting the DOM tree into an XML stream, finally, it is converted into a SOAP message package. Therefore, you only need to modify the structure when the object is changed to a DOM tree, so that the subsequent work can be normal. Similarly, the ASF client is a reverse process. You only need to transform the DOM tree into an object. Do not repeat the details. Repeated problems: after the transformation, the ASF framework will be able to return messages that can be identified by xfire and solve the xfire problem. However, because a lot of content has been modified, we need to perform a comprehensive unit test. As a result, a test found a problem and found that the original normal interface returned array objects could not be normal. After the SOAP message is intercepted, it is found that if the original SOAP message package of the array type is returned as follows: <soap: envelope xmlns: Soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: XSD = "http://www.w3.org/2001/XMLSchema" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"> <soap: Body> <getuseraccountarrresponse xmlns = "http://webservice.asf.xplatform.alisoft.com"> <out> <NS1: accountbean xmlns: NS1 = "http://object.webservice.asf.xplatform.alisoft.com"> <accountbalance XM LNS = "http://object.webservice.asf.xplatform.alisoft.com"> 100.23 </accountbalance> <accountid xmlns = "http://object.webservice.asf.xplatform.alisoft.com"> 1 </accountid> <isdeleted xmlns = "http://object.webservice.asf.xplatform.alisoft.com"> false </isdeleted> </NS1: accountbean> <NS1: accountbean xmlns: NS1 = "http://object.webservice.asf.xplatform.alisoft.com"> <accountbalance xmlns = "http://object.webservice .Asf.xplatform.alisoft.com "> 111.23 </accountbalance> <accountid xmlns =" http://object.webservice.asf.xplatform.alisoft.com "> 11 </accountid> <isdeleted xmlns =" http://object.webservice.asf.xplatform.alisoft.com "> false </isdeleted> </NS1: accountbean> </out> </getuseraccountarrresponse> </soap: Body> </soap: envelope> now there is a layer of arrayofaccountbean tag behind the out, in fact, this is caused by the modification just now, and neither xfire nor axis2 can parse this type of return. For some reason, if an array is returned as a result, it does not need to be encapsulated by another layer, but the attribute of other objects must be copied to the object, therefore, the attribute name must be used as the peripheral tag. Therefore, the server needs to be modified again and the judgment should be made when the returned array is encapsulated and returned. If the returned array is returned as an array result, it does not need to be encapsulated again. If it is returned as an object attribute, you need to encapsulate it again. After the server is adjusted, a full unit test is conducted. Everything is normal. Post: due to the prevalence of SOA, Web Service is becoming more and more widely used as a technical solution for SOA. Although the standards of soap messages and WSDL are both normative definitions, however, the detailed implementation is involved. Different framework developers and developers in different languages have different understandings, with a slight misunderstanding, different clients and servers of the same Protocol cannot be compatible with each other. This type of problem is common in the communication industry. The compatibility of mobile phones on different terminals is often the biggest headache for value-added service developers. The Details determine success or failure, and the cross-platform process is still long.
