跨越防火牆的通訊
如果你的應用程式有成千上萬的使用者，而且他們都分布在世界各地，那麼客戶端和伺服器之間的通訊將是乙個棘手的問題。那是因為客戶端和伺服器之間通常都會有防火牆或者**伺服器。在這種情況下，你想使用dcom就不是那麼簡單了，而且，通常你也不願意把你的客戶端程式發布到如此龐大數量的每乙個使用者手中。於是，你最終選擇了用瀏覽器作為客戶端，寫下一堆asp頁面，把應用程式的中間層暴露給終端使用者。結果呢？運氣好的話，只是開發難度大了一些，運氣不好的話，就會得到乙個根本無法維護的應用程式。
想象一下你應該怎麼在你的應用程式裡面加入乙個新的頁面：你必須先建立好使用者介面（web頁面），以及在這個頁面後面，包含相應商業邏輯的中間層元件。這還不夠，你還要再建立至少乙個asp頁面，用來接受使用者輸入的資訊，呼叫中間層元件，把結果格式化為html形式，最後還要把"結果頁"送回瀏覽器。要是客戶端**不再如此依賴於html表單，客戶端的程式設計不就簡單多了嗎？還有，建立asp頁面的那一步可以省略掉嗎？
當然。如果你的中間層元件是web service的話，你完全可以從使用者介面直接呼叫中間層元件，從而省掉建立asp頁面的那一步。要呼叫web service，你可以直接使用microsoft soap toolkit或。net這樣的soap客戶端，也可以使用你自己開發的soap客戶端，然後把它和你的應用程式連線起來。這樣做，不僅可以縮短開發周期，還可以減少**的複雜度，並增強整個應用程式的可維護性。同時，你的應用程式也不再需要在每次呼叫中間層元件時，都跳轉到相應的"結果頁"了。
以我的經驗來看，在乙個使用者介面和中間層有較多互動的應用程式中，使用web service這種結構，可以輕鬆的節省花在使用者介面程式設計上的20%的開發時間。這樣做還有另乙個好處，就是你將得到乙個由web service組成的中間層，這一層是完全可以在應用程式整合或其他場合下被重用的。最後，通過web service把你的應用程式的邏輯和資料暴露出來，還可以讓其它平台上的客戶重用你的應用程式。
應用程式整合
企業級的應用程式開發者都知道，企業裡經常都要把用不同語言寫成的在不同平台上執行的各種程式整合起來，而這種整合將花費很大的開發的力量。你的應用程式經常都需要從執行在古老的ibm主機上的程式中獲取資料；或者再把資料傳送到主機或unix應用程式中去。即使是在同乙個平台上，不同的軟體廠商生產的各種軟體也常常需要整合起來。通過web service，應用程式可以用標準的方法把功能和資料暴露出來，供其它的應用程式使用。
例如，你有乙個訂單登入程式，用於登入從客戶來的新訂單，包括客戶資訊、發貨位址、數量、**和付款方式等資訊。同時，你還有乙個訂單執行程式，用於實際貨物傳送的管理。這兩個程式是來自不同軟體廠商的。乙份新訂單進來之後，訂單登入程式需要通知訂單執行程式傳送貨物。通過在訂單執行程式上面增加一層web service，訂單執行程式可以把"addorder"函式暴露出來。這樣，每當有新訂單到來時，訂單登入程式就可以呼叫這個函式來傳送貨物了。進而通過web service整合應用程式
b2b的整合
用web service整合應用程式，可以使你公司內部的商務處理更加自動化。但當交易跨越了你的**商和客戶，突破了公司的界線時又會怎麼樣呢？跨公司的商務交易整合通常叫做b2b整合。
web service是b2b整合成功的關鍵。通過web service，你的公司可以把關鍵的商務應用暴露給指定的**商和客戶。例如，把你的電子下單系統和電子發票系統暴露出來，你的客戶就可以以電子的方式向你傳送購貨訂單，而你的**商則可以以電子的方式把原料採購的發票傳送給你。當然，這並不是乙個新的概念：電子文件交換（edi）早就是這樣了。web service和edi之間的主要區別在於，web service的實現要比edi簡單得多，而且web service是執行在internet上的，在世界任何地方都可輕易實現，這樣其執行成本就相對較低。不過，web service並不像edi那樣，是文件交換或b2b整合的一套完整的解決方案。web service只是b2b整合的乙個關鍵部分，還需要許多其它的部分才能完成這個整合。
用web service來實現b2b整合的最大好處在於可以輕易實現互操作性。只要把你的商務邏輯暴露出來，成為web service，你就可以讓任何指定的合作夥伴輕鬆的呼叫你的商務邏輯，而不管他們的系統在什麼平台上執行，使用的是什麼開發語言。這樣就大大減少了花在b2b整合的上的時間和成本。這樣的低成本讓許多原本無法承受edi的投資成本的中小企業也能實現b2b整合。
軟體重用
軟體重用是乙個很大的主題，它有很多的形式和程度。最基本的形式是源**模組或者類一級的重用。另一種形式是二進位制形式的元件重用。當前，像**控制項或使用者介面控制項這樣的可重用軟體元件在市場上都占有很大的份額。但這類軟體的重用都有乙個很嚴重的限制：重用僅限於**，而資料不能被重用。原因在於你可以很輕易的發布元件甚至源**，但要發布資料就沒那麼容易了，除非那些資料都是不會經常變化的靜態資料。
用web service來整合各種應用中的功能，為使用者提供乙個統一的介面許多應用程式都會利用web service，把當前基於元件的應用程式結構擴充套件為元件和web service 的混合結構。你也可以在應用程式中使用第三方的web service 提供的功能。你還可以把你自己的應用程式的功能通過web service 提供給別人。所有這些情況下，你都可以重用**和**後面的資料。總之，web service 將是軟體重用的一種非常有力的形式。
什麼時候不應該使用web service
乙個對web service的完整介紹還應該包括什麼時候不該用web service.經過前面的介紹，我們知道了web service 在通過web進行互操作或遠端呼叫的時候是最有用的。不過，還有許多情況，web service根本不能給你帶來任何好處。
單機應用程式
目前，我們還有很多桌面應用程式是供商用和個人使用的。其中一些只需要與執行在本機上的其他程式通訊。在這種情況下，我們最好就不要再用web service ，只要用本地的api就可以了。com非常適合於在這種情況下工作，因為它既小又快。執行在一台伺服器上的伺服器軟體也是這樣：最好直接用com或其他本地的api來進行應用程式間的呼叫。當然web service 也能用在這些情況下，但那樣不僅消耗太大，而且不會給你帶來任何好處。
區域網上的同構應用程式
在許多應用中，你所有的程式都是用vb或vc開發的，都在windows平台下使用com，都執行在同乙個區域網上。例如，你有兩個伺服器應用程式需要相互通訊，或者你有乙個win32或winform的客戶程式要連線到區域網上的另乙個伺服器程式。在這些程式裡使用dcom會比soap/http有效的多。類似的，如果你的乙個。net程式要連線到lan上的另乙個。net程式，那麼你應該使用。net remoting.有趣的是，在。net remoting中，你也可以指定使用soap/http來進行web service 呼叫。不過最好還是直接通過tcp進行rpc呼叫，那樣會有效得多。總之，只要你從應用程式結構的角度看來，有別的方法比web service 更有效，更可行，那就不要再用web service.
總結
web service是建立可互操作的分布式應用程式的新平台。web service 的主要目標是跨平台的可互操作性。為了達到這一目標，web service 是完全基於xml、xsd等獨立於平台、獨立於軟體**商的標準的。
web service在應用程式跨平台和跨網路進行通訊的時候是非常有用的。web service適用於應用程式整合、b2b整合、**和資料重用，以及通過web進行客戶端和伺服器的通訊的場合。 當然，web service也不是萬能的，你不能到處濫用web service.在有些情況下，web service 會降低應用程式的效能，而不會帶來任何好處。例如，一台機器或乙個區域網裡面執行的同構應用程式就不應該用web service 進行通訊。
什麼時候用exists 什麼時候用in
in not in exists not exists 使用exists，oracle會首先檢查主查詢，然後執行子查詢直到它找到第乙個匹配項，這就節省了時間。oracle在執行in子查詢時，首先執行 子查詢，並將獲得的結果列表存放在乙個加了索引的臨時表中。在執行子查詢之前，系統先將主查詢掛起 待子查...
什麼時候用GET？什麼時候用POST？
get和post兩種方法都是將資料送到伺服器，但你該用哪一種呢？http標準包含這兩種方法是為了達到不同的目的。post用於建立資源，資源的內容會被編入http請示的內容中。例如，處理訂貨表單 在資料庫中加入新資料行等。當請求無 時 如進行搜尋 便可使用get方法 當請求有 時 如新增資料行 則用p...
什麼時候用堆，什麼時候用棧？
參考文章 c 面試題之記憶體分配 一 首先，回顧一下c c 的記憶體分配機制。乙個c c 程式編譯時記憶體分為5大儲存區 堆區 棧區 靜態區 全域性區 文字常量區 儲存字串常量 程式 區 存放二進位制程式 下面主要闡述前面三個。1 靜態儲存區域 靜態儲存區域的 內存在程式編譯時就已經分配好，這塊內存...