canonical

? 在采用AJAX技術的應用中, 常見的是兩種架構設計, 一種是采用RPC(Remote Procedure Call)方案, 后臺應用直接將java對象包裝為service接口, 在js對外暴露(java對象完全不知道web層), 在js中通過類似函數調用的方式訪問后臺服務.而另外一種方案是在后臺維持一個前臺DOM節點的映象,觸發前臺事件之后, 前臺引擎自動截獲該事件, 并翻譯為對后臺事件監聽器的調用, 將請求提交到后臺, 后臺程序處理請求之后更新后臺DOM節點, 然后將頁面變更部分傳回前臺頁面. 這兩種方案一種是傾向于在js中提供自我封閉的程序模型(對遠程服務的調用體現為對一個js函數的調用), 一種是傾向于在后臺提供封閉的程序模型(對前臺頁面的更新體現為對一個后臺java對象的屬性和結構的改變). 這兩種方案的共同之處在于它們都試圖在一定程度上屏蔽前后臺程序的交互細節, 而提供一種統一的程序模型.
? 但是我們需要記住軟件設計的第一要義在于系統的分解, 而Browser和Server之間客觀存在的http信道是天然存在的一種分界線. 任何強迫我們忘記B/S之間的界限的技術都是需要謹慎對待的. 例如控制后臺對象的權限問題, 很多RPC方案限制了應用程序對于web接入層的直接接觸, 而只能通過AOP(Aspect Oriented Programming)技術來動態織入權限控制代碼. 在實際使用中, 這種方式往往因為service接口函數的多樣化而造成配置上的繁瑣.? 而在我們的體系架構中, 系統邊界劃分在web訪問層上(而不是java service層), 借助于web訪問協議自身的一致性和透明性, 我們只需要如下實現
?? Object invokeWebEvent(){??? ???
???? return new ActionMethodInvocation(getWebObject(), getObjectEvent(), getInterceptors()).proceed();
?? }
就為所有WebObject加入interceptor堆棧, 完全不需要AOP的動態織入技術.
? 在witrix平臺的設計中, 因為大量采用pull方案, 我們對于前后臺交互方式采取的是完全開放的態度, 前后臺的交互接口完全定義在web訪問層上(即前臺程序直接訪問一個url獲取數據), 盡量避免將系統架構的限制引入到應用程序設計中來. 確實, Browser和Server之間的原始交互方式是受限制的, 狹窄的, 但是從系統設計的角度上說, 這正是異構系統集成和進行系統核心控制的最好場所, 任何試圖獨占該連接信道并在層層封裝之后提供更加豐富的訪問語義的努力在我看來都是可疑的.
?