本文英文版發在: [url]http://www.theserverside.com/discussions/thread.tss?thread_id=43148[/url]
在公開回答 ([url]http://www.webofweb.net/manifesto/AppletAgainstAJAX.html[/url]) 爲什麼 WoW 當初選了Applet而不是AJAX的問題時, 我開始思考當前大規模軟件組件相互集成的問題, 有了一些新想法.
概括來說, 我發現通常的 API(應用編程接口) 都是單一層次的, 即使是SOA中的服務定義也是. 描述爲"單一層次"是因爲它們是一個設計來被調用的一些 method/function 列表. 但是現在的軟件組件其本身邏輯和調用它們的邏輯都複雜了很多, 而且相當一部分是 "多維" 的 - 結構化的對象和結構化的邏輯. 如此一來, 把多維的邏輯 壓縮/抽象 成爲單層的公開接口的必需工作量增長很快. 有些情況下, 這些抽象過程和爲組合API設計規範的工作甚至有可能超過去理解和解決本來問題的成本.
所以我開始質疑這種通過公開接口來定義組件行爲的方式, 還是這樣最好? 別無他法? 我把這種方式叫做 基於調用的接合方式 (Invocation Based Interfacing), 這種方式下你都是通過調用去改變一個組件的狀態或者獲取它的結果.
然後我總結出一個截然不同的方式, 我稱之爲 基於東道的接合方式 (Hosting Based Interfacing). 在這種方式下 所謂的 特遣專員 被傳遞於軟件組件之間, 各自完成預定的任務. 這樣所帶來的改變是軟件組件不再需要定義公開的, 用來被反覆調用/返回的 接口(服務), 而是公開它們的內部環境 (可能只需要把它們的部分內部邏輯直接公開出來, 無需再封裝). 向接收到的 "特遣專員" 提供這樣的環境以盡 "東道". 然後各種 "特遣專員" 就可以通過目標組件所提供的環境來完成自己的工作, 如果需要的話也可以構造新的 "特遣專員" 發送結果回去.
原始的想法已經在我設計 WoW 的 Traverser/Scener Architecture ([url]http://www.webofweb.net/webstart?r=412[/url]) 時體現出來, 不過現在感覺看得更清晰一些了.
不知道大家怎麼想這個問題.
在公開回答 ([url]http://www.webofweb.net/manifesto/AppletAgainstAJAX.html[/url]) 爲什麼 WoW 當初選了Applet而不是AJAX的問題時, 我開始思考當前大規模軟件組件相互集成的問題, 有了一些新想法.
概括來說, 我發現通常的 API(應用編程接口) 都是單一層次的, 即使是SOA中的服務定義也是. 描述爲"單一層次"是因爲它們是一個設計來被調用的一些 method/function 列表. 但是現在的軟件組件其本身邏輯和調用它們的邏輯都複雜了很多, 而且相當一部分是 "多維" 的 - 結構化的對象和結構化的邏輯. 如此一來, 把多維的邏輯 壓縮/抽象 成爲單層的公開接口的必需工作量增長很快. 有些情況下, 這些抽象過程和爲組合API設計規範的工作甚至有可能超過去理解和解決本來問題的成本.
所以我開始質疑這種通過公開接口來定義組件行爲的方式, 還是這樣最好? 別無他法? 我把這種方式叫做 基於調用的接合方式 (Invocation Based Interfacing), 這種方式下你都是通過調用去改變一個組件的狀態或者獲取它的結果.
然後我總結出一個截然不同的方式, 我稱之爲 基於東道的接合方式 (Hosting Based Interfacing). 在這種方式下 所謂的 特遣專員 被傳遞於軟件組件之間, 各自完成預定的任務. 這樣所帶來的改變是軟件組件不再需要定義公開的, 用來被反覆調用/返回的 接口(服務), 而是公開它們的內部環境 (可能只需要把它們的部分內部邏輯直接公開出來, 無需再封裝). 向接收到的 "特遣專員" 提供這樣的環境以盡 "東道". 然後各種 "特遣專員" 就可以通過目標組件所提供的環境來完成自己的工作, 如果需要的話也可以構造新的 "特遣專員" 發送結果回去.
原始的想法已經在我設計 WoW 的 Traverser/Scener Architecture ([url]http://www.webofweb.net/webstart?r=412[/url]) 時體現出來, 不過現在感覺看得更清晰一些了.
不知道大家怎麼想這個問題.
