nighty

    一般而言，我們平常接觸的大多數(shù)項(xiàng)目都應(yīng)該是單純使用B/S或是C/S，除非在特殊場(chǎng)合，否則比較少混合使用B/S，C/S架構(gòu)。首先說(shuō)一下對(duì)這二種架構(gòu)特點(diǎn)的一些個(gè)人理解。B/S應(yīng)該是目前很多項(xiàng)目都應(yīng)用的架構(gòu)，瀏覽器的方式使得用戶的使用十分方便，用戶可以何時(shí)何地通過(guò)Internet訪問(wèn)URL而進(jìn)行相應(yīng)的工作，升級(jí)維護(hù)也能比較集中，缺點(diǎn)就是瀏覽器的表現(xiàn)能力受限以及常常受非議的安全性問(wèn)題，如果軟件的應(yīng)用范圍區(qū)域不集中，而且用戶經(jīng)常變換地點(diǎn)進(jìn)行訪問(wèn)，那么這種架構(gòu)是非常適合的。C/S架構(gòu)的C端有非常強(qiáng)的處理能力，所以在交互表現(xiàn)和安全方面可以做得比瀏覽器強(qiáng)，但是缺點(diǎn)也是非常明顯的，安裝部署、升級(jí)維護(hù)、版本兼容都是比較頭大的事情，一般的適用場(chǎng)景是集中的辦公室場(chǎng)所，用戶使用范圍相對(duì)穩(wěn)定，以及一些對(duì)業(yè)務(wù)處理非常復(fù)雜的場(chǎng)合，為了降低服務(wù)器的負(fù)荷，同樣需要C模式的支持。
    以前接觸過(guò)的電信領(lǐng)域，就有過(guò)混合架構(gòu)的軟件。但是都是非常寵大，一直都對(duì)其實(shí)現(xiàn)方案比較感興趣，但是都沒(méi)有機(jī)會(huì)進(jìn)一步了解。最近搜索了一下相關(guān)的資料，總結(jié)一下混合應(yīng)用的一些想法（只針對(duì)Java方向）。
    ①混合架構(gòu)的問(wèn)題集中點(diǎn)。服務(wù)端共享，客戶端采用不同的表現(xiàn)方式，共享的應(yīng)該是業(yè)務(wù)層接口，持久層應(yīng)該是屏蔽的。應(yīng)用層的消息傳遞就是整個(gè)應(yīng)用的關(guān)鍵所在，雖然像Jakarta提供的httpClient這種模仿瀏覽器的組件，但是畢竟是模仿，在很多方面的功能還是缺失的。
    ②最傳統(tǒng)的方式是采用EJB做為服務(wù)，這個(gè)寵然大物容易讓人害怕，不過(guò)在分布式的系統(tǒng)中它還是有應(yīng)用優(yōu)勢(shì)的，像電信和金融這種行業(yè)應(yīng)用還是比較廣的，而且現(xiàn)成的中間件和應(yīng)用服務(wù)器商都比較多，像Oracel、BEA、IBM、Sun都有成熟的應(yīng)用產(chǎn)品，當(dāng)然開(kāi)發(fā)的成本和人力投入也是恐龍級(jí)數(shù)據(jù)的。
    ③有網(wǎng)友說(shuō)在C端直接訪問(wèn)數(shù)據(jù)庫(kù)，B/S結(jié)構(gòu)不變，也就是通過(guò)數(shù)據(jù)庫(kù)進(jìn)行共享。這種方式是不可取的，二個(gè)缺點(diǎn)：把服務(wù)器的業(yè)務(wù)邏輯搬到了C端上，嚴(yán)格上講是不安全的，升級(jí)維護(hù)也非常麻煩；并發(fā)控制的壓力都在數(shù)據(jù)庫(kù)上。
    ④采用RMI，這個(gè)老古董相信應(yīng)該很多人都不使用了，因?yàn)樗氖褂靡贿B串的手續(xù)，比如服務(wù)接口定義必須實(shí)現(xiàn)Remote接口，服務(wù)Server在實(shí)現(xiàn)時(shí)必須繼承UnicastRemoteobject類，必須使用rmic指令產(chǎn)生stub和skeleton等，設(shè)置上繁雜。
    ⑤Spring 遠(yuǎn)程服務(wù)。這個(gè)應(yīng)該說(shuō)是比較可取的，大家都比較喜歡輕量級(jí)的東西。就如第一點(diǎn)所說(shuō)的，通過(guò)遠(yuǎn)程服務(wù)，我們可以在客戶直接調(diào)用服務(wù)端的服務(wù)接口，就像本地調(diào)用一樣，Spring對(duì)遠(yuǎn)程服務(wù)提供了好幾種實(shí)現(xiàn)方案。
    ⑥WebService。適合異構(gòu)環(huán)境，但是WSDL的這種方式相對(duì)來(lái)說(shuō)會(huì)比較耗費(fèi)資料，因?yàn)闃?biāo)準(zhǔn)定義除了業(yè)務(wù)內(nèi)容外，還有許多另外的說(shuō)明內(nèi)容。
    Spring遠(yuǎn)程服務(wù)實(shí)現(xiàn)方案介紹：
    ⑴Spring + RMI。Spring把傳統(tǒng)的RMI方式的繁雜設(shè)置去掉，只要配置Bean文件就和定義服務(wù)接口可以。RMI的服務(wù)啟動(dòng)和管理都交給Spring來(lái)處理。RMI訪問(wèn)的缺點(diǎn)就是對(duì)防火墻的穿透力比較差。
    ⑵Spring + Caucho的Hessian、Burlap。Hessian使用Http將對(duì)象以中性的二進(jìn)制消息進(jìn)行傳送，而不像RMI使用Java的序列化格式（這種序列化是專制的，不是Sun提供的序列化機(jī)制），由于是二進(jìn)制消息，所以不受限于某種實(shí)現(xiàn)語(yǔ)言，傳輸時(shí)所需要的帶寬較小是其優(yōu)點(diǎn)。Burlap是以XML文件格式傳送對(duì)象，XML文件有較高可讀性，應(yīng)用程序只要能解釋XML就能接收消息，當(dāng)然也不限于某種語(yǔ)言，但是組裝XML和解釋XML都需要消耗資源，當(dāng)傳輸大數(shù)據(jù)時(shí)性能應(yīng)該存在問(wèn)題。
    ⑶Spring + Http Invoker。由于Hessian的序列化機(jī)制不是正統(tǒng)的Java序列化機(jī)制，所以當(dāng)遇到傳輸復(fù)雜的業(yè)務(wù)模型時(shí)，就會(huì)存在各種問(wèn)題，為此，Spring又提供了Http Invoker，同樣是使用Http傳送對(duì)象，而且是使用Java的序列化機(jī)制。相比RMI，Http對(duì)防火墻的穿透力要強(qiáng)。
    后來(lái)嘗試了最后的這種Http Invoker方式，是在Spring2.0版本下嘗試的，開(kāi)發(fā)非常簡(jiǎn)單，網(wǎng)上也有大量的資料介紹。應(yīng)該說(shuō)從這里入口可以做一些嘗試。目前遇到的一個(gè)項(xiàng)目就需要混合架構(gòu)，B/S采用Spring2 + Struts2 + Hiberntae3，瀏覽器只提供一些查詢功能和數(shù)據(jù)展現(xiàn)，C端采用Eclipse的RCP平臺(tái)，共享服務(wù)器的業(yè)務(wù)接口，調(diào)用就采用Http Invoker遠(yuǎn)程服務(wù)，復(fù)雜的業(yè)務(wù)功能都集中在C端上。