作者：Martin Fowler
脈絡：一家企業有多套獨立建造的應用程式，使用不同的語言與平台。企業需要以具回應性的方式共享資料與流程。
光共享資料還不夠#
檔案傳輸與共享資料庫讓應用程式能共享資料——這是應用整合的重要一環，但往往不夠。
資料的變更常常會引發跨應用程式的後續動作。改一個地址可能只是單純的資料變更，也可能觸發登記與法律流程，以配合不同司法管轄區的不同規則。若要讓一個應用程式去喚起另一個應用程式裡的這類流程，就得對對方的內部知道得太多了。
這其實是老問題的鏡像#
這面問題正好映照出應用程式設計中的經典議題。設計中最有力的結構化機制之一就是封裝——模組透過函式呼叫介面隱藏自己的資料，因而能攔截資料變更、執行資料變更時該做的各種動作。
- 共享資料庫提供的是一個龐大而未封裝的資料結構，讓上述封裝變得困難得多。
- 檔案傳輸允許應用程式在處理檔案時對變更做出反應，但那個過程是延遲的。
共享資料庫的資料未封裝，也讓維護一整批被整合的應用程式更困難：任何應用程式的許多變更都可能觸發資料庫變更，而資料庫變更又會在每個應用程式之間造成可觀的漣漪效應。
結果是，採用共享資料庫的系統往往極度抗拒改動資料庫——這意味著應用程式的開發工作對業務需求變化的回應能力大幅下降。
我們需要的，是一種讓應用程式呼叫另一個應用程式中的函式的機制：傳入要共享的資料，並喚起那個告訴接收端「該如何處理這份資料」的函式。
解法#
遠端程序呼叫把封裝原則套用到應用整合上：
- 若某個應用程式需要另一個應用程式擁有的資訊，就直接向對方要。
- 若某個應用程式需要修改另一個的資料，就透過呼叫對方來做。
於是每個應用程式都能維護自己擁有的資料的完整性，也能在不影響其他應用程式的前提下改動自己的內部資料。
實作選項#
RPC 的作法很多：CORBA、COM、.NET Remoting、Java RMI 等，差別在於支援的系統數量與易用程度；這些環境常額外提供交易之類的能力。
論普及程度，當前的時髦寵兒是採用 SOAP 與 XML 等標準的 Web Services。Web service 一個特別有價值的特性是它能輕鬆搭配 HTTP，而 HTTP 很容易穿過防火牆。
優點：方法可以包住資料#
因為有方法把資料包起來，處理語意不一致變得比較容易：應用程式可以對同一份資料提供多套介面，讓某些客戶看見一種樣貌、另一些看見另一種，連更新都可以走不同介面。這比關聯式檢視表（view）更能支援多重觀點。
但整合人員很難插入轉換元件，因此每個應用程式都得自己去跟鄰居協商介面。
缺點：熟悉感反而是陷阱#
因為軟體開發者早已習慣程序呼叫，遠端程序呼叫用起來很順手。
事實上，這弊大於利。遠端與本地程序呼叫在效能與可靠性上有巨大差異。若人們不理解這一點，遠端程序呼叫會導致又慢又不可靠的系統（見 [Waldo]）。
雖然封裝消除了龐大的共享資料結構、有助於降低耦合，各應用程式仍然相當緊密地耦合在一起。每個系統所支援的遠端呼叫，傾向把不同系統綁成一個愈打愈緊的結；尤其是時序——某些事必須依特定順序完成——會讓系統難以獨立改動。
這些之所以成為問題，常常是因為在單一應用程式內部無關緊要的議題，到了整合場景就變得舉足輕重。人們往往用設計單一應用程式的方式去設計整合，卻沒意識到規則已經改變。
接下來#
想頻繁交換小量資料（也許還用來喚起遠端功能）→ 訊息傳遞