放翁（文初）的一畝三分地

 

三．平臺跨的不容易

       本來這部分內(nèi)容應(yīng)該作為很后面的內(nèi)容，但是由于工作已經(jīng)作了，也總結(jié)了，那么就先寫下來貼一下，也算是個(gè)分享吧，這部分內(nèi)容在網(wǎng)上找了很久都沒有，所以也算是不錯(cuò)的一個(gè)實(shí)踐。

       ISV有幾家接了上來，有用PHP的，有.net的，這時(shí)候ASF框架的WebService繼功能測試，性能測試，安全性測試進(jìn)入了一個(gè)新的測試階段，兼容性測試。由于ISV的技術(shù)力量參差不齊，所以我們需要包辦實(shí)現(xiàn)所有語言的客戶端調(diào)用Demo的工作，因此對我這個(gè)做ASF的人來說，又要懂得各個(gè)語言的客戶端調(diào)用以及配置，幸好還有一個(gè)ISV Support部門也做一些這樣的工作，但是由于都是新手，也沒有太多的指望。

       WebService之所以能夠被認(rèn)為是SOA最行之有效的技術(shù)手段，主要還是因?yàn)槠渫ㄟ^wsdl規(guī)范以xml作為數(shù)據(jù)和操作請求描述的載體，基于SOAP協(xié)議在http或者smtp上傳輸，實(shí)現(xiàn)業(yè)務(wù)邏輯交互與實(shí)現(xiàn)語言及平臺的無關(guān)性，達(dá)到跨平臺交互的效果。然而作為協(xié)議，往往來說是制定了規(guī)范性的框架，但是框架內(nèi)的細(xì)節(jié)實(shí)現(xiàn)，不同的廠商，平臺，開發(fā)語言，開源框架都會(huì)有不同的實(shí)現(xiàn)方式，因此也造成了WebService客戶端解析Soap數(shù)據(jù)包兼容性的問題。這個(gè)問題在普通的接口中不容易出現(xiàn)，只是在調(diào)用接口返回?cái)?shù)據(jù)類型為對象數(shù)組的時(shí)候出現(xiàn)。

首先出現(xiàn)在Java平臺的兩個(gè)比較通用的開源WebService框架上：axis2,xfire。（cxf暫時(shí)還沒有去做測試）。現(xiàn)象：axis2和xfire的兩種客戶端都無法正常解析ASF返回的數(shù)組對象。例如返回的是Account對象，Account有id，name，value三個(gè)屬性。模擬返回2個(gè)Account對象，結(jié)果axis2客戶端獲得一個(gè)數(shù)組，內(nèi)部有一個(gè)Account對象，不過三個(gè)屬性都是沒有被初始化。xfire客戶端獲得一個(gè)數(shù)組，內(nèi)部有兩個(gè)Account對象，同樣屬性都沒有被初始化。跟蹤兩個(gè)客戶端源碼并結(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客戶端在解析此包體的時(shí)候，首先檢查return標(biāo)簽，然后根據(jù)wsdl中的描述確認(rèn)內(nèi)部數(shù)組對象類型為Account，然后循環(huán)獲取結(jié)果集構(gòu)造對象，但是按照axis2的內(nèi)部邏輯處理正常的情況，應(yīng)該沒有Account這層標(biāo)簽，直接是多個(gè)結(jié)構(gòu)體組裝而成，由于多了Account這層外圍標(biāo)簽，導(dǎo)致解析第一個(gè)對象就出現(xiàn)問題，因此，就出現(xiàn)了上面描述的結(jié)果。此時(shí)有些懷疑是否是ASF框架在返回SOAP的時(shí)候沒有遵循WSDL的規(guī)范，但是沒有檢驗(yàn)過xfire也不能確定是否是沒有符合規(guī)范而造成的。

在來解釋一下XFire客戶端調(diào)用問題的原因。同樣跟蹤了XFire的客戶端代碼，發(fā)現(xiàn)問題主要是出在最后給對象獲取屬性值的操作上。首先XFire客戶端啟動(dòng)時(shí)會(huì)根據(jù)本地的接口包或者對象包路徑來反轉(zhuǎn)成為namingspace然后和屬性名稱一起生成QName緩存在本地，作為屬性對象。然后當(dāng)獲得了返回SOAP消息包體的時(shí)候，根據(jù)這些QName去獲取屬性的內(nèi)容，但是可以從上面描述的SOAP返回的內(nèi)容來看，Account的namingspace丟失了，導(dǎo)致后面各個(gè)屬性的namingspace也都丟失了。看了一下ASF在返回SOAP的代碼，的卻在構(gòu)造SOAP返回包的時(shí)候無法獲得對象的namingspace，只有它的上級return類型有namingspace，那么如何解決呢，轉(zhuǎn)念一想，其實(shí)這也是一種規(guī)范，wsdl的生成工具大部分都遵循這種包反轉(zhuǎn)作為namingspace的策略，因此在構(gòu)造返回包體的時(shí)候采取了這個(gè)策略來填充SOAP包，XFire客戶端正常。（后話，萬一遇到一些和我一樣自己喜歡修改wsdl的人，那么xfire就未必能夠正常解析這類服務(wù)了）。從這兒也驗(yàn)證了ASF對于WSDL的消息包返回規(guī)范是正確的，也就也證明了axis2客戶端的一個(gè)缺陷，因此在java平臺暫時(shí)不建議客戶使用axis2，同時(shí)axis2的客戶端友好度遠(yuǎn)遠(yuǎn)低于xfire，不過axis2的優(yōu)勢在于配置靈活以及可插入性（這也是ASF為什么集成axis2作為默認(rèn)的webservice發(fā)布框架的原因，后續(xù)blog會(huì)回顧其他幾個(gè)測試的歷程）

這還是開始，由于都是開源框架，所以調(diào)試和檢測相對來說還比較方便。接著測試部就提出在用.net客戶端調(diào)用返回對象數(shù)組出現(xiàn)問題，問題和XFire最早一樣。當(dāng)時(shí)我就很肯定地就是應(yīng)該問題出在解析那些屬性上。說實(shí)話，第一次接觸.net，什么都不會(huì)，裝了個(gè)vs 2005就開始搗鼓，不過.net真是傻瓜工具，調(diào)用webservice相當(dāng)簡單，就只需要建立一個(gè)web reference，其中web reference就指向一個(gè)wsdl地址，那么.net就自動(dòng)替你動(dòng)態(tài)生成好client了，然后就像普通的對象調(diào)用一樣，直接可以操作此服務(wù)（不過ASF的webservice的發(fā)布和引用也已經(jīng)做的這么傻瓜了^_^）。簡單是把雙刃劍，容易上手，但是容易養(yǎng)成不求甚解的習(xí)慣，工作到現(xiàn)在，要不是開發(fā)框架，我根本不會(huì)去管wsdl中哪個(gè)元素是什么用處，工具生成好了，用就罷了，只要不出錯(cuò)。懶倒還是一方面，最痛苦的莫過于沒有辦法看到源碼，只能黑盒測試以及猜測，這時(shí)候我覺得java真是好。還問了一個(gè)以前的高手朋友，他做了6，7年的java然后轉(zhuǎn)到.net上，我說怎么跟蹤.net的源碼，他和我說：“據(jù)說.net快要開放源碼了”。#_#|| 我回了一句：“我基本上等不到那天了。”言歸正傳，下面是如何分析.net問題的報(bào)告。

Java&.Net WebService兼容問題

Java發(fā)布的webservice 在.net客戶端調(diào)用的時(shí)，數(shù)組對象類型返回兼容問題。

問題描述：

Java發(fā)布的WebService在Java客戶端調(diào)用下都是正常的，但是在.net的客戶端調(diào)用下，如果返回的類型是數(shù)組對象類型，那么就會(huì)發(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ù)對象都和接口定義在同一個(gè)包體內(nèi)，這樣生成wsdl的時(shí)候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);

}

接口中的返回對象和接口不在一個(gè)包內(nèi)，那么生成的xsd的schema就有多個(gè)，那么.net的客戶端調(diào)用java發(fā)布的webservice就存在前面描述的問題。

因此用同樣的wsdl分別用.net和java發(fā)布，通過.net客戶端去調(diào)用，前者不存在問題，后者有問題，截獲soap相應(yīng)報(bào)文如下：

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只有一個(gè)內(nèi)容就是Account數(shù)組，java的定義應(yīng)該比較符合定義內(nèi)容。

部分結(jié)論：

也就是說在第一種配置情況下，wsdl中包含一個(gè)xsd的schema，.net客戶端不存在任何問題。wsdl中存在多個(gè)schema的情況下，數(shù)組對象無法構(gòu)造成功，但是對于單個(gè)對象返回可以正常解析。

解決方案：

1.修改服務(wù)框架服務(wù)端代碼適應(yīng).net客戶端（不可行，會(huì)導(dǎo)致java的出現(xiàn)問題）

2.將這種特殊接口的schema中定義的類都放在一個(gè)包里（覺得不是很合適）

3.把對象都序列化然后作為結(jié)果返回，個(gè)人感覺性能比較低，不過可以真的減小跨平臺的問題。

配置二的情況：

       不存在客戶端調(diào)用的構(gòu)造問題，不過需要改造客戶端代碼（其實(shí)就是獲得了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();

 } 

}

此時(shí)，我們的客戶端代碼修改成為：

原來的代碼：

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;//獲取了第一個(gè)返回對象的第一個(gè)屬性值。

這種模式比較通用在現(xiàn)在的跨平臺的客戶端調(diào)用webservice。

因此考慮AEP接口改造成為這種方式，同時(shí)可以給客戶封裝類似的構(gòu)造函數(shù)庫提供給客戶使用。

結(jié)束語：

       這個(gè)報(bào)告發(fā)給了我們的架構(gòu)師們以及相關(guān)人員，晚上下班到家，收到了老大的郵件，讓我們總架構(gòu)師向微軟提出這個(gè)問題，看是否真的是這樣的情況，能否有好的方法解決。這讓我想起了前一陣子誰說的一句話：“有多少人打過微軟的客戶服務(wù)電話反映過情況”。赫赫，我們這就算是反映了，效果么……，覺得求人不如求己，開源好啊^_^

更多的內(nèi)容請?jiān)L問我的blog：http://blog.csdn.net/cenwenchu79

 

       每個(gè)人在人生的不同階段都在成長，父母們?yōu)樽约河涗浟诉^去的成長歷程，自己也在成年以后記錄著自己的成長歷程。程序員或者架構(gòu)師都有著自己的“孩子”，不論自己的孩子是好是壞，都為自己的孩子有一點(diǎn)成績而激動(dòng)不已。現(xiàn)在的我也正在培育著一個(gè)自己的“孩子”，雖然在它成長過程中我要付出很多，但是看著它的成長，讓我覺得所有的付出都是值得的。因此通過這種方式，記錄下它的成長，記錄下遇到的種種困難和解決之道，為自己也為其他程序員架構(gòu)師在培育“孩子”的過程中提供可能有幫助的一些信息。

一．初涉SCA

       阿里新子公司成立，我也從業(yè)務(wù)開發(fā)組調(diào)動(dòng)到了平臺架構(gòu)組，平臺架構(gòu)組當(dāng)時(shí)的職責(zé)就是完善XPlatform來支持多個(gè)業(yè)務(wù)產(chǎn)品線部門的業(yè)務(wù)開發(fā)，XPlatform是基于MDA理念的快速開發(fā)平臺。但隨著業(yè)務(wù)部門開發(fā)靈活性要求的日益增加，XPlatform在可定制化，模塊化就日漸暴露出了不足。在4月份的技術(shù)戰(zhàn)略調(diào)整以后，開始了翻天覆地的XPlatform重構(gòu)計(jì)劃，而我就被分配負(fù)責(zé)考慮底層架構(gòu)重構(gòu)以及服務(wù)框架的設(shè)計(jì)。

       當(dāng)時(shí)首先考慮模塊化重構(gòu)底層的時(shí)候，感覺OSGI是一個(gè)很好的方向，因此在重構(gòu)服務(wù)框架前期的Cache模塊時(shí)候采用了OSGI策略，可以動(dòng)態(tài)替換Cache，但是在使用的過程中發(fā)現(xiàn)，此模塊化并非我們所需的模塊化。OSGI的模塊化比較徹底，就連每個(gè)Bundle的dependency都是自己維護(hù)和管理，這樣對于動(dòng)態(tài)載入和卸載提供了堅(jiān)實(shí)的基礎(chǔ)，但同時(shí)也為它提供了最難處理的一個(gè)問題：復(fù)雜的ClassLoader機(jī)制。而回顧當(dāng)前的業(yè)務(wù)開發(fā)場景，是否真的有這樣強(qiáng)模塊隔離的需求，回答往往是否定的。而作為動(dòng)態(tài)的載入和卸載，的確是很好的一種特性，但是作為商業(yè)化的產(chǎn)品，特別是現(xiàn)在的互聯(lián)網(wǎng)應(yīng)用，機(jī)群中部署的應(yīng)用模塊往往來說并不需要單獨(dú)裝載和部署。另一方面來看OSGI面向的主要是對于單機(jī)服務(wù)開發(fā)模塊化的解決方案，并非SOA的解決方案，而當(dāng)前互聯(lián)網(wǎng)應(yīng)用在很大程度上需要互聯(lián)互通，模塊化是基礎(chǔ)，但是并非最終的解決手段。

       這時(shí)候開始關(guān)注與SCA，對于SOA具體實(shí)施的一種實(shí)踐性的規(guī)范，規(guī)范本身的模塊化可擴(kuò)展性給我留下了很深的印象。SCA和OSGI在模塊化思想上有很多類似的地方，在SCA中Composite就是Bundle虛擬體，而SCA的優(yōu)點(diǎn)就在于它只是規(guī)范，只是一種設(shè)計(jì)思想，不約束實(shí)現(xiàn)語言，平臺以及其它細(xì)節(jié)，這也是互聯(lián)網(wǎng)應(yīng)用的一種趨勢。信息共享達(dá)到信息價(jià)值最大化，這是企業(yè)應(yīng)用的目標(biāo)，在實(shí)現(xiàn)這個(gè)目標(biāo)的時(shí)候需要拋開實(shí)現(xiàn)過程中的細(xì)節(jié)。就好比程序員往往關(guān)注的是使用什么好的技術(shù)能夠開發(fā)出最炫的應(yīng)用，而老板關(guān)注的是如何在最短最快的情況下滿足用戶需求，兩者之間如何能達(dá)成雙贏，那么就是架構(gòu)師的職責(zé)了。

       既然認(rèn)定了SCA這條路，那么就開始走吧，第一步當(dāng)然是看規(guī)范，OSOA上關(guān)于SCA的規(guī)范十分詳盡。SCA規(guī)范雖然已經(jīng)有些年頭了，但是正式納入OSOA并且成為一個(gè)較為廣泛認(rèn)可的規(guī)范其實(shí)時(shí)間并不長，國外Sun,Bea都用一些類似的產(chǎn)品，但也沒有大規(guī)模推廣，而在Apache的孵化項(xiàng)目中Tuscany是SCA最出名的實(shí)踐開源項(xiàng)目，對于我來說當(dāng)然是加入開源大家庭。我在接觸Tuscany的時(shí)候，它還是0.9之前的milestone2，但到現(xiàn)在為止，短短的幾個(gè)月，已經(jīng)發(fā)布到了v1版本了，可見發(fā)展迅速。對于Tuscany的關(guān)注，我看見現(xiàn)在國內(nèi)也越來越多，Tuscany最大的特點(diǎn)就是它的架構(gòu)可擴(kuò)展性很強(qiáng)，這也是SCA規(guī)范所需要的架構(gòu)體系，要做到SCA的模塊化和擴(kuò)展性，必須有靈活的基礎(chǔ)架構(gòu)作為支撐。

       三下五除二，用Tuscany搭建了SCA規(guī)范中描述的幾個(gè)通用場景，簡單的java bean，spring的集成，異步回調(diào)，rmi遠(yuǎn)程調(diào)用等等，當(dāng)然遇到了不少問題，由于Tuscany本身也是孵化過程中，最大的問題就是相應(yīng)的文檔少，作為一個(gè)初學(xué)者，只能通過Demo了解大致的使用方式，遇到問題也就通過跟蹤它的代碼來學(xué)習(xí)，不過這個(gè)過程，讓我也對整個(gè)框架的體系架構(gòu)有所了解，就如大牛所說，真正的體系架構(gòu)是一個(gè)運(yùn)行期的概念，而非設(shè)計(jì)期的，設(shè)計(jì)期其實(shí)就是SCA規(guī)范本身，而運(yùn)行期的部分才是真正的體系架構(gòu)。

       預(yù)研終究是在做實(shí)驗(yàn)性的工作，是否能夠產(chǎn)品化，還需要實(shí)踐來檢驗(yàn)。XPlatform的重構(gòu)正式啟動(dòng)了，平臺架構(gòu)師們組織了一次內(nèi)部重構(gòu)技術(shù)方案討論會(huì)，我將前期的研究結(jié)果以及SCA的思想和實(shí)現(xiàn)都作了展示，同時(shí)結(jié)合我們重構(gòu)的目標(biāo)作了技術(shù)實(shí)施可行性介紹。與會(huì)的另外一個(gè)架構(gòu)師提出了使用Spring實(shí)現(xiàn)SOA的ESB模式的解決方案，經(jīng)過比較和討論最后我的計(jì)劃方案得到了肯定，但是我自己心里其實(shí)也沒有底，畢竟如果真的在XPlatform的體系架構(gòu)中實(shí)施SCA，那么將會(huì)波及各個(gè)產(chǎn)品線的底層架構(gòu)，如果后續(xù)出現(xiàn)無法修復(fù)的問題，那么這個(gè)責(zé)任可不小。同時(shí)在過去的那些年頭，EJB就是一個(gè)很好的反面例子，一個(gè)規(guī)范理念是重要的，但是實(shí)施環(huán)境是否合適也會(huì)決定成敗，SCA是否適合未來的阿里軟件技術(shù)方向，當(dāng)時(shí)的我沒有把握。最后我主動(dòng)提出降低風(fēng)險(xiǎn)的設(shè)計(jì)方案，平臺底層分成兩部分：基礎(chǔ)服務(wù)框架（BSF）和應(yīng)用服務(wù)框架（ASF），前者主要應(yīng)用于XPlatform內(nèi)部核心組件的插拔交互，后者應(yīng)用于上層應(yīng)用的組裝，發(fā)布，交互。

Alisoft-xplatform-core-service-framework這個(gè)就是服務(wù)框架項(xiàng)目的子工程目錄名，也是我的SCA之路的第一步。當(dāng)走出這第一步以后，就再也不能回頭了，常用老馬的一句話來激勵(lì)自己：我可能不是最聰明的人，也不是最努力的人，但是堅(jiān)持可能就讓我比別人成功。Tuscany為我開啟了SCA的實(shí)踐之路，但Tuscany并不是像看起來那么美，要走適合服務(wù)框架的SCA之路，難題才剛剛開始。