三．平臺跨的不容易
本來這部分內(nèi)容應(yīng)該作為很后面的內(nèi)容，但是由于工作已經(jīng)作了，也總結(jié)了，那么就先寫下來貼一下，也算是個分享吧，這部分內(nèi)容在網(wǎng)上找了很久都沒有，所以也算是不錯的一個實踐。
ISV有幾家接了上來，有用PHP的，有.net的，這時候ASF框架的WebService繼功能測試，性能測試，安全性測試進(jìn)入了一個新的測試階段，兼容性測試。由于ISV的技術(shù)力量參差不齊，所以我們需要包辦實現(xiàn)所有語言的客戶端調(diào)用Demo的工作，因此對我這個做ASF的人來說，又要懂得各個語言的客戶端調(diào)用以及配置，幸好還有一個ISV Support部門也做一些這樣的工作，但是由于都是新手，也沒有太多的指望。
WebService之所以能夠被認(rèn)為是SOA最行之有效的技術(shù)手段，主要還是因為其通過wsdl規(guī)范以xml作為數(shù)據(jù)和操作請求描述的載體，基于SOAP協(xié)議在http或者smtp上傳輸，實現(xiàn)業(yè)務(wù)邏輯交互與實現(xiàn)語言及平臺的無關(guān)性，達(dá)到跨平臺交互的效果。然而作為協(xié)議，往往來說是制定了規(guī)范性的框架，但是框架內(nèi)的細(xì)節(jié)實現(xiàn)，不同的廠商，平臺，開發(fā)語言，開源框架都會有不同的實現(xiàn)方式，因此也造成了WebService客戶端解析Soap數(shù)據(jù)包兼容性的問題。這個問題在普通的接口中不容易出現(xiàn)，只是在調(diào)用接口返回數(shù)據(jù)類型為對象數(shù)組的時候出現(xiàn)。
首先出現(xiàn)在Java平臺的兩個比較通用的開源WebService框架上：axis2,xfire。（cxf暫時還沒有去做測試）。現(xiàn)象：axis2和xfire的兩種客戶端都無法正常解析ASF返回的數(shù)組對象。例如返回的是Account對象，Account有id，name，value三個屬性。模擬返回2個Account對象，結(jié)果axis2客戶端獲得一個數(shù)組，內(nèi)部有一個Account對象，不過三個屬性都是沒有被初始化。xfire客戶端獲得一個數(shù)組，內(nèi)部有兩個Account對象，同樣屬性都沒有被初始化。跟蹤兩個客戶端源碼并結(jié)合返回的Soap消息分析，得到了問題的原因。
SOAP返回的包體如下：
<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>
先來解釋Axis2的問題，Axis2客戶端在解析此包體的時候，首先檢查return標(biāo)簽，然后根據(jù)wsdl中的描述確認(rèn)內(nèi)部數(shù)組對象類型為Account，然后循環(huán)獲取結(jié)果集構(gòu)造對象，但是按照axis2的內(nèi)部邏輯處理正常的情況，應(yīng)該沒有Account這層標(biāo)簽，直接是多個結(jié)構(gòu)體組裝而成，由于多了Account這層外圍標(biāo)簽，導(dǎo)致解析第一個對象就出現(xiàn)問題，因此，就出現(xiàn)了上面描述的結(jié)果。此時有些懷疑是否是ASF框架在返回SOAP的時候沒有遵循WSDL的規(guī)范，但是沒有檢驗過xfire也不能確定是否是沒有符合規(guī)范而造成的。
在來解釋一下XFire客戶端調(diào)用問題的原因。同樣跟蹤了XFire的客戶端代碼，發(fā)現(xiàn)問題主要是出在最后給對象獲取屬性值的操作上。首先XFire客戶端啟動時會根據(jù)本地的接口包或者對象包路徑來反轉(zhuǎn)成為namingspace然后和屬性名稱一起生成QName緩存在本地，作為屬性對象。然后當(dāng)獲得了返回SOAP消息包體的時候，根據(jù)這些QName去獲取屬性的內(nèi)容，但是可以從上面描述的SOAP返回的內(nèi)容來看，Account的namingspace丟失了，導(dǎo)致后面各個屬性的namingspace也都丟失了。看了一下ASF在返回SOAP的代碼，的卻在構(gòu)造SOAP返回包的時候無法獲得對象的namingspace，只有它的上級return類型有namingspace，那么如何解決呢，轉(zhuǎn)念一想，其實這也是一種規(guī)范，wsdl的生成工具大部分都遵循這種包反轉(zhuǎn)作為namingspace的策略，因此在構(gòu)造返回包體的時候采取了這個策略來填充SOAP包，XFire客戶端正常。（后話，萬一遇到一些和我一樣自己喜歡修改wsdl的人，那么xfire就未必能夠正常解析這類服務(wù)了）。從這兒也驗證了ASF對于WSDL的消息包返回規(guī)范是正確的，也就也證明了axis2客戶端的一個缺陷，因此在java平臺暫時不建議客戶使用axis2，同時axis2的客戶端友好度遠(yuǎn)遠(yuǎn)低于xfire，不過axis2的優(yōu)勢在于配置靈活以及可插入性（這也是ASF為什么集成axis2作為默認(rèn)的webservice發(fā)布框架的原因，后續(xù)blog會回顧其他幾個測試的歷程）
這還是開始，由于都是開源框架，所以調(diào)試和檢測相對來說還比較方便。接著測試部就提出在用.net客戶端調(diào)用返回對象數(shù)組出現(xiàn)問題，問題和XFire最早一樣。當(dāng)時我就很肯定地就是應(yīng)該問題出在解析那些屬性上。說實話，第一次接觸.net，什么都不會，裝了個vs 2005就開始搗鼓，不過.net真是傻瓜工具，調(diào)用webservice相當(dāng)簡單，就只需要建立一個web reference，其中web reference就指向一個wsdl地址，那么.net就自動替你動態(tài)生成好client了，然后就像普通的對象調(diào)用一樣，直接可以操作此服務(wù)（不過ASF的webservice的發(fā)布和引用也已經(jīng)做的這么傻瓜了^_^）。簡單是把雙刃劍，容易上手，但是容易養(yǎng)成不求甚解的習(xí)慣，工作到現(xiàn)在，要不是開發(fā)框架，我根本不會去管wsdl中哪個元素是什么用處，工具生成好了，用就罷了，只要不出錯。懶倒還是一方面，最痛苦的莫過于沒有辦法看到源碼，只能黑盒測試以及猜測，這時候我覺得java真是好。還問了一個以前的高手朋友，他做了6，7年的java然后轉(zhuǎn)到.net上，我說怎么跟蹤.net的源碼，他和我說：“據(jù)說.net快要開放源碼了”。#_#|| 我回了一句：“我基本上等不到那天了。”言歸正傳，下面是如何分析.net問題的報告。
Java&.Net WebService兼容問題
Java發(fā)布的webservice 在.net客戶端調(diào)用的時，數(shù)組對象類型返回兼容問題。
問題描述：
Java發(fā)布的WebService在Java客戶端調(diào)用下都是正常的，但是在.net的客戶端調(diào)用下，如果返回的類型是數(shù)組對象類型，那么就會發(fā)現(xiàn)得到了數(shù)組，并且數(shù)組內(nèi)部對象生成，但是對象內(nèi)部的屬性值無法獲得。
問題分析：
在wsdl中定義數(shù)組對象類型返回有兩種方式：
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>
配置一的情況：
有兩種場景出現(xiàn)：
場景一：
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,double fee);
public void delAccount(Account account,String name);
public int checkUser(String accountId,String accountId1);
}
其中接口中所有的返回或者參數(shù)對象都和接口定義在同一個包體內(nèi)，這樣生成wsdl的時候xsd的schema就只有一份，那么.net的客戶端數(shù)組對象返回問題不存在。
場景二：
public interface IAccountService
{
public AccountBean checkUserAccount(String accountId) throws InvocationTargetException;
public AccountBean[] getUserAccountList(String accountIdBeg,String accountIdEnd);
public AccountBean[] getUserAccountArr(String accountIdBeg);
public Account[] getUserAccountArr2(String accountIdBeg);
public double payForAppOrder(AccountBean account,double fee);
public void delAccount(AccountBean account,String name);
public int checkUser(String accountId,String accountId1);
}
接口中的返回對象和接口不在一個包內(nèi)，那么生成的xsd的schema就有多個，那么.net的客戶端調(diào)用java發(fā)布的webservice就存在前面描述的問題。
因此用同樣的wsdl分別用.net和java發(fā)布，通過.net客戶端去調(diào)用，前者不存在問題，后者有問題，截獲soap相應(yīng)報文如下：
java 返回的soap包：
<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>
<accountBalance>100.23</accountBalance>
</Account>
<Account>
<accountId>111</accountId>
<isDeleted>false</isDeleted>
<accountBalance>111.23</accountBalance>
</Account>
</return>
</_ns_:getUserAccountArr2Response>
</soapenv:Body>
</soapenv:Envelope>
.net返回的soap包：
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/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>
<return>
<accountBalance>12.12</accountBalance>
<accountId>11</accountId>
<isDeleted xsi:nil="true"/>
</return>
</getUserAccountArr2Response>
</soap:Body>
</soap:Envelope>
但就作為wsdl中定義的話，return只有一個內(nèi)容就是Account數(shù)組，java的定義應(yīng)該比較符合定義內(nèi)容。
部分結(jié)論：
也就是說在第一種配置情況下，wsdl中包含一個xsd的schema，.net客戶端不存在任何問題。wsdl中存在多個schema的情況下，數(shù)組對象無法構(gòu)造成功，但是對于單個對象返回可以正常解析。
解決方案：
1.修改服務(wù)框架服務(wù)端代碼適應(yīng).net客戶端（不可行，會導(dǎo)致java的出現(xiàn)問題）
2.將這種特殊接口的schema中定義的類都放在一個包里（覺得不是很合適）
3.把對象都序列化然后作為結(jié)果返回，個人感覺性能比較低，不過可以真的減小跨平臺的問題。
配置二的情況：
不存在客戶端調(diào)用的構(gòu)造問題，不過需要改造客戶端代碼（其實就是獲得了xml的數(shù)據(jù)片斷，自己去解析xml的數(shù)據(jù)來構(gòu)造客戶端對象）。此類方法在網(wǎng)上也很通用，可以參看www.salesforce.com提供給第三方的API接口介紹，就是類似的。
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(loopCounter++) + " - ");
//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 if 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();
}
}
此時，我們的客戶端代碼修改成為：
原來的代碼：
jdk2Service.AccountService service5 = new jdk2Service.AccountService();
jdk2Service.Account[] re = service5.getUserAccountArr("demo");
jdk2Service.Account re2 = service5.checkUserAccount("test");
現(xiàn)在的代碼：
jdkService.AccountService service3 = new jdkService.AccountService();
jdkService.ArrayOfAccountBean res = service3.getUserAccountArr("tea");
string name = res.Any[0].FirstChild.InnerText;//獲取了第一個返回對象的第一個屬性值。
這種模式比較通用在現(xiàn)在的跨平臺的客戶端調(diào)用webservice。
因此考慮AEP接口改造成為這種方式，同時可以給客戶封裝類似的構(gòu)造函數(shù)庫提供給客戶使用。
結(jié)束語：
這個報告發(fā)給了我們的架構(gòu)師們以及相關(guān)人員，晚上下班到家，收到了老大的郵件，讓我們總架構(gòu)師向微軟提出這個問題，看是否真的是這樣的情況，能否有好的方法解決。這讓我想起了前一陣子誰說的一句話：“有多少人打過微軟的客戶服務(wù)電話反映過情況”。赫赫，我們這就算是反映了，效果么……，覺得求人不如求己，開源好啊^_^
更多的內(nèi)容請訪問我的blog：http://blog.csdn.net/cenwenchu79