canonical

    最近強(qiáng)調(diào)彈性設(shè)計(jì)的比較多，大概是因?yàn)樾枨蟮亩嘧兲钊藫项^了吧。但從道理上說(shuō)，一個(gè)良好的設(shè)計(jì)必然是剛?cè)岵?jì)的。所謂沒(méi)有規(guī)矩不成方圓，你能想象沒(méi)有鋼 筋骨架結(jié)構(gòu)的高樓嗎。在基礎(chǔ)核心架構(gòu)方面特別需要適當(dāng)?shù)膭傂院妥銐虻姆€(wěn)定性，需要用接口明確表達(dá)出將用到的假設(shè)。內(nèi)核穩(wěn)定了，固化了，外圍的aspect 才能安全的織入到系統(tǒng)體系架構(gòu)中來(lái)。象變形金剛那樣的自由組合變化的結(jié)構(gòu)（在流動(dòng)結(jié)構(gòu)與固化結(jié)構(gòu)之間轉(zhuǎn)換）目前還只是一種幻想。

    強(qiáng)類(lèi)型語(yǔ)言在控制大型系統(tǒng)的核心方面還是遠(yuǎn)勝于弱類(lèi)型腳本語(yǔ)言的。有些人認(rèn)為單元測(cè)試可以取代編譯器的強(qiáng)類(lèi)型語(yǔ)法檢查，這完全是一種臆想。程序的正確性應(yīng) 該在不同的層面上得到約束，驗(yàn)證，而不是一古腦的推到單元測(cè)試那里。在單元測(cè)試中對(duì)于概念一致性的保障是絕對(duì)無(wú)法與靜態(tài)類(lèi)型檢查相比的。類(lèi)型一致性的檢查 在編譯器的幫助下以非常低的成本就可以進(jìn)行，而如果要在單元測(cè)試中實(shí)現(xiàn)同樣的約束，成本要高得多。有一點(diǎn)我們應(yīng)該明確：除了功能實(shí)現(xiàn)代碼，其他任何文檔， 代碼都應(yīng)該是多余的。為什么需要單元測(cè)試，那還不是因?yàn)闆](méi)辦法嘛。

   我其實(shí)很少談到OO這個(gè)概念，一般情況下我只提結(jié)構(gòu)的表達(dá)與結(jié)構(gòu)的控制。軟件開(kāi)發(fā)是一個(gè)從二進(jìn)制指令構(gòu)造出一些高級(jí)結(jié)構(gòu)的過(guò)程。無(wú)論是PO, OO, 還是XO, 只要它能有效的降低這種結(jié)構(gòu)構(gòu)造過(guò)程的復(fù)雜性，能夠增強(qiáng)我們對(duì)程序結(jié)構(gòu)的表達(dá)和控制能力，那么它就是有價(jià)值的。在我看來(lái)，繼承（inheritance) 必然是有用的，因?yàn)樗且环N表達(dá)推理結(jié)構(gòu)的方式而無(wú)論它的概念詮釋是什么。行為函數(shù)聚合在對(duì)象的名義下是有意義的，因?yàn)樗沟眠@些關(guān)聯(lián)得以明確化，靜態(tài) 化。為什么函數(shù)式編程是有效的，它和OO是什么關(guān)系。說(shuō)白了，F(xiàn)P能夠方便的表達(dá)OO不易表達(dá)的結(jié)構(gòu)。xml與OO是否是沖突的？xml能夠方便的表達(dá)結(jié) 構(gòu)，通過(guò)dtd或者xml schema又可以方便的實(shí)現(xiàn)對(duì)結(jié)構(gòu)的約束（動(dòng)態(tài)的類(lèi)型系統(tǒng)?)。
    級(jí)列設(shè)計(jì)理論要求我們所有的討論必須在一個(gè)統(tǒng)一的模型（最廣義的模型）下進(jìn)行。OO與非OO的思想其共同之處是什么，它們?cè)谑裁磳用嫔鲜墙y(tǒng)一的？無(wú)論是 OO還是PO，都可以歸結(jié)為結(jié)構(gòu)問(wèn)題。所以我多談結(jié)構(gòu)，少談OO。兩個(gè)不同的概念，可能意味著它們處于復(fù)雜性的不同級(jí)列（可以實(shí)現(xiàn)平滑的過(guò)渡），也可能意 味著它們之間是正交的，互補(bǔ)的

                                      

http://www.xml.com/pub/a/ws/2003/09/30/soa.html
http://canonical.blogdriver.com/canonical/809426.html

   隨著IBM, Microsoft這些世界級(jí)大廠商不遺余力的推銷(xiāo)，SOA(Service Oriented Architecture)已經(jīng)成為企業(yè)應(yīng)用中的核心概念之一。我的一個(gè)同學(xué)在IBM做SOA架構(gòu)咨詢，前兩天也和他聊到這個(gè)話題。從他們IBM的態(tài)度來(lái) 看，SOA無(wú)非是后EJB時(shí)代一個(gè)profitable enabled的概念而已。現(xiàn)在軟件廠商的日子變得愈加艱難了，很多廠商都希望向服務(wù)轉(zhuǎn)型，成為所謂IT service provider. 這是某種商業(yè)架構(gòu)上的service oriented, 與技術(shù)上的SOA似乎有一些相互映襯的關(guān)系。IBM極力希望把SOA中的service概念提升到business layer, 希望在超越BPM(Business Process Management)的層次上提供一站式的打包服務(wù)。但是很顯然，此service非彼service, 這種SOA的宣傳中頗有一些偷換概念之嫌。把所有可以讓用戶買(mǎi)單的理由用MDA(Model Driven Architecture)做包裝，打包到一個(gè)獨(dú)立概念的package中在目前確實(shí)是一種可行的商業(yè)策略，只不過(guò)相對(duì)于用戶脆弱的技術(shù)理解力而言，這種 SOA實(shí)在是不可承受之重。大多數(shù)用戶所能理解的SOA不過(guò)是Integration的代名詞，與EAI(Enterprise  Application Integration)沒(méi)有什么可區(qū)分性。目前java技術(shù)的普及已經(jīng)使得各個(gè)廠商的區(qū)別變得很小了，IBM這些巨型廠商鼓吹它們?cè)诋悩?gòu)系統(tǒng)集成方面的 優(yōu)勢(shì)當(dāng)然是勢(shì)所難免，在此過(guò)程中加點(diǎn)料也是可以理解的。


   雖然SOA這一概念中混雜了太多的商業(yè)因素，它也并不是一種單純的fantasy. 從技術(shù)角度上說(shuō)，SOA存在著如下關(guān)鍵性特征：
1. 獨(dú)立運(yùn)行(standalone)。所謂的service, 它與組件(component)的根本不同，首先在于service是獨(dú)立于調(diào)用者自行運(yùn)轉(zhuǎn)的。訪問(wèn)service的接口相對(duì)狹窄，我們只需要知道 service如何滿足我們的功能需求，而不需要管理它的生命周期，不需要理會(huì)那些維持service運(yùn)行所需要考慮的種種細(xì)節(jié)。即我們對(duì)于 service的了解只需要局限于功能接口即可，不需要理會(huì)它的那些管理接口，配置接口等。各種service在功能接口這一層面發(fā)生交互，整個(gè)圖景得到 簡(jiǎn)化。最常見(jiàn)的一個(gè)例子就是數(shù)據(jù)庫(kù)服務(wù)器，調(diào)用程序只要知道如何通過(guò)sql語(yǔ)言進(jìn)行數(shù)據(jù)訪問(wèn)即可，另有數(shù)據(jù)庫(kù)管理員去對(duì)付各種配置管理問(wèn)題。從技術(shù)上說(shuō)， 這可以看作是singleton模式的一種擴(kuò)展。實(shí)際上spring容器中管理的bean在某種程度上就可以看作是獨(dú)立于bean的調(diào)用者的，因而 spring這樣的容器可以成為SOA架構(gòu)的自然接入點(diǎn)。

2. 異步調(diào)用(asynchronous)。內(nèi)稟的異步特性是SOA包容真正的商業(yè)智能的關(guān)鍵所在。想象一下我們現(xiàn)在需要評(píng)估用戶的信用度,它對(duì)應(yīng)于函數(shù) evaluateCustomerCredit(customer). 最簡(jiǎn)單的情況下，我們只需要根據(jù)用戶的某些指標(biāo)直接進(jìn)行算術(shù)運(yùn)算即可。如果評(píng)估規(guī)則非常復(fù)雜，我們可能放棄硬編碼，而引入規(guī)則引擎（Rule Engine)這種人工智能的解決方案。在更加復(fù)雜的情況下，我們可能無(wú)法抽象出以數(shù)學(xué)方式表達(dá)的規(guī)則，而必須依賴于業(yè)務(wù)人員的人工處理（真正的智能）。 此時(shí)，系統(tǒng)可能需要彈出一個(gè)頁(yè)面，等待業(yè)務(wù)人員作出判斷，部分情況下還需要經(jīng)過(guò)審批流程才能決定對(duì)于用戶信用度的最終評(píng)定。對(duì)于計(jì)算機(jī)系統(tǒng)而言，這些都是 漫長(zhǎng)的過(guò)程，是同步調(diào)用方式所無(wú)法容納的。同樣是一個(gè)函數(shù)調(diào)用，只有異步特性才能夠包容真正的商業(yè)智能，才能在函數(shù)這種最小的程序結(jié)構(gòu)單元中引入最復(fù)雜的 處理過(guò)程。現(xiàn)在SOA的宣傳往往集中于機(jī)器之間的互相調(diào)用，強(qiáng)調(diào)異構(gòu)系統(tǒng)之間的一種包容性，但事實(shí)上異步特性所能承載的內(nèi)容要遠(yuǎn)遠(yuǎn)超越機(jī)器世界本身。當(dāng) 然，同步調(diào)用方式也是SOA架構(gòu)的自然組成部分，就像我們既需要email， 也需要手機(jī)一樣。

3. 基于消息(message based)。基于消息的調(diào)用方式是分布式系統(tǒng)的一種內(nèi)在要求。消息是一種數(shù)據(jù)，它并不是遠(yuǎn)程對(duì)象指針。distributed object這種基于proxy-stub的方案其內(nèi)稟要求是遠(yuǎn)程狀態(tài)同步（狀態(tài)的一致性）,而分布式系統(tǒng)是由眾多獨(dú)立的狀態(tài)空間（進(jìn)程空間）所構(gòu)成的， 這種內(nèi)在的不協(xié)調(diào)是造成分布式對(duì)象方案難以實(shí)現(xiàn)可擴(kuò)展性的關(guān)鍵原因。
  SOA與EBI(event-based integration)的區(qū)別主要在于EBI往往是push模式的，消息源向注冊(cè)的消息consumer推送消息，而SOA往往還是一種pull的調(diào) 用。這兩種方式各有千秋，在大的scale情況下，pull模式的可擴(kuò)展性要更好一些。但是兩種模式在企業(yè)應(yīng)用中都是必不可少的，可能這些概念很快就會(huì)出 現(xiàn)融合。


4. 純文本協(xié)議+元數(shù)據(jù)(Plaintext Meta)。SOA架構(gòu)中基于純文本協(xié)議是一個(gè)非常關(guān)鍵的技術(shù)抉擇。當(dāng)需要跨越眾多硬件平臺(tái)和軟件系統(tǒng)的時(shí)候，各種二進(jìn)制的RPC方案總是存在著難以徹底 解決的可理解性的問(wèn)題。憑借純文本的結(jié)構(gòu)透明性加上元數(shù)據(jù)的自描述特性，我們希望實(shí)現(xiàn)一種語(yǔ)義透明性，使得各種中間層都能夠以通用的方式傳遞經(jīng)過(guò)的消息， 并理解其中需要理解的部分。與OOP(Object Oriented Programming)中的傳統(tǒng)模式不同的是，SOA架構(gòu)中強(qiáng)調(diào)的是結(jié)構(gòu)(structure)與內(nèi)容(content)的分離，而不是數(shù)據(jù)與行為的耦 合與封裝. 表面上看起來(lái)，SOA中的調(diào)用方式似乎是對(duì)procedure（過(guò)程）化調(diào)用的回歸，但實(shí)際上其中有著深刻的不同。在與元數(shù)據(jù)結(jié)合之后，在系統(tǒng)之間傳遞的 消息（信息）并不是完全被動(dòng)的，而是具有某種smart特性。當(dāng)數(shù)據(jù)這一方面可以包容更多的變化的時(shí)候，處理函數(shù)這一方面的結(jié)構(gòu)可以得到簡(jiǎn)化。實(shí)際上，在 SOA架構(gòu)中，我們推崇一種uniform interface, 也只有通過(guò)一種通用的接口，信息才能以比較低的代價(jià)穿越各種狀態(tài)空間邊界。基于通用接口，我們又重新發(fā)現(xiàn)了世界的簡(jiǎn)單性，而pipe-and- filter這種在unix系統(tǒng)中久經(jīng)考驗(yàn)的設(shè)計(jì)模式也得到了新的發(fā)揮空間。
    說(shuō)到純文本的元語(yǔ)言，xml無(wú)疑是這一概念最強(qiáng)勢(shì)的候選者。作為一種半結(jié)構(gòu)化的文本表述，xml天然就是人機(jī)共享的信道。但是，隨著應(yīng)用的深入，當(dāng)越來(lái)越 多的xml設(shè)計(jì)變得無(wú)法讓人直觀理解的時(shí)候，我們也感覺(jué)到了一些對(duì)于xml濫用的痕跡。W3C的Web Service協(xié)議棧提供了非常關(guān)鍵性的思想，并作為標(biāo)準(zhǔn)化的實(shí)現(xiàn)方式存在了很長(zhǎng)的時(shí)間了，但是其實(shí)現(xiàn)和調(diào)用的繁瑣和冗長(zhǎng)逐漸引起了開(kāi)發(fā)者的不滿。 SOAP雖然號(hào)稱(chēng)Simple Object Access Protocol，但是今天已經(jīng)很難把它和simple這個(gè)詞拉上什么關(guān)系。也許Web Service的未來(lái)就如同EJB一樣, 漸漸被更加pragmatic的方案所取代。

    在SOA架構(gòu)中，松散耦合(loose couple)是late binding(discovery), standalone和message based等多種技術(shù)策略綜合作用之后所達(dá)到的一種效果，這為外部靈活的流程配置做好了鋪墊。

    web開(kāi)發(fā)這個(gè)領(lǐng)域是很有意思的。首先，web的興起是在軟件業(yè)發(fā)展到一定階段才發(fā)生的，它必然吸收了軟件業(yè)最優(yōu)良的思想，必然有其本質(zhì)上先進(jìn)的地方。另 一方面，web的應(yīng)用畢竟是時(shí)日較短的事情，造成很多基礎(chǔ)架構(gòu)方面也是薄弱的，原始的。
    具體來(lái)說(shuō)，前臺(tái)html的展現(xiàn)模型本身是非常先進(jìn)的。xhtml+css+js實(shí)現(xiàn)了結(jié)構(gòu)(structure), 表現(xiàn)(presentation)和行為(behavior)的分離。xhtml本身是簡(jiǎn)單的文本文件，通過(guò)工具的支持可以做到結(jié)構(gòu)上的"所見(jiàn)即所得" (WYSIWYG)。 在js中操縱html結(jié)構(gòu)具有多種方式：可以通過(guò)id直接訪問(wèn)html片斷，可以直接操縱dom的層次結(jié)構(gòu)，可以將html作為線性文本處理，可以應(yīng)用 xml相關(guān)的技術(shù)對(duì)dom結(jié)構(gòu)進(jìn)行變換，可以動(dòng)態(tài)切換html元素的css風(fēng)格等。dom結(jié)構(gòu)的訪問(wèn)方式是高度統(tǒng)一的，通過(guò)parentNode, childNodes, setAttribute, getAttribute等少數(shù)幾個(gè) API函數(shù)，我們可以通過(guò)一種簡(jiǎn)潔一致的方式操縱所有的節(jié)點(diǎn)和相關(guān)屬性（當(dāng)然,IE這方面的bug不少）。html相關(guān)技術(shù)中所顯示的結(jié)構(gòu)控制能力遠(yuǎn)遠(yuǎn)超 越了傳統(tǒng)桌面程序中組件技術(shù)所能達(dá)到的程度。
    但另一方面，html也是原始的，缺乏現(xiàn)代應(yīng)用程序所必需的標(biāo)準(zhǔn)控件，典型的如Tree控件和Tab控件等。每個(gè)開(kāi)發(fā)商都不得不實(shí)現(xiàn)并維護(hù)自己的界面庫(kù)。 通過(guò)web界面調(diào)用后臺(tái)業(yè)務(wù)邏輯的方式更是很粗糙的。基礎(chǔ)的servlet只提供了基于IO的有限狀態(tài)機(jī)模型，對(duì)于后臺(tái)功能缺乏有效的組織，而對(duì)于前臺(tái)界 面也缺乏合適的抽象手段，僅僅作為文本輸出。MVC框架建筑在servlet模型之上，將后臺(tái)邏輯功能以一種統(tǒng)一的組織方式向外暴露。而tag技術(shù)在前臺(tái) 界面中的應(yīng)用，使得我們可以有效的識(shí)別并分離出我們所關(guān)心的結(jié)構(gòu)。這些技術(shù)的發(fā)展都是web開(kāi)發(fā)模型逐漸精細(xì)化的必然結(jié)果。
    為了在服務(wù)器端獲得足夠強(qiáng)的結(jié)構(gòu)控制能力，有些人求助于桌面程序的歷史開(kāi)發(fā)經(jīng)驗(yàn)，希望通過(guò)java語(yǔ)言中的結(jié)構(gòu)表達(dá)能力來(lái)擴(kuò)展web開(kāi)發(fā)的模型，于是便有 了echo2, tapestry這樣的組件化web開(kāi)發(fā)框架。坦率的說(shuō)，我并不看好這類(lèi)強(qiáng)類(lèi)型建模的框架。除了性能上的原因之外，我反對(duì)這類(lèi)框架的一個(gè)主要原因是 java語(yǔ)言直接表達(dá)的結(jié)構(gòu)一般無(wú)法達(dá)到用xml文本表達(dá)的結(jié)構(gòu)的統(tǒng)一性和靈活性，從而很難應(yīng)對(duì)界面的快速變化。實(shí)際上，對(duì)web界面進(jìn)行組件化的分解并 不一定需要一種強(qiáng)類(lèi)型語(yǔ)言支持的組件模型。通過(guò)自定義標(biāo)簽的使用，我們完全可以實(shí)現(xiàn)將頁(yè)面分解為多個(gè)子部分的目的，這一點(diǎn)已經(jīng)由witrix平臺(tái)中的 tpl模板技術(shù)所證實(shí)。

    web開(kāi)發(fā)是個(gè)既先進(jìn)又落后的領(lǐng)域。很多人面對(duì)這種矛盾的情況，難免思想上會(huì)出現(xiàn)混亂。關(guān)鍵是要認(rèn)清技術(shù)的本質(zhì)而不要被OO是否必需等抽象的討論所迷惑。

web程序需要完成  html <--> java 之間的映射，在界面越來(lái)越復(fù)雜，越來(lái)越多變的今天，這項(xiàng)工作也變得越來(lái)越困難。按照級(jí)列設(shè)計(jì)理論的觀點(diǎn)，我們應(yīng)該去尋求一些中間的過(guò)渡步驟。在 witrix平臺(tái)中，tpl模板引擎正扮演了這種中間角色。通過(guò)tpl模板我們實(shí)現(xiàn)了如下映射路徑

html <--> tpl <--> java

注 意到這里html與tpl之間，以及tpl與java之間的映射都不是trivial的同構(gòu)關(guān)系，而是都可能存在著復(fù)雜的運(yùn)算過(guò)程，從而實(shí)現(xiàn)了html與 java映射過(guò)程中復(fù)雜性的分解與均攤。tpl與java之間的關(guān)聯(lián)主要通過(guò)EL(expression language)表達(dá)式來(lái)完成，而html與tpl的映射則主要通過(guò)自定義標(biāo)簽(tag)機(jī)制。
注意到tpl所提供的中間層具有獨(dú)立的重大意 義，它并不是臆造的或者是簡(jiǎn)單的技術(shù)驅(qū)動(dòng)的結(jié)果。實(shí)際上，在web開(kāi)發(fā)中除了java結(jié)構(gòu)與html結(jié)構(gòu)之外還存在著第三種結(jié)構(gòu)，即用戶眼中的界面結(jié)構(gòu)， 本來(lái)它與html所描述的結(jié)構(gòu)是簡(jiǎn)單的一一對(duì)應(yīng)的，但是隨著界面技術(shù)的發(fā)展，html的描述能力逐漸被耗盡，成為了internet時(shí)代的"匯編語(yǔ)言"。 現(xiàn)在一個(gè)簡(jiǎn)單的頁(yè)面片斷就可能對(duì)應(yīng)著大量html代碼，因而喪失了"所寫(xiě)即所見(jiàn)"的簡(jiǎn)單性。tpl通過(guò)強(qiáng)大的抽象能力在某種程度上恢復(fù)了程序員對(duì)于界面表 現(xiàn)結(jié)構(gòu)的直觀控制能力，并在一定程度上保留了html所見(jiàn)即所得的特性。

在witrix平臺(tái)中因?yàn)榇嬖谥鴗pl這一強(qiáng)大的抽象層，使得我們對(duì)于ajax的支持可以采取更加靈活的方式。
ajax(Asynchronous JavaScript + XML)的標(biāo)準(zhǔn)結(jié)構(gòu)是
html <--> js <==> xml <==> java

在 這種結(jié)構(gòu)中通過(guò)xml信道的只是數(shù)據(jù)，而界面的表達(dá)邏輯與展現(xiàn)邏輯完全由js來(lái)控制。這種結(jié)構(gòu)發(fā)展的一個(gè)極端是所有的界面展現(xiàn)結(jié)構(gòu)都由 javascript動(dòng)態(tài)構(gòu)造出來(lái)，而完全喪失了html靜態(tài)描述的特點(diǎn),喪失了所見(jiàn)即所得的設(shè)計(jì)。與直接實(shí)現(xiàn)html<-->java之間 的映射情況類(lèi)似，直接實(shí)現(xiàn) html <--> js之間的映射也是困難的，盡管dom模型的支持可能使得js映射的難度要低于java映射。

在witrix平臺(tái)中ajax的方案為
html <--> js <==> tpl <--> java

即tpl取代了ajax標(biāo)準(zhǔn)方案中xml的位置，使得映射過(guò)程的復(fù)雜性得以分散化。

結(jié)合jsplet框架的拉模式（pull mode)，我們定義了如下ajax訪問(wèn)接口
js.ajax.load({request='objectName=/@Test&objectEvent=query',tpl:'/test.tpl:partA',targetId:'testDiv'});

1。 遠(yuǎn)程服務(wù)請(qǐng)求就是一段普通的http post request， 避免了額外的xml編碼解碼需求。
2。請(qǐng)求到的數(shù)據(jù)先由tpl文件來(lái)進(jìn)行處理。注意到這里tpl文件的url分成兩部分，前一部分是tpl文件的虛擬路徑，而 ：后面的部分，即partA指出請(qǐng)求的是該tpl文件內(nèi)的partA部分，而不是整個(gè)tpl文件。
3。返回的html結(jié)果被填充到targetId所指定的html元素中。

test.tpl文件的內(nèi)容
＜html＞
＜body＞

＜tpl:define id="partA"＞
＜img tpl:tag="ui:EditTable" /＞
＜/tpl:define＞

＜div id="testDiv"＞
＜img tpl:tag="ui:ViewTable" /＞
＜/div＞

＜/body＞
＜/html＞

tpl具有強(qiáng)大的結(jié)構(gòu)構(gòu)造能力，在這里我們以非常小的代價(jià)實(shí)現(xiàn)了tpl片斷的定義，例如test.tpl中的partA部分。這里通過(guò)id訪問(wèn)tpl片斷就如同js中通過(guò)id來(lái)訪問(wèn)html片斷一樣。
最后提一個(gè)很重要的思想：大量零碎的代碼片斷需要集中存放，否則人的精力會(huì)被耗散。一個(gè)反例就是struts中的action, 明明只干那么點(diǎn)事，偏偏要占據(jù)一個(gè)單獨(dú)的java文件，占據(jù)大量單獨(dú)的配置條目，最終給程序員帶來(lái)很大的困擾。

Ajax: A New Approach to Web Applications http://www.adaptivepath.com/publications/essays/archives/000385.php
Ajax(Asynchronous JavaScript + XML)并不是一個(gè)革命性的嶄新概念（也許根本就不存在突發(fā)的革命），它的技術(shù)基礎(chǔ)在多年之前就已經(jīng)牢固的建立起來(lái)了，在概念層次上的探討也早就不是一個(gè) 新鮮的話題，只是大規(guī)模的有深度的應(yīng)用似乎是最近才開(kāi)始的。
從廣義上說(shuō)，web應(yīng)用至少涉及到兩個(gè)結(jié)構(gòu)，
1. 后臺(tái)以java語(yǔ)言表達(dá)的業(yè)務(wù)邏輯結(jié)構(gòu)
2。前臺(tái)以html語(yǔ)言表達(dá)的界面表現(xiàn)結(jié)構(gòu)。

web開(kāi)發(fā)很大一部分工作就是建立這兩個(gè)結(jié)構(gòu)之間的關(guān)系。即我們需要
html <--> java

我 們首先要意識(shí)到這兩種結(jié)構(gòu)之間并不一定是同構(gòu)的，即后臺(tái)數(shù)據(jù)的組織方式與前臺(tái)展現(xiàn)時(shí)的結(jié)構(gòu)是不同的。同樣的數(shù)據(jù)可以對(duì)應(yīng)于不同的展現(xiàn)結(jié)構(gòu)。這也是所謂 MVC架構(gòu)實(shí)現(xiàn)模型與視圖分離的依據(jù)。傳統(tǒng)上，基于Model2模式的MVC框架中，這兩種結(jié)構(gòu)的映射只能在很粗的粒度上進(jìn)行（即整個(gè)頁(yè)面的粒度上），因 此妨礙了封裝和重用。為了進(jìn)行細(xì)粒度的映射，我們必須要擁有細(xì)粒度的結(jié)構(gòu)控制能力。而目前最強(qiáng)的結(jié)構(gòu)控制能力存在于javascript/DHTML模型 之中，在js中html的結(jié)構(gòu)可以是一段線性的文本(innerHTML和outerHTML), 可以是層級(jí)組織的節(jié)點(diǎn)（parentNode, childNodes), 也可以是按照key組織起來(lái)的Map(getElementById)。在不同的情形下，我們可以根據(jù)需要選擇不同的結(jié)構(gòu)模型。
ajax體系很直接的一個(gè)想法就是將所有關(guān)于界面表達(dá)和控制的結(jié)構(gòu)都推到前臺(tái)，由控制力最強(qiáng)的js來(lái)控制后臺(tái)數(shù)據(jù)模型與前臺(tái)html模型之間的映射。
html <--> js <==> xml <==> java
在ajax 體系中，xml所扮演的角色是js與java之間的翻譯通道，它將js中的結(jié)構(gòu)與java中的結(jié)構(gòu)對(duì)應(yīng)起來(lái)，這種翻譯比html/java之間的映射要簡(jiǎn) 單的多。其實(shí)它甚至可以是一種同構(gòu)的映射，可以用一種通用的方式來(lái)進(jìn)行，例如結(jié)合burlap與buffalo包的功能。結(jié)合webservice的一些 思想，js/java之間的映射是可以在函數(shù)調(diào)用這種細(xì)粒度上自動(dòng)進(jìn)行的，從而我們最終可以在概念上完成html/java之間的細(xì)粒度映射。

    AOSD(Aspect-Oriented Software Development)可以看作是AOP技術(shù)思想在設(shè)計(jì)領(lǐng)域的一種投射. 采用Aspect的觀念之后, 我們?cè)谙到y(tǒng)分析時(shí)應(yīng)用如下的分解策略
     base + extensionA + extensionB +... 而不僅僅是 partA + partB + ...
  這種分解的基本理由在于base/extension的依賴關(guān)系與extension之間的依賴關(guān)系并不相同. 在理想情況下, extension之間是完全正交的, 而它們通過(guò)base可以構(gòu)成一個(gè)整體, 這是一種典型的star schema. 但是在實(shí)際的軟件構(gòu)造過(guò)程中, 軟件各個(gè)元素之間的交互方式要復(fù)雜的多:
 1. extension之間可能存在著相互作用, 最簡(jiǎn)單的一種情況是extension執(zhí)行時(shí)的序關(guān)系(order).
 2. 一個(gè)結(jié)構(gòu)上的extension可能分散到多個(gè)component上, 如何精確而有效的控制定位是一個(gè)非常困難的問(wèn)題.
    就目前的AOP技術(shù)而言, 對(duì)于extension的控制其實(shí)是非常乏力的(但這并不意味著AOP必然放棄對(duì)extension的控制), 我們尚需要積累更多的經(jīng)驗(yàn). 在實(shí)做中, 更加穩(wěn)健的方法往往是應(yīng)用aspect的思想而采用傳統(tǒng)的實(shí)現(xiàn)方式.
    AOSD在理論上存在一些價(jià)值, 例如它為use case的extension符號(hào)找到了技術(shù)對(duì)應(yīng), 因而使得這個(gè)概念變得更加明晰, 而在傳統(tǒng)中, 對(duì)于use case的extension的解釋一直是模糊而混亂的. 目前在真正的開(kāi)發(fā)中, AOSD所描繪的全程建模仍然只是一個(gè)遙遠(yuǎn)的夢(mèng)想.

  如果一個(gè)東西看起來(lái)象花生，聞起來(lái)象花生，吃起來(lái)也象花生，那它究竟是不是花生？ 如果兩個(gè)事物在所有可觀測(cè)行為上都表現(xiàn)一致，那兩者的本質(zhì)是否統(tǒng)一就成為了一個(gè)不可證偽的問(wèn)題，從而處于科學(xué)范疇之外。而從人的機(jī)會(huì)主義傾向來(lái)看，我們理 所當(dāng)然的會(huì)認(rèn)為這兩者是同一概念。我們以觀察來(lái)認(rèn)識(shí)世界，當(dāng)然也就是以行為來(lái)界定事物。問(wèn)題在于，我們?cè)诶碚撋弦允挛锏乃行袨閬?lái)界定它，而我們目前觀 測(cè)到的又永遠(yuǎn)只是它的部分行為。在泛函分析分析中，有一種弱（weak)等價(jià)的概念，兩個(gè)函數(shù)如果與某個(gè)空間中所有函數(shù)的作用（內(nèi)積）的結(jié)果都相等，則這 兩個(gè)函數(shù)在此空間中就是弱等價(jià)的。swartz正是通過(guò)這種方法定義了廣義函數(shù)，為delta函數(shù)在數(shù)學(xué)上建立了嚴(yán)格的基礎(chǔ)，回避了delta函數(shù)的本質(zhì) 性定義困難。在物理學(xué)家看來(lái)，delta函數(shù)當(dāng)然是個(gè)客觀存在的實(shí)體，而在數(shù)學(xué)家看來(lái)，它只是通過(guò)分布間接定義的概念。（當(dāng)然，部分研究非標(biāo)準(zhǔn)分析的數(shù)學(xué) 家認(rèn)為廣義函數(shù)兜了個(gè)大圈子）
    接口(interface)與類(lèi)(class)相比，接口的概念完全是由其行為定義的，而類(lèi)還涉及到其封裝了的成員變量，這些變量的作用在繼承的時(shí)候會(huì)隱 蔽的表現(xiàn)出來(lái)。毫無(wú)疑問(wèn)，接口所代表的概念是比類(lèi)變得"淺薄"了，它是明確暴露的行為切片而不是象類(lèi)那樣欲遮還羞的實(shí)體定義。

IntelliJ老板的一篇文章Language Oriented Programming: The Next Programming Paradigm
英文 http://www.onboard.jetbrains.com/articles/04/10/lop/
中文 http://blog.csdn.net/chelsea/archive/2005/02/17/290486.aspx

Martin Follower的一篇文章 Language Workbenches: The Killer-App for Domain Specific Languages?
http://www.martinfowler.com/articles/languageWorkbench.html

概念解釋?zhuān)?br> DSL(Domain Specific Language): a limited form of computer language designed for a specific class of problems, 例如SQL語(yǔ)言，xml配置文件。
LOP(Language Oriented Programming): the general style of development which operates about the idea of building software around a set of domain specific languages.
Language Workbench： the new breed of tools to do language oriented programming

LOP不是一個(gè)新的提法，不過(guò)隨著前段時(shí)間MDA(Model Driven Architecture)概念的熱炒，LOP似乎終于熬到了應(yīng)用層面。Sergey Dmitriev的文章中批評(píng)了主流程序語(yǔ)言的不足，大概有這么幾條：
1. 通用語(yǔ)言表達(dá)能力(expressive power)很差，Time Delay to Implement Ideas
2. 領(lǐng)域概念的表達(dá)分散在實(shí)現(xiàn)代碼中，整體圖像迷失，因而Understanding and Maintaining Existing Code很困難。
3. 類(lèi)庫(kù)等不是用領(lǐng)域概念表達(dá)的，因而Domain Learning Curve很陡峭。

這 些都是標(biāo)準(zhǔn)的陳詞濫調(diào)。地球人都知道，從問(wèn)題描述到軟件實(shí)現(xiàn)之間存在著巨大的邏輯障礙，這種障礙有一部分是本質(zhì)性的，即源于我們認(rèn)識(shí)中的創(chuàng)造性因素，而另 一部分是技術(shù)性的，即源于我們使用的技術(shù)手段的限制。我們所能想到的解決的辦法就是盡量提高解決方法的抽象層次, 提升到所謂的領(lǐng)域?qū)用妫瑥亩饧夹g(shù)性障礙，同時(shí)輔助創(chuàng)造性發(fā)展。當(dāng)我們的腦子里不再充斥著各種技術(shù)性細(xì)節(jié)的時(shí)候，大概就可以集中精力做些創(chuàng)造性工作了。 LOP把這些老帳又翻出來(lái)，到底它提供了什么新意？下面我們簡(jiǎn)要分析一下LOP方案中概念的含義。

1. 領(lǐng)域(Domain)。
    計(jì)算機(jī)語(yǔ)言與自然語(yǔ)言在使用上是有著深刻不同的。自然語(yǔ)言只是傳遞著信息，而計(jì)算機(jī)語(yǔ)言還要負(fù)責(zé)具體干事情，即計(jì)算機(jī)語(yǔ)言要同時(shí)說(shuō)明怎么做和怎么用。做與 用這是兩個(gè)不同的領(lǐng)域，例如我現(xiàn)在編了一個(gè)時(shí)光機(jī)器的軟件，上面就一按鈕，只要輕輕一按，嗖的一聲我就回到了500年前。怎么樣，使用簡(jiǎn)單吧，但實(shí)現(xiàn)呢？ 我們當(dāng)然希望在一個(gè)領(lǐng)域中使用最適合它的描述方法和控制指令。目前主流語(yǔ)言都是面向機(jī)器實(shí)現(xiàn)領(lǐng)域的(是實(shí)現(xiàn)領(lǐng)域的DSL?)，加上Von Neumann串性化體系的限制, 強(qiáng)迫我們用動(dòng)態(tài)過(guò)程來(lái)實(shí)現(xiàn)靜態(tài)概念，更加劇了它對(duì)使用領(lǐng)域描述的不適應(yīng)性。我們所要做的就是將做與用盡量分離，但同時(shí)盡量增大用的靈活性，domain representation不僅僅給最終用戶用，還給程序員用。能在使用領(lǐng)域概念范圍內(nèi)解決的問(wèn)題，我們不要將其拖延到實(shí)現(xiàn)領(lǐng)域。在領(lǐng)域間進(jìn)行轉(zhuǎn)換，總 存在信息轉(zhuǎn)換成本，甚至?xí)斐尚畔⑹д妗＠纾环?huà)看起來(lái)結(jié)構(gòu)很簡(jiǎn)單，但是用自然語(yǔ)言描述起來(lái)都相當(dāng)困難，更別說(shuō)轉(zhuǎn)換為計(jì)算機(jī)語(yǔ)言了（當(dāng)然，這個(gè)例子很 有可能是誤導(dǎo)的，因?yàn)樯婕暗讲煌母泄伲渲械膮^(qū)別是非常深刻的，無(wú)法用單一的原因去解釋?zhuān)Ｋ^領(lǐng)域區(qū)分，最重要的還是使用領(lǐng)域與實(shí)現(xiàn)領(lǐng)域的區(qū)分（不同 的復(fù)雜性，不同的表現(xiàn)形式...），而不僅僅是業(yè)務(wù)領(lǐng)域與計(jì)算機(jī)領(lǐng)域的劃分。在業(yè)務(wù)領(lǐng)域內(nèi)部我們也要區(qū)分使用與實(shí)現(xiàn)。

2. 領(lǐng)域特定語(yǔ)言(DSL)
    語(yǔ)言與庫(kù)的最大差別在于語(yǔ)素可以自由組合，以極低的代價(jià)構(gòu)造出無(wú)數(shù)可驗(yàn)證的結(jié)構(gòu)，而庫(kù)函數(shù)的組合和搭配調(diào)用是冗長(zhǎng)的，受限的，難以進(jìn)行校驗(yàn)的。DSL強(qiáng)大 的描述能力和推理能力其實(shí)是通過(guò)放棄其通用建模能力而實(shí)現(xiàn)的。最有效的DSL必須弱于圖靈機(jī)，必須將大量做的過(guò)程分離出去，必須引入大量的領(lǐng)域概念（本 體）。
    在引入外部概念的時(shí)候，DSL會(huì)將其轉(zhuǎn)義為領(lǐng)域概念之后使用，從而消除歧義性并降低理解難度。
    DSL不是在通用環(huán)境下工作，而是在明確受限的context下工作，因而概念的表達(dá)可以更加簡(jiǎn)潔，而且領(lǐng)域概念之間還可以通過(guò)context構(gòu)成一種整體性，例如非此即彼。
    witrix平臺(tái)中的tpl模板引擎在一定程度上可以看作是一種DSL tools, 我也一直推動(dòng)tpl在這個(gè)方向上發(fā)展。tpl具有強(qiáng)大的領(lǐng)域抽象能力,例如
       彈出一個(gè)選擇系統(tǒng)用戶的窗口，直接實(shí)現(xiàn)為 
        ＜a href="select_user.jsp?deptId=1"＞選擇用戶＜a＞

    封裝為tag之后，使用形式變?yōu)?br>         ＜app:選擇用戶 部門(mén)編號(hào)="1" /＞
    經(jīng)過(guò)轉(zhuǎn)換之后，這里的調(diào)用不再是API含義，不再是說(shuō)明怎么做，而是描述用什么。tpl中的標(biāo)簽可以使用調(diào)用時(shí)明確指定的參數(shù)，也可以從全局 context中導(dǎo)入隱含的變量，從而依賴于所在領(lǐng)域的假定。例如，我們的很多界面控件需要與后臺(tái)交互，依賴于后臺(tái)jsplet框架，因而這些tpl標(biāo)簽 選擇自動(dòng)導(dǎo)入$thisObj和objectName等變量。領(lǐng)域抽象與context依賴其實(shí)正是DSL的精華所在。
    (關(guān)于DSL，有些人可能會(huì)將其等價(jià)于規(guī)則引擎(rule engine), 這其實(shí)是一種誤解。規(guī)則引擎實(shí)現(xiàn)的是條件空間的分解與合并，它是一個(gè)獨(dú)立的技術(shù)，與DSL并沒(méi)有必然的聯(lián)系)

3. 語(yǔ)言工作臺(tái)(Workbench)
    Workbench是LOP的使能技術(shù)。我們希望自由的構(gòu)造DSL,必然需要對(duì)結(jié)構(gòu)具有強(qiáng)大的控制能力。而文本語(yǔ)言總是線性的，靜態(tài)的。看看現(xiàn)在對(duì)自然語(yǔ) 言的研究吧，顯然我們對(duì)于怎樣在線性文本中塞入更多的結(jié)構(gòu)缺乏本質(zhì)性的認(rèn)識(shí)。我們?nèi)藶闃?gòu)造的語(yǔ)言，限于表現(xiàn)形式，其結(jié)構(gòu)都異常的貧乏。計(jì)算機(jī)的腦袋是簡(jiǎn)單 的，于是，我們想到增加維度，通過(guò)復(fù)雜的工具配合，來(lái)實(shí)現(xiàn)多層次，多視角, 動(dòng)態(tài)的結(jié)構(gòu)控制。在我看來(lái)，很多時(shí)候這是一種無(wú)奈之舉，當(dāng)然也確實(shí)是目前唯一可行的辦法。
    工具復(fù)雜了之后，造成的本質(zhì)性障礙在于結(jié)構(gòu)上的僵化，其具體表現(xiàn)之一就是所謂的廠家鎖定,一種結(jié)構(gòu)融合上的困難。不同廠家產(chǎn)品的結(jié)構(gòu)具有巨大的差異而無(wú)法 互相交互。xml其實(shí)正是為了解決這種結(jié)構(gòu)交互困難而產(chǎn)生的，所以我更希望看到基于xml的工作。而在xml的形式下，能夠?qū)嵤┑慕Y(jié)構(gòu)變換現(xiàn)在也在不斷發(fā) 展當(dāng)中，AOP, XSLT等等。

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!248.entry

     物理和數(shù)學(xué)的新分支的產(chǎn)生多半有著哲理性的開(kāi)端，而軟件中OO技術(shù)的興起想必也是有一定的哲學(xué)基礎(chǔ)的。但哲學(xué)是一種整體的，超越的認(rèn)識(shí)，當(dāng)我們?cè)趯?shí)際的應(yīng) 用中走得越遠(yuǎn)，就會(huì)發(fā)現(xiàn)現(xiàn)實(shí)的操作距離哲學(xué)的理想越遠(yuǎn)。早期面向?qū)ο罂偸枪拇祵?duì)現(xiàn)實(shí)世界的直接表達(dá)，鼓吹Object,Class的本體論含義。但現(xiàn)在我 們已經(jīng)可以清楚的感覺(jué)到面向?qū)ο蟮恼軐W(xué)隱喻存在著本質(zhì)上的困難，而軟件希望作為真實(shí)世界的翻版也必然面臨著建模的本質(zhì)性問(wèn)題，即任何一個(gè)單一的模型與事實(shí) 相比總是簡(jiǎn)化的，貧瘠的。通過(guò)無(wú)限多自恰的模型構(gòu)成的概念包絡(luò)，再加上無(wú)法用技術(shù)手段表達(dá)的哲學(xué)升華，我們才達(dá)到了所謂不隨人的意志轉(zhuǎn)移的客觀世界。軟件 只能是客觀世界的一部分，而不可能是客觀世界的鏡像。
    OO技術(shù)已經(jīng)得到了深刻的發(fā)展與應(yīng)用，實(shí)際上現(xiàn)在可以不再總是需要一件哲學(xué)的外衣了。我一直強(qiáng)調(diào)繼承(inheritance)是一種推理技術(shù)，而接口 (interface)是一種正交分解技術(shù), 希望拋開(kāi)OO的詮釋而從數(shù)學(xué)上為OO技術(shù)找到根基。 無(wú)論是推理還是正交分解，我們都可以在數(shù)學(xué)上嚴(yán)格的證明它們的好處， 因此OO必然是一種好的技術(shù)。至于它對(duì)現(xiàn)實(shí)世界的表達(dá)能力，那是另外一個(gè)獨(dú)立的問(wèn)題。我的這種思想深受測(cè)度論(measure theory)的影響。測(cè)度論中對(duì)于概率的定義是純粹數(shù)學(xué)化，滿足一定條件的數(shù)學(xué)量就定義為概率。 至于它是否對(duì)應(yīng)于我們?nèi)粘Ｋ季S中的概率概念，那是使用者的責(zé)任，那是物理學(xué)所面臨的問(wèn)題。只有通過(guò)這種公理化的定義，測(cè)度論才擺脫了概念完備性與自恰性的 問(wèn)題，才擺脫了哲學(xué)上的循環(huán)論證。當(dāng)然，詮釋問(wèn)題在物理學(xué)中仍然是一個(gè)非常嚴(yán)重的問(wèn)題, 例如對(duì)于量子力學(xué)的Copenhagen詮釋的爭(zhēng)論從未間斷過(guò)，只是對(duì)于數(shù)學(xué)層面上的操作過(guò)程一般還能保持共識(shí)。當(dāng)然，說(shuō)的深入一些，即使數(shù)學(xué)上的定義也 未必是邏輯上必然的。為什么實(shí)數(shù)軸是完備的，為什么1.999999999...的極限是2, 這實(shí)際上是一個(gè)公理: 選擇公理(axiom of Choice), 等價(jià)于Zorn引理。