一、引言
當今，各個企業都在想方設法提高自己的生產效率，并且對IT資產的重組也都在努力的探索當中。借助于面
向服務的架構(SOA)技術，IT組織已經在克服這些問題方面取得了一定的成效;但是，在大多數情況下仍然只是實現了整個IT服務組合的一小部分。目前，
有關這方面的大多數的努力也只不過是達到一種“剛剛滿足”的SOA應用狀況—在改進構建應用程序的能力以及使之與市場的結合更快更好更為便宜方面。而且正
如我們已了解的，要實現這些目標說起來容易做起來難。
二、傳統的基于中間件的復合應用程序
現有的事實是，SOA是一種中間件—而傳統情況下，中間件往往要依賴于更多的中間件才能把數據翻譯成一
種消費者友好的狀態。當你最后搞清楚構建一種融入SOA技術的復合應用程序不僅要求使用一種portal(中間件)而且還有可能要使用一種BPEL引擎
(甚至還是中間件)對它進行編排時，這當然使你非常失望。更糟糕的是，你有可能在一家發布UDDI注冊表和注冊大量Web服務的組織內工作。但遺憾的是，
在大多數情況下，還存在極少的實際消費這些服務的應用程序。怎么會是這種情況呢?
難道如果無法構建消費這些SOA服務的應用程序我們就該得出結論—什么東西出錯了嗎?是否是因為業務內
容開發者太難構建這種直接消費SOA服務的應用程序從而導致只好由其它的IT組織為我們創建這樣的應用程序呢?是否由于缺乏一種SOA監管架構從而使我們
猶豫不決?我想，我對上面所有問題的回答都是“是的”。而且存在一種非常突出的理由:僅由業務開發者消費和利用這種由IT組織暴露的SOA服務實在是太難
了!其實，真正存在的問題是缺乏一種容易的方法來在SOA上加入一種界面—而這正是把AJAX技術與SOA結合到一起的優點所在。
典型情況下，SOA服務被實現為一種松耦合的封裝和暴露業務功能的Web服務。這聽起來似乎非常直接，
但是實現起來卻非常復雜和困難。開發者經常在SOA服務的開發粒度方面討論不止;但是現在，大多數開發人員都一致認為“業務級”的開發粒度是最合適的。然
而，這仍然需要大量的相關領域專家加入并且要與業務內容合作才能最終確定這些服務的大小。
三、SOA的復興
幸運的是，最近人們又對SOA產生了深厚的興趣。也許企業最終意識到SOA確實能夠幫助給它們帶來巨大
幫助。也許這是由于更好的開發工具和在Amazon，Yahoo和eBay宣傳下的Web服務所致的緣故。也許它就是AJAX?不錯—這也正是本人撰寫此
文之原因。認真地說，我確實認為正是AJAX成為更新人們對于SOA的重新認識的一種重要的驅動力量，特別是在當今各種新技術混合應用領域。但是，這兩種
迥然不同的技術應該如何結合并連接到一起才能迸發出更巨大的力量呢?先讓我們來看一下Wikipedia對當前AJAX技術的定義。其中涉及到了Web頁
面，但是根本沒有提及SOA。其中的描述是:
“AJAX，代表了‘異步JavaScript+XML’，是一種創建交互式Web應用程序的Web開
發技術。其目的是，通過在后臺與服務器實現少量的數據交換從而使前端Web頁面感覺起來更具響應性;因此，每當用戶作出一個改變時，不必重載整個Web頁
面。其最終目的是進一步提高Web頁面的交互性、響應速度及可用性。”
此定義中沒有提及SOA并不奇怪，因為早期的AJAX應用主要集中在增強頁面的功能與可用性方面。這一
點已經在眾多應用程序，例如Google Maps，Flickr和Yahoo
Mail，中得到證實。然而，并不是這些面向消費者的應用程序使我對AJAX的潛力感到激動，而是運行于公司的防火墻背后的業務應用程序真正利用了
AJAX中的優點，因為它向我們展示了兩個關鍵特征:一個是客戶端編程模型，另一個是對服務器進行異步調用的易實現。這兩種關鍵能力—在客戶端(瀏覽器)
應用邏輯的能力和在不打斷Web頁面的情況下存取服務器數據的能力，正是它們拓寬了構建新的更為豐富的Web
2.0企業應用程序的如此眾多的可能性應用領域。
前面，我曾提及SOA缺乏一種界面。這也正是AJAX“介于”這其中的原因—它能夠給SOA加上一個體
面的外觀。在此，請讓我多作一些解釋。我們不妨考慮一下，如果SOA服務以在線方式出現的話，情況會怎么樣?這樣的服務通常需要在一個注冊表或倉庫中進行
注冊(如果我們幸運的話)，然后就可以用于消費。例如，我們不妨去看一下StrikeIron網站(www.StrikeIron.com)中所提供的內
容。StrikeIron已經成功地創建了一種針對普通大眾的“Web服務市場”。乍看起來，StrikeIron網站中的目錄機制很象一個小型業務應用
程序中所提供的列表。但是稍后，你就會意識到這并不是一些應用程序—它們實際上是一些Web服務。由一家公司針對廣大消費者提供WSDL/REST
Web服務的概念本身就蘊含了多種意義。但是，現在先讓我們來看一下這家公司所出售的內容。根據StrikeIron提供的信息(他們允許存取這些服
務)，它提供的大多數流行的Web服務包括:
·美國地址校驗
·全球短信服務
·銷售和使用稅
·電子郵件校驗
·逆向電話查詢
毫無疑問，所有這些Web服務都相當有用，而且能被應用于許多不同的領域。但同時，它們又太“商品
化”。換句話說，我可能并不在意是誰提供的這些服務，而僅想得到我所希望的信息。另一方面，我會簡單地使用任何Web服務來實現把現金從我的經常帳戶轉到
我的儲蓄帳戶嗎?我不會這么做的。我首先需要建立對這種服務的信任，因此，我必須與提供該服務的供應商建立一定的關系。存在于我(消費者)和服務提供者之
間的這種“信任圈”也正代表了企業內部及其合伙企業之間的關系。
四、AJAX+SOA技術相結合
上面同樣的方式也可以為企業所采用，從而把他們的Web服務提供給更廣大的用戶群。通過一種Web服務
市場，企業可以注冊各種Web服務—而這些Web服務通常情況下僅能為企業內部或合作伙伴所使用。市場供應商顯然希望這種情況發生，但是更重要的是，我們
看到了一種機會—應用AJAX+SOA技術來驅動一類新的Web 2.0業務應用程序。
第一次，人們開始感覺到應用程序開發與SOA終于走到了一起。我們擁有通過可重用形式—SOA服務—加
以描述的業務功能。我們擁有無所不在的連接—Web。我們擁有正在被證明成為新的應用程序容器的瀏覽器。我們在這類應用程序容器/瀏覽器中擁有一種編程模
型—JavaScript。并且它們使用的都是開放式標準!我們還要求什么呢?其實，還有其它一些內容。
我特別希望看到一種更快的基于所有以上技術的開發應用程序的方案—一種不必再依賴于與SOA服務集成到
一起的中間件即可構建應用程序的方法。這正是我所期望的Web應用程序的能力—“直接連接SOA”。這種“直接連接SOA”應該能夠穿過傳統型門戶屏障以
及重量級進程引擎進而直接(至少在概念上如此;稍后，我們將詳及)存取SOA服務。在此，我不僅是指Web服務，它也可能是BPEL編制服務，粗粒度
POJO服務，RSS回饋或任何其它能夠被暴露為一種“服務”的東西。當然，這其中的接口應該使用開放型標準暴露。
這種新式的開發和運行時刻模型創建了一種構建應用程序驅動的復合應用程序的新方法。它具有客戶機/服務器類型的吸引力，而沒有傳統型重量級客戶機/服務器所具有的沉重包袱。它運行于瀏覽器端并且能夠依具體要求而實現。
五、基于用戶的復合應用程序
在過去的幾年間，我們都聽說過“復合應用程序”這一概念。但是，大多數供應商卻在一直談論著“復合服務”—作為一種把他們的宿主服務重構成另一些更好用的服務或門戶應用程序的方法。讓我作個類比來作進一步的說明。
AcmeGrid，我們在本文中虛構的一家網格計算供應商，它提供一種服務—網格計算—能夠使你的應用
程序運行為一種服務。這家公司的顧客告訴它他們想通過一個方法實現把許多服務組合成一種粗粒度的服務。因此，很自然地，AcmeGrid發布了一種基于
Eclipse的AcmeGrid復合應用程序構造器(CAB)。有趣的是，CAB看上去很象一個BPEL設計器，但是與AcmeGrid發布的服務更為
緊密地集成到一起。盡管相當漂亮，但是，它并不是一種真實的應用程序，充其量也只是一種服務。實質上，CAB更象一個服務構造器。但是，當我們在努力構建
應用程序時有誰會需要一種服務構造器呢?不久，另一家虛構的供應商，我們暫且稱其為AcmePortal，宣布了它的Portal復合應用程序構造器
(PCAB)。它也發行了一種基于Eclipse的設計器;盡管它的外觀感覺也象一個BPEL設計器，但是，這個程序卻“知道”如何構建portal。在
許多情況下，一個portal和一個應用程序有一樣好的效果。但是，如果你硬性要求把一個portal轉換為一個應用程序的話，也只是徒然。
實際上，我非常想實現一種基于用戶的復合應用程序，而不是一種基于中間件的復合應用程序。為此，我需要
一種開發和運行時刻平臺—這種平臺不僅能夠使用AJAX和SOA，而且還能夠對這二者進行管理。一些經銷商又進一步推進了AJAX應用程序的概念—直接從
瀏覽器中調用基于WSDL的Web服務，其實質上是作一種SOAP調用。這種方法甚至還有一個名字—“客戶端/SOA”。這對于簡單的非企業或消費者應用
程序而言可能是不錯的，但是對于真正的企業程序卻不是這樣。為什么呢?因為當你直接從瀏覽器端調用Web服務時，監管功能等于交給了瀏覽器—這簡直就是
說，根本不存在監管問題。圖1展示了非監管的Web服務消費框圖。我還從來未遇到過一家不去監管自己的服務的企業，并且也不相信企業僅僅因為我們在技術上
實現非常有效就會允許這樣的事情發生。如果你不相信我的看法，那么你只須記住企業是從來不會對除HTTP和SSL以外的應用程序開放其防火墻的。不管我們
如何勸告系統主管，他們是不會開放其它端口的。
六、我們需要一種新型的平臺
由上面可知，我們所討論的不僅是停留在AJAX和SOA技術方面。其實，我們真正需要的是一種平臺，它
能夠為AJAX和SOA共存于企業之中提供必要的監管能力。這個平臺還提供站在客戶端角度消費SOA服務的能力，而且還能監管服務消費情況。圖2展示了如
何通過一個服務網關來監管Web服務。一個服務網關實際上是一個服務端抽象，它能夠代表客戶端監管并調節服務存取，這在剛才我們所討論的情況下是指基于瀏
覽器的AJAX應用程序。使用服務網關的漂亮之處在于，你并不被限制僅訪問在企業內運行的服務。這種服務網關能夠監管注冊到企業內的任何服務。在基于
WSDL的Web服務中，企業會注冊WSDL，而WSDL又提供在運行時刻到服務的綁定。這可能是運行在企業的數據中心的一種服務，但是它有可能與一個運
行于一家合伙企業的數據中心的服務一樣容易。如果企業允許(通過監管)應用程序存取服務的話，那么，這些服務運行于何處是無關緊要的。
七、結論
讀完本文，我希望你已開始欣賞起把AJAX和SOA結合到一起的強大威力來了—特別是這二者之間的共存
方式以及實現新式的具有企業要求的監管能力的基于Web服務的應用程序。我堅信，我們正在進入到一種充滿令人驚異的機會的新時代的前夕。Web
2.0時代社會性網絡，圖片共享以及各種標注技術都是偉大的，但是真正有影響力的還在于Web 2.0對企業的響應。