canonical

    最近強調彈性設計的比較多，大概是因為需求的多變太令人撓頭了吧。但從道理上說，一個良好的設計必然是剛柔并濟的。所謂沒有規矩不成方圓，你能想象沒有鋼 筋骨架結構的高樓嗎。在基礎核心架構方面特別需要適當的剛性和足夠的穩定性，需要用接口明確表達出將用到的假設。內核穩定了，固化了，外圍的aspect 才能安全的織入到系統體系架構中來。象變形金剛那樣的自由組合變化的結構（在流動結構與固化結構之間轉換）目前還只是一種幻想。

    強類型語言在控制大型系統的核心方面還是遠勝于弱類型腳本語言的。有些人認為單元測試可以取代編譯器的強類型語法檢查，這完全是一種臆想。程序的正確性應 該在不同的層面上得到約束，驗證，而不是一古腦的推到單元測試那里。在單元測試中對于概念一致性的保障是絕對無法與靜態類型檢查相比的。類型一致性的檢查 在編譯器的幫助下以非常低的成本就可以進行，而如果要在單元測試中實現同樣的約束，成本要高得多。有一點我們應該明確：除了功能實現代碼，其他任何文檔， 代碼都應該是多余的。為什么需要單元測試，那還不是因為沒辦法嘛。

   我其實很少談到OO這個概念，一般情況下我只提結構的表達與結構的控制。軟件開發是一個從二進制指令構造出一些高級結構的過程。無論是PO, OO, 還是XO, 只要它能有效的降低這種結構構造過程的復雜性，能夠增強我們對程序結構的表達和控制能力，那么它就是有價值的。在我看來，繼承（inheritance) 必然是有用的，因為它是一種表達推理結構的方式而無論它的概念詮釋是什么。行為函數聚合在對象的名義下是有意義的，因為它使得這些關聯得以明確化，靜態 化。為什么函數式編程是有效的，它和OO是什么關系。說白了，FP能夠方便的表達OO不易表達的結構。xml與OO是否是沖突的？xml能夠方便的表達結 構，通過dtd或者xml schema又可以方便的實現對結構的約束（動態的類型系統?)。
    級列設計理論要求我們所有的討論必須在一個統一的模型（最廣義的模型）下進行。OO與非OO的思想其共同之處是什么，它們在什么層面上是統一的？無論是 OO還是PO，都可以歸結為結構問題。所以我多談結構，少談OO。兩個不同的概念，可能意味著它們處于復雜性的不同級列（可以實現平滑的過渡），也可能意 味著它們之間是正交的，互補的

                                      

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

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


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

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

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


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

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

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

    web開發是個既先進又落后的領域。很多人面對這種矛盾的情況，難免思想上會出現混亂。關鍵是要認清技術的本質而不要被OO是否必需等抽象的討論所迷惑。

web程序需要完成  html <--> java 之間的映射，在界面越來越復雜，越來越多變的今天，這項工作也變得越來越困難。按照級列設計理論的觀點，我們應該去尋求一些中間的過渡步驟。在 witrix平臺中，tpl模板引擎正扮演了這種中間角色。通過tpl模板我們實現了如下映射路徑

html <--> tpl <--> java

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

在witrix平臺中因為存在著tpl這一強大的抽象層，使得我們對于ajax的支持可以采取更加靈活的方式。
ajax(Asynchronous JavaScript + XML)的標準結構是
html <--> js <==> xml <==> java

在 這種結構中通過xml信道的只是數據，而界面的表達邏輯與展現邏輯完全由js來控制。這種結構發展的一個極端是所有的界面展現結構都由 javascript動態構造出來，而完全喪失了html靜態描述的特點,喪失了所見即所得的設計。與直接實現html<-->java之間 的映射情況類似，直接實現 html <--> js之間的映射也是困難的，盡管dom模型的支持可能使得js映射的難度要低于java映射。

在witrix平臺中ajax的方案為
html <--> js <==> tpl <--> java

即tpl取代了ajax標準方案中xml的位置，使得映射過程的復雜性得以分散化。

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

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

test.tpl文件的內容
＜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具有強大的結構構造能力，在這里我們以非常小的代價實現了tpl片斷的定義，例如test.tpl中的partA部分。這里通過id訪問tpl片斷就如同js中通過id來訪問html片斷一樣。
最后提一個很重要的思想：大量零碎的代碼片斷需要集中存放，否則人的精力會被耗散。一個反例就是struts中的action, 明明只干那么點事，偏偏要占據一個單獨的java文件，占據大量單獨的配置條目，最終給程序員帶來很大的困擾。

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

web開發很大一部分工作就是建立這兩個結構之間的關系。即我們需要
html <--> java

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

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

  如果一個東西看起來象花生，聞起來象花生，吃起來也象花生，那它究竟是不是花生？ 如果兩個事物在所有可觀測行為上都表現一致，那兩者的本質是否統一就成為了一個不可證偽的問題，從而處于科學范疇之外。而從人的機會主義傾向來看，我們理 所當然的會認為這兩者是同一概念。我們以觀察來認識世界，當然也就是以行為來界定事物。問題在于，我們在理論上要以事物的所有行為來界定它，而我們目前觀 測到的又永遠只是它的部分行為。在泛函分析分析中，有一種弱（weak)等價的概念，兩個函數如果與某個空間中所有函數的作用（內積）的結果都相等，則這 兩個函數在此空間中就是弱等價的。swartz正是通過這種方法定義了廣義函數，為delta函數在數學上建立了嚴格的基礎，回避了delta函數的本質 性定義困難。在物理學家看來，delta函數當然是個客觀存在的實體，而在數學家看來，它只是通過分布間接定義的概念。（當然，部分研究非標準分析的數學 家認為廣義函數兜了個大圈子）
    接口(interface)與類(class)相比，接口的概念完全是由其行為定義的，而類還涉及到其封裝了的成員變量，這些變量的作用在繼承的時候會隱 蔽的表現出來。毫無疑問，接口所代表的概念是比類變得"淺薄"了，它是明確暴露的行為切片而不是象類那樣欲遮還羞的實體定義。

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

概念解釋：
DSL(Domain Specific Language): a limited form of computer language designed for a specific class of problems, 例如SQL語言，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不是一個新的提法，不過隨著前段時間MDA(Model Driven Architecture)概念的熱炒，LOP似乎終于熬到了應用層面。Sergey Dmitriev的文章中批評了主流程序語言的不足，大概有這么幾條：
1. 通用語言表達能力(expressive power)很差，Time Delay to Implement Ideas
2. 領域概念的表達分散在實現代碼中，整體圖像迷失，因而Understanding and Maintaining Existing Code很困難。
3. 類庫等不是用領域概念表達的，因而Domain Learning Curve很陡峭。

這 些都是標準的陳詞濫調。地球人都知道，從問題描述到軟件實現之間存在著巨大的邏輯障礙，這種障礙有一部分是本質性的，即源于我們認識中的創造性因素，而另 一部分是技術性的，即源于我們使用的技術手段的限制。我們所能想到的解決的辦法就是盡量提高解決方法的抽象層次, 提升到所謂的領域層面，從而消解技術性障礙，同時輔助創造性發展。當我們的腦子里不再充斥著各種技術性細節的時候，大概就可以集中精力做些創造性工作了。 LOP把這些老帳又翻出來，到底它提供了什么新意？下面我們簡要分析一下LOP方案中概念的含義。

1. 領域(Domain)。
    計算機語言與自然語言在使用上是有著深刻不同的。自然語言只是傳遞著信息，而計算機語言還要負責具體干事情，即計算機語言要同時說明怎么做和怎么用。做與 用這是兩個不同的領域，例如我現在編了一個時光機器的軟件，上面就一按鈕，只要輕輕一按，嗖的一聲我就回到了500年前。怎么樣，使用簡單吧，但實現呢？ 我們當然希望在一個領域中使用最適合它的描述方法和控制指令。目前主流語言都是面向機器實現領域的(是實現領域的DSL?)，加上Von Neumann串性化體系的限制, 強迫我們用動態過程來實現靜態概念，更加劇了它對使用領域描述的不適應性。我們所要做的就是將做與用盡量分離，但同時盡量增大用的靈活性，domain representation不僅僅給最終用戶用，還給程序員用。能在使用領域概念范圍內解決的問題，我們不要將其拖延到實現領域。在領域間進行轉換，總 存在信息轉換成本，甚至會造成信息失真。例如，一幅畫看起來結構很簡單，但是用自然語言描述起來都相當困難，更別說轉換為計算機語言了（當然，這個例子很 有可能是誤導的，因為涉及到不同的感官，其中的區別是非常深刻的，無法用單一的原因去解釋）。所謂領域區分，最重要的還是使用領域與實現領域的區分（不同 的復雜性，不同的表現形式...），而不僅僅是業務領域與計算機領域的劃分。在業務領域內部我們也要區分使用與實現。

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

    封裝為tag之后，使用形式變為
        ＜app:選擇用戶 部門編號="1" /＞
    經過轉換之后，這里的調用不再是API含義，不再是說明怎么做，而是描述用什么。tpl中的標簽可以使用調用時明確指定的參數，也可以從全局 context中導入隱含的變量，從而依賴于所在領域的假定。例如，我們的很多界面控件需要與后臺交互，依賴于后臺jsplet框架，因而這些tpl標簽 選擇自動導入$thisObj和objectName等變量。領域抽象與context依賴其實正是DSL的精華所在。
    (關于DSL，有些人可能會將其等價于規則引擎(rule engine), 這其實是一種誤解。規則引擎實現的是條件空間的分解與合并，它是一個獨立的技術，與DSL并沒有必然的聯系)

3. 語言工作臺(Workbench)
    Workbench是LOP的使能技術。我們希望自由的構造DSL,必然需要對結構具有強大的控制能力。而文本語言總是線性的，靜態的。看看現在對自然語 言的研究吧，顯然我們對于怎樣在線性文本中塞入更多的結構缺乏本質性的認識。我們人為構造的語言，限于表現形式，其結構都異常的貧乏。計算機的腦袋是簡單 的，于是，我們想到增加維度，通過復雜的工具配合，來實現多層次，多視角, 動態的結構控制。在我看來，很多時候這是一種無奈之舉，當然也確實是目前唯一可行的辦法。
    工具復雜了之后，造成的本質性障礙在于結構上的僵化，其具體表現之一就是所謂的廠家鎖定,一種結構融合上的困難。不同廠家產品的結構具有巨大的差異而無法 互相交互。xml其實正是為了解決這種結構交互困難而產生的，所以我更希望看到基于xml的工作。而在xml的形式下，能夠實施的結構變換現在也在不斷發 展當中，AOP, XSLT等等。

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

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