一、引言
當今，各個企業都在想辦法提高自己的生產效率，對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頁面
。不奇怪，因為早期的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服務都相當有用，而且能被應用於許多不同的領域。但同時，它們又太「商品化」。換句話說，我可能並不在乎是誰提供的這些服務，而只想得到我所希望的資訊。另一方面，我會簡單地使用任何網路服務來實現把現金從我的經常帳戶轉到我的儲蓄帳戶嗎?我不會這麼做的。我首先需要建立對這種服務的信任，因此，我必須與提供該服務的供應商建立一定的關係。存在於我(消費者)和服務提供者之間的這種「信任圈」也正代表了企業內部及其合夥企業之間的關係。
四、AJAX+SOA技術結合
上面同樣的方式也可以為企業所採用，從而把他們的Web服務提供給更廣大的用戶群。透過一種Web服務市場，企業可以註冊各種Web服務—而這些Web服務通常僅能為企業內部或合作夥伴所使用。市場供應商顯然希望這種情況發生，但更重要的是，我們看到了一個機會—應用AJAX+SOA技術來驅動一類新的Web 2.0業務應用程式。
第一次，人們開始感覺到應用程式開發與SOA終於走到了一起。我們擁有透過可重複使用形式—SOA服務—加以描述的業務功能。我們擁有無所不在的連結—Web。我們擁有正在被證明成為新的應用程式容器的瀏覽器。我們在這類應用程式容器/瀏覽器中擁有一種程式設計模型—JavaScript。而且它們使用的都是開放式標準!我們還要求什麼呢?其實，還有其它一些內容。
我特別希望看到一種更快的基於所有以上技術的開發應用程式的方案—一種不必再依賴與SOA服務整合到一起的中間件即可建立應用程式的方法。這正是我所期望的網路應用程式的能力—「直接連接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對企業的回應。