TCP/IP、HTTP、WEBSERVICE、SOAP、ICE都使用后才有感慨

TCP是TCP/IP的第三層傳輸層，對應OSI的第四層傳輸層；
IP是TCP/IP的第二層互聯(lián)層，對應OSI的第三層網(wǎng)絡層。

ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中間件，基于ICE可以實現(xiàn)電信級的解決方案。前面我們提到過在設(shè)計網(wǎng)站架構(gòu)的時候可以使用ICE實現(xiàn)對網(wǎng)站應用的基礎(chǔ)對象操作，將基礎(chǔ)對象操作和數(shù)據(jù)庫操作封裝在這一層，在業(yè)務邏輯層以及表現(xiàn)層(java,php,.net,python)進行更豐富的表現(xiàn)與操作，從而實現(xiàn)比較好的架構(gòu)?；贗CE的數(shù)據(jù)層可以在未來方便的進行擴展。ICE支持分布式的部署管理，消息中間件，以及網(wǎng)格計算等等。 

大道理講完，言歸正傳，最近育兒網(wǎng)新增了不少新服務，服務間經(jīng)常會需要相互調(diào)用數(shù)據(jù)，例如用戶中心要取博客系統(tǒng)里的文章啊，論壇里發(fā)文后要在積分系統(tǒng)里增加用戶積分啊。由于設(shè)計時這些服務僅僅基于統(tǒng)一的用戶中心，服務間基本是獨立的，所以要實現(xiàn)這些調(diào)用只能在每個服務上新增為其它服務提供服務的服務-_-!。這個時候有幾個可選方案，我們開始選擇了xml-rpc，基于http和xml的選程調(diào)用，用了一段時間，發(fā)現(xiàn)維護成本和訪問性能都存在問題。 

由于這些中間服務部署的時候是和各自所屬的服務部署在一起的，對這些服務做整體的改動就非常困難，要維護起來就比較麻煩。另外由于是什么http和xml作為通信協(xié)議，由php實現(xiàn)業(yè)務邏輯，性能問題也很明顯，而且這些http請求都會在http日志留下足跡，導致我們的日志分析很不精確。這個問題不是太大，但很郁悶，所以我們考慮使用ICE來解決這個問題，至于SOAP什么的就不考慮了，同樣效率低下。 

實現(xiàn)的過程還是比較順利，花了三天的時間用c++實現(xiàn)了大部分常用的接口，服務端采用deamon的方式運行，錯誤日志記在syslog里(/var/log/messages)，客戶端PHP，編譯進去了IcePHP，調(diào)用的方法很簡單。現(xiàn)在還存在一些問題，運行的時候會異常退出，還需要一段時間來解決，暫時加了只狗看著，一旦進程里沒了就重新啟動。 

既然要跨平臺通訊，就涉及對象描述，ICE使用Slice來對結(jié)構(gòu)，類，方法等進行定義。完了以后服務器端，客戶端都按這個來調(diào)用和實現(xiàn)。ICE內(nèi)置的Linux 下后臺Deamon實現(xiàn)方案非常簡單，只需要從Ice::Service里派生出一個類來，實現(xiàn)run方法，在這個方法里創(chuàng)建adapter對象，并在adapter對象里添加Servants，然后激活這個adapter就可以了，網(wǎng)絡層的通信都由ICE接管了。由于是基于tcp/ip的直接通信，比更高層的http通信效率要高很多。 

在客戶端實現(xiàn)時，我們也碰到了一些小麻煩。一個是內(nèi)置的$ICE對象用的時候有時需要用global聲明，否則可能會出錯，另外由于默認情況下Slice中struct對應到php的類型是一個類的實例，而不是一個數(shù)組，所以在賦值給頁面的時候，smarttemplate以及其它模板系統(tǒng)中可能都會存在問題，可以通過修改模板系統(tǒng)的數(shù)據(jù)賦值顯示代碼解決。 

我們做了一些性能的測試，同樣運行1千次請求，使用xml-rpc實現(xiàn)需要28秒左右，使用ICE實現(xiàn)，只需要3秒多，性能的差距還是很大的，同時在這個過程中沒發(fā)現(xiàn)有內(nèi)存泄露的情況，效果還比較理想。 
//////////////////

WEBSERVICE   所遵循的SOAP協(xié)議 是建立在HTTP協(xié)議之上的協(xié)議 

簡單對象訪問協(xié)議（SOAP）是W3C組織的一個Note, 它描述了一種在分散的或分布式的環(huán)境中如何交換信息的輕量級協(xié)議。SOAP是一個基于XML的協(xié)議，它包括三個部分：SOAP封裝(Envelop)，封裝定義了一個描述消息中的內(nèi)容是什么，是誰發(fā)送的，誰應當接受并處理它以及如何處理它們的框架；SOAP編碼規(guī)則（Encoding Rules），用于表示應用程序需要使用的數(shù)據(jù)類型的實例；SOAP RPC表示(RPC Representation)，表示遠程過程調(diào)用和應答的協(xié)定；SOAP可以和多種傳輸協(xié)議綁定（Binding），使用底層協(xié)議交換信息。在這個文檔中，目前只定義了SOAP如何和HTTP以及HTTP擴展進行綁定的框架。

SOAP是個通信協(xié)議， SOAP在HTTP協(xié)議的基礎(chǔ)上，把編寫成XML的REQUEST參數(shù), 放在HTTP BODY上提交個WEB SERVICE服務器(SERVLET，ASP什么的) 處理完成后，結(jié)果也寫成XML作為RESPONSE送回用戶端， 為了使用戶端和WEB SERVICE可以相互對應，可以使用WSDL作為這種通信方式的描述文件，利用WSDL工具可以自動生成WS和用戶端的框架文件，SOAP具備把復雜對象序列化捆綁到XML里去的能力。

SOAP的前身是RPC, 就是遠程呼叫處理的協(xié)議，這個協(xié)議安全性不是很好，多數(shù)防火墻都會阻擋RPC的通信包，而SOAP則使用HTTP協(xié)議作為基本的協(xié)議，使用端口80使得SOAP可以透過防火墻，完成RPC的功能。

SOAP協(xié)議和HTTP協(xié)議一樣，都是底層的通信協(xié)議，只是請求包的格式不同而已，SOAP包是XML格式的，現(xiàn)在我們編寫WEB SERVICE不需要深入理解SOAP也沒關(guān)系。如果SERVICE和CLIENT在同樣的環(huán)境下使用SOAP，由于一般情況下都有自動生成SOAP程序框架的工具，因此不知道細節(jié)也沒關(guān)系. 可是, 如果CLIENT和SERVICE的環(huán)境不同，比如說JAVA的Client和.NET的SERVICE進行通信，或者是VB CLIENT和TOMCAT下的JAVA SERVICE通信，還是要知道一點細節(jié)為好. 特別是, WSDL或者UDDI都不是標準，如果不讓用就只好手工配制SOAP MESSAGE啦。