III. cross-platform interaction is not easy. This part of content should be very followed. However, since the work has been done and summarized, you should first write it down and paste it for sharing, this part of content has not been found online for a long time, so it is a good practice. Several ISVs have been connected. php is useful. at this time, the ASF Framework's WebService followed the functional test, performance test, Security Test into a new test phase, compatibility test. Because the technical strength of isV is uneven, we need to handle the tasks of calling the demo on clients in all languages. Therefore, for me as an ASF engineer, we need to understand the client calls and configurations in various languages. Fortunately, another isV Support Department has done some such work, but because they are new users, there is not much expectation. WebService can be considered the most effective technical means of SOA mainly because it uses XML as the carrier of data and request description through the WSDL specification, based on the SOAP protocol transmitted over HTTP or SMTP, business logic interaction and language and platform independence are achieved to achieve cross-platform interaction. However, as a protocol, it is often a normative framework, but the implementation of the details in the framework, different vendors, platforms, development languages, and open-source frameworks will have different implementation methods, therefore, the compatibility of soap data packets resolved by the WebService client is also caused. This problem is not easy in common interfaces, but occurs when the data type returned by the interface is an array of objects. First appeared in two common open-source WebService frameworks on the Java platform: axis2 and xfire. (Cxf has not been tested yet ). Symptom: neither the axis2 client nor the xfire client can parse the array objects returned by ASF. For example, the returned account object has three attributes: ID, name, and value. Two account objects are returned. The axis2 client obtains an array with an internal account object. However, all three attributes are not initialized. The xfire client obtains an array with two internal account objects. The same attributes are not initialized. Track the source code of the two clients and analyze the returned SOAP message to find out the cause of the problem. The returned soap package body is as follows: <soapenv: envelope xmlns: soapenv = "http://schemas.xmlsoap.org/soap/envelope/"> <soapenv: Body> <_ NS _: getuseraccountarr2response xmlns: _ NS _ = "http://webservice.asf.xplatform.alisoft.com"> <return xmlns = "http://webservice.asf.xplatform.alisoft.com"> <account xmlns = ""> <accountid> 11 </accountid> <isdeleted> false </isdeleted> <accountbalance> 100.23 </accountbalance> </account> <account xmlns = ""> <Accountid> 111 </accountid> <isdeleted> false </isdeleted> <accountbalance> 111.23 </accountbalance> </account> </return> </_ NS _: getuseraccountarr2response> </soapenv: Body> </soapenv: envelope> first explains the problem of axis2. When the axis2 client parses the package body, it first checks the return label, then confirm that the internal array object type is account according to the description in the WSDL, and then obtain the result set to construct the object cyclically. However, if the internal logic of axis2 is normal, there should be no account label, it is directly assembled by multiple structs. Because of the extra account peripheral tag, the first object will be resolved and the result described above will appear. At this time, some suspect that the ASF framework does not follow the WSDL specification when returning soap, but it has not been tested and cannot be determined whether it is caused by non-compliance. Let's explain the cause of the xfire client call problem. I also tracked the xfire client code and found that the problem mainly lies in the final operation to get the attribute value for the object. When the xfire client is started, it will be reversed to namingspace based on the Local interface package or object package path, and the QNAME will be generated together with the property name and cached locally as the property object. Then, when the returned SOAP message package is obtained, the attribute content is obtained based on these qnames. However, the namingspace of the account is lost according to the content returned by the soap described above, the namingspace of each attribute is also lost. After reading the code that ASF returns soap, it cannot obtain the namingspace of the object when constructing the soap return package. How can this problem be solved only when its superior return type has namingspace, in another thought, this is actually a specification. Most of the WSDL generation tools follow this kind of packet reversal policy as namingspace, therefore, when constructing the returned package body, this policy is used to fill the soap package. The xfire client is normal. (In the future, xfire may not be able to parse such services normally if I meet someone who I like to modify WSDL ). It has also been verified from here that ASF is correct for the WSDL message packet return specification, which also proves a defect of the axis2 client. Therefore, we do not recommend that you use axis2 on the Java platform for the time being, at the same time, the client friendliness of axis2 is much lower than that of xfire. However, the advantage of axis2 lies in flexible configuration and insertion. (This is why ASF integrates axis2 as the default WebService release framework, later, the blog will review the history of several other tests.) This is still the beginning. Because it is an open-source framework, debugging and detection are relatively convenient. Next, the test department proposed that an error occurred when calling the returned object array with the. NET client. The problem was the same as that of xfire. At that time, I was sure that the problem was resolved on those attributes. To be honest, the first contact. net, nothing can be done. When VS 2005 is installed, it starts to be a hit,. net is a dumb tool. It is quite simple to call WebService. You only need to create a web reference, where the Web reference points to a WSDL address. net automatically generates a client for you dynamically, and then, just like a common object call, you can directly operate on this service (however, the publishing and reference of ASF's WebService has been such a dumb ). Simple is a double-edged sword. It is easy to get started, but it is easy to get into the habit of not seeking for a thorough understanding. Now, if it wasn't for the development framework, I wouldn't care about which element in the WSDL is useful, and the tool has been generated, use it, as long as there is no error. On the one hand, the most painful thing is that there is no way to see the source code, only black box testing and speculation. At this time, I think Java is really good. I also asked a friend who was a master who made Java for 6 or 7 years and then switched. net. net source code, he and I said: "said. net is about to open source code ". #_# | I replied, "I have never waited for that day ." The following is a report on how to analyze. Net problems. Java &. Net WebService compatibility issues Java released when the. NET client calls WebService, the array Object Type Returns compatibility issues. Problem description: The WebService released by Java is normal under the Java client call, but in. net client calls, if the returned type is the array object type, then you will find the array, and the internal object of the array is generated, but the internal attribute value of the object cannot be obtained. Problem Analysis: There are two methods to define the array object type returned in WSDL: 1. <Xs: complextype name = "Account"> <Xs: sequence> <Xs: Element minoccurs = "0" name = "accountbalance" type = "XS: double "/> <Xs: Element minoccurs =" 0 "name =" accountid "nillable =" true "type =" XS: string "/> <Xs: element minoccurs = "0" name = "isdeleted" nillable = "true" type = "XS: string"/> </Xs: sequence> </Xs: complextype> <Xs: element name = "getuseraccountarrresponse"> <Xs: complextype> <Xs: sequence> <Xs: element maxoccurs = "unbounded" minoccurs = "0" name = "return" nillable = "true" type = "XSD: Account"/> </Xs: sequence> </Xs: complextype> </Xs: Element> 2. <Xs: element name = "getuseraccountarr2response"> <Xs: complextype> <Xs: sequence> <Xs: element minoccurs = "0" name = "return" nillable = "true" type = "XSD: arrayofaccount"/> </Xs: sequence> </Xs: complextype> </Xs: Element> <Xs: complextype name = "Account"> <Xs: sequence> <Xs: element minoccurs = "0" name = "accountbalance" type = "XS: Double"/> <Xs: element minoccurs = "0" name = "accountid" nillable = "true" type = "XS: string"/> <Xs: element minoccurs = "0" name = "isdeleted" nillable = "true" type = "XS: string"/> </Xs: sequence> </Xs: complextype> <Xs: complextype name = "arrayofaccount"> <Xs: complexcontent> <Xs: Restriction base = "soapenc: array"> <Xs: attribute ref = "soapenc: arraytype" WSDL: arraytype = "XSD: account []"> </Xs: attribute> </Xs: Restriction> </Xs: complexcontent> </Xs: complextype>
Configuration 1:There are two scenarios: Scenario 1: Public interface iaccountservice2 {public account checkuseraccount (string accountid); Public Account [] getuseraccountlist (string accountidbeg, string accountidend ); public Account [] getuseraccountarr (string accountidbeg); Public Account [] getuseraccountarr2 (string accountidbeg); Public double payforapporder (account Account account, Double Region); Public void delaccount (account Account account, string name); Public int checkuser (string accountid, string accountid1);} All the returned or parameter objects in the interface are defined in the same package as the interface, in this way, when the WSDL is generated, the XSD Schema has only one copy.. Net client array object returned problem does not exist. Scenario 2: public interface iaccountservice {public accountbean checkuseraccount (string accountid) throws invocationtargetexception; Public accountbean [] getuseraccountlist (string region, string accountidend); Public accountbean [] getuseraccountarr (string region ); public Account [] getuseraccountarr2 (string accountidbeg); Public double payforapporder (accountbean account, Double Region); Public void Delaccount (accountbean account, string name); Public int checkuser (string accountid, string accountid1);} The returned object and interface in the interface are not in the same package, there are multiple XSD schemas generated.. Net client to call the WebService released by Java. Therefore, use the same WSDL.. NET and Java are released through. net client to call, the former does not have a problem, the latter has a problem, the interception of the corresponding soap packet is as follows: Java returned soap package: <soapenv: envelope xmlns: soapenv = "http://schemas.xmlsoap.org/soap/envelope/"> <soapenv: body> <_ NS _: getuseraccountarr2response xmlns: _ NS _ = "http://webservice.asf.xplatform.alisoft.com"> <return xmlns = "http://webservice.asf.xplatform.alisoft.com"> <account> <accountid> 11 </accountid> <isdeleted> false </isdeleted> <accountbal Ance> 100.23 </accountbalance> </account> <accountid> 111 </accountid> <isdeleted> false </isdeleted> <accountbalance> 111.23 </accountbalance> </ account> </return> </_ NS _: getuseraccountarr2response> </soapenv: Body> </soapenv: envelope>. net returned soap package: <soap: envelope xmlns: Soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: XSD = "http://www.w3.o RG/2001/XMLSCHEMA "> <soap: body> <getuseraccountarr2response xmlns = "http://webservice.asf.xplatform.alisoft.com"> <return> <accountbalance> 12.12 </accountbalance> <accountid> 11 </accountid> <isdeleted xsi: nil = "true"/> </return> <accountbalance> 12.12 </accountbalance> <accountid> 11 </accountid> <isdeleted xsi: nil = "true"/> </return> </getuseraccountarr2response> </soap: Body> </soap: envelope> If it is defined in SDL, only one return content is the account array, and the Java definition should be consistent with the definition content. Conclusion: In the first configuration, the WSDL contains an XSD Schema, And the. NET client does not have any problems. If multiple schemas exist in the WSDL, the array object cannot be constructed successfully, but the returned results of a single object can be parsed normally. Solution: 1. modify the service framework server code to adapt.. Net client (which is not feasible and may cause Java problems) 2. put the classes defined in the schema of this special interface in a package (I think it is not suitable). 3. when all objects are serialized and returned as results, I personally feel that the performance is relatively low, but it can really reduce cross-platform problems.
Configuration 2:There is no constructor of client calls, but the client code needs to be transformed (in fact, the XML data segment is obtained, and the XML data is parsed to construct the client object ). This method is also widely used on the Internet. You can refer to the introduction of Apis provided by www.salesforce.com to third parties, which is similar. C # example private void querysample () {queryresult QR = NULL; binding. queryoptionsvalue = new sforce. queryoptions (); binding. queryoptionsvalue. batchsize = 250; binding. queryoptionsvalue. batchsizespecified = true; QR = binding. query ("select firstname, lastname from contact"); bool bcontinue = true; int loopcounter = 0; while (bcontinue) {console. writeline ("/nresults set" + convert. tostring (loopc Ounter ++) + "-"); // process the query results for (INT I = 0; I <QR. records. length; I ++) {sforce. sobject con = QR. records [I]; string fname = con. any [0]. innertext; string lname = con. any [1]. innertext; If (fname = NULL) console. writeline ("Contact" + (I + 1) + ":" + lname); else console. writeline ("Contact" + (I + 1) + ":" + fname + "" + lname);} // handle the loop + 1 problem by checking to see I F The most recent queryresult if (QR. done) bcontinue = false; else QR = binding. querymore (QR. querylocator);} console. writeline ("/nquery succesfully executed. "); console. write ("/nhit return to continue... "); console. readline () ;}} at this time, our client code is changed to: original code: jdk2service. accountservice service5 = new jdk2service. accountservice (); jdk2service. account [] Re = service5.getuseraccountarr ("Demo"); jdk2service. A Ccount re2 = service5.checkuseraccount ("test"); current Code: jdkservice. accountservice service3 = new jdkservice. accountservice (); jdkservice. arrayofaccountbean res = service3.getuseraccountarr ("tea"); string name = res. any [0]. firstchild. innertext; // gets the first attribute value of the first returned object.
This mode is more common in the current cross-platform client call
WebService
.
Therefore
AEP
The interface is transformed into this method, and similar constructor libraries can be encapsulated for customers to use.Conclusion: This report was sent to our architects and related personnel. They arrived home from work in the evening and received an email from the boss asking our chief architect to raise this question to Microsoft, check whether this is the case and whether there is a good solution. This reminds me of what I said a while ago: "How many people have called Microsoft's customer service to reflect the situation ". Khhe, we have reflected this. What is the effect ......, I think it is better to ask for people, open-source good ^_^ more content please visit my blog: http://blog.csdn.net/cenwenchu79
