作者：Donald F. Ferguson、Dennis Pilarinos、John Shewchuk 摘要：Web應用程序是非常常見的應用程序模型，它們將變得越來越普遍。幾乎所有大中型企業的應用程序都提供Web用戶界面。在本文中，我們將使用術語“企業”表示大中型企業、軟件供應商和集成商。桌面和客戶端/服務器應用程序越來越多地使用瀏覽器作爲UI引擎，並通過Web協議調用數據和服務。 軟件、應用程序模型以及Web本身都在進行革命性變革。這場變革對計算機世界的影響與客戶端/服務器模型或Web的出現相差無幾。Web將從連接用戶與站點提供的應用程序的工具發展爲具有以下特徵的模型： l 應用程序“在Web中”執行。 l 最終用戶開發自己的應用程序訪問Web，將其轉變爲用於訪問Web服務的最終用戶開發的工作空間。 本文重點介紹變革中的一小部分內容。其他文章將擴展此願景。 很多技術和趨勢都爲上述革命性變革提供了動力。比如：多核處理器；虛擬化；聯合很多設備的應用程序方案，如手機和平板電腦；面向服務的架構(SOA)和Web服務；Web 2.0；軟件即服務(Software as a Service，SaaS)。 我們將討論某些趨勢的影響，但我們主要側重於SOA、Web 2.0和軟件即服務(SaaS)。這些概念及其關係尚未得到廣泛瞭解。通常，這些技術似乎相互矛盾。本文介紹使這些概念成爲一個統一體的高級參考架構的元素。 上文所述的很多技術趨勢都得到了廣泛的認可和關注。本文討論爭議較大的第三個趨勢：無處不在的編程功能。很多高等學校和大學畢業生開始參加工作時都有基本的編程技巧，很多學生已經開發了簡單的PHP或Visual Basic應用程序並且構建了網站。專業人員的主要工作職責可能不包括編程，但是很多情況下，如果編程能夠使他們效率更高，專業人員也會簡單的進行編程。他們可能還會開發一些簡單的應用程序，因爲這樣比較“酷”。對於這個概念，我們將使用最終用戶編程這個術語。 最終用戶編程是機會開發的極端情況，它發生在企業中的各個部分以及業務範圍(LOB)中。LOB和團隊通常構建簡單的“快捷而粗劣的”SharePoint或PHP應用程序，這些應用程序可以通過擴展已封裝的應用程序或企業範圍核心應用程序解決直接業務問題。 機會開發和系統開發形成了對照。系統開發是模型驅動的，總是需要進行需求收集、用例和股東會談，包括質量和保證的應用程序開發生命週期等等。系統開發是企業開發團隊（“CIO團隊”）的主要模型。很多封裝的應用程序開發人員（獨立軟件供應商或ISV）和系統集成商(SI)也提出系統解決方案。 在機會開發和系統開發的企業之間有一個拉力。如果最終用戶編程變得很普遍，則這個拉力將會增大。最終用戶將不滿足於等待系統開發團隊開發或修改解決方案。我們介紹的參考架構提供了一個協調機會開發和系統開發的方法。 我們將使用一個方案來演示參考架構。形成和支撐該架構的核心元素是Internet 服務總線(ISB)。參考架構包含很多元素，但是，本文僅提供ISB的詳細信息。其他文章將介紹其他元素。 目錄 方案以及機會開發和系統開發 Dave 經常出差，他首先要使用酒店和航空公司。在出差的城市中，他使用當地的汽車服務，並且預訂餐館。與朋友、家人和同事的協作也是非常重要的。Dave使用各旅行提供商的網站制訂和更改旅行計劃。 Dave的旅行管理涉及很多通過網站與旅行提供商進行的手動交互任務。他必須手動協調跨站點的任務，並且必須手動在字段之間剪切和粘貼數據。而且要符合一定的先後順序邏輯，例如，必須先預訂餐館和汽車服務才能到達餐館。Dave的行爲就像一個複雜的應用程序或企業應用程序集成(EAI)解決方案。手動工作非常單調乏味而且容易出錯。Dave有基本的編程技巧，因此他決定編寫一個小mashup。此mashup通過客戶端網頁腳本或簡單的HTML剪輯使用旅行提供商的網站（圖1(a)）。此mashup使Dave的生活變得更加輕鬆，並且使Dave的工作效率更高，因爲他在管理旅行方面花費的時間更好，而將更多的時間花費在他的工作上。此mashup也非常酷，給他的朋友留下了很深刻的印象。 Mary和Ludwig喜歡這個應用程序，他們從Dave那裏獲得了代碼。他們想擁有不同的UI，但希望共享代碼。因此，他們將UI與網站訪問分離、編寫腳本並通過實現簡單的模型視圖控制器版本進行緩存，從而改進了這個應用程序（圖1(b)）。改進後的程序還可以通過其他設備（如PDA或手機）進行訪問以重用代碼（圖1(c)）。最後，他們決定將模型層移動到部門Web服務器並實現一個簡單的Web應用程序。這樣便使多個人能夠訪問信息，以獲得幫助。 朋友有機會構建一個複雜的應用程序，這是一個簡單的僞EAI解決方案。隨着能夠編程的專業人員的參與，這些專門的即時應用程序將變得越來越普遍。不僅僅有“酷的因素”，而且應用程序也將簡化單調乏味的任務。專業人員還可能爲解決短期的業務問題（如約定）構建“即時”應用程序。當用戶通過訪問現有數據庫和核心企業應用程序執行業務任務時，這些應用程序類似於電子表格的角色。 機會情境應用程序（situational application）將對企業系統應用程序交付產生深遠的影響。首先它將影響企業應用程序的開發。情境應用程序可能“依賴”核心企業應用程序，或採用意想不到的方法使用核心系統。這將使IT組織將某些“模型層”移動到企業服務器，以提高性能和完整性。 本質上，情境應用程序定義了驅動系統企業應用程序變革的用例。情境應用程序可以替換用於記錄用例的簡單實體模型，並且可以驅使正式的建模。 很多壓力使大量情境應用程序移動到企業服務器。可能有一些合作伙伴需要使用要求企業安全的應用程序。某些應用程序可能是重要業務決策的一部分，比如貸款審批。管理和遵從性將要求記錄數據訪問和輸入，並且保存這些應用程序各個版本的代碼。將情境應用程序移動到數據中心具有深遠意義。除了核心業務解決方案之外，數據中心還需要支持上百或上千個經常更改的應用程序。數據中心需要管理幾十個供大量用戶訪問的高負載核心應用程序服務器，以及上千個小型團隊使用專用應用程序偶爾訪問的虛擬服務器。 很多情況下，系統解決方案也使用機會應用程序。Dave認爲如果IT使用他的應用程序，這將非常酷。 總之，機會應用程序推動系統解決方案的發展，系統解決方案推動機會應用程序的完善（例如代表性狀態傳輸（Representational State Transfer，REST）-> Web服務）。這些動��還推動軟件即服務的發展，更確切的說是軟件和服務。軟件和服務提供了一個平臺，可以將系統解決方案和機會應用程序的開發和交付結合在一起。
企業服務總線 考慮當Dave正在從紐約旅行到達拉斯時，如果航空公司取消了Dave從達拉斯到舊金山的航班將會發生的情況。Dave將不能到達舊金山，他需要在中轉機場所在的城市停留一整夜。因此有必要更改酒店、餐館以及汽車服務預訂。Dave在下飛機時可以使用他的mashup簡化這些更改。如果在飛行時能夠自動重新預訂，那最好不過了（“更酷了”）。航空公司和航班監視站提供航班時間表的更新服務。理想情況下，Dave的應用程序將始終動態執行。應用程序將監視這些更新，並使用簡單邏輯響應事件，更改路線和計劃。 簡單的最終用戶應用程序未必總是修復路線，但大多數修復非常簡單。Dave只需手動處理複雜的情況，還可以批准飛行過程中他的應用程序自動進行的更改。 修復路線的常規應用程序方案是企業中常見的問題類型。例如，類似的問題也可能發生在購買定單和報銷單審批方面。下面這個方案就是複合應用程序的一個示例，它實現直接處理(STP)模式（參見參考資料）。企業執行系統方法來解決這些問題。圖2概述瞭如果航空公司、酒店、餐館、城市汽車以及其他系統位於企業防火牆中時，複合應用程序可能的樣式。運行時間相對較長的編排過程預訂航班管理系統發出的事件。該過程來回發送消息，並調用現有應用程序取消預訂、查詢空閒資源以及進行新的預訂。由於企業種類的不同，現有應用程序具有各種消息格式（C、COBOL等等）以及通信協議（例如，WebSphere MQ、SAP RFC）。
圖2：企業業務過程（單擊圖片查看大圖） 圖2所示的修復過程設計非常脆弱。例如，如果添加了另一個航空公司應用程序，則必須更改業務過程。還可以將業務過程與現有應用程序的特定消息格式和語言聯繫在一起。添加一個常規機制用於記錄與某些條件匹配的消息（例如，如果旅行者是管理人員，則記錄所有消息）是非常困難的。這種脆弱性導致企業應用程序架構發展爲企業服務總線(ESB)。 圖3概述了企業服務總線。應用程序適配器將現有格式和協議轉換爲標準的Web服務。這樣便將任何內容與任何內容連接的NxN協議/格式映射問題轉變成了N->1映射的問題，即將所有內容都轉換爲標準。ESB提供了處理服務之間消息流的其他功能。示例包括消息轉換、記錄和路由。
圖3：企業服務總線（單擊圖片查看大圖） 如果Dave公司的企業開發和業務部門決定，實現其旅行應用程序的重要性足以爲其提供資金支持，那麼這個企業團隊可以實現類似於圖3的應用程序。開發此係統解決方案有以下幾個問題： 1. 無法保證企業會對複合應用程序提供資金支持。可能還有其他更迫切的業務問題。 2. 系統開發涉及用例、某些形式的過程建模、會見股東等。這些都需要時間。 3. 航空公司、酒店以及其他應用程序都在企業之外。企業會非常慎重地考慮建立業務到業務的連接。即使業務合作伙伴實現了Web服務，企業也需要建立Web服務與合作伙伴交互的授權規則和審覈。企業將需要支持用戶身份管理、聯合身份驗證以及資料供應，因爲不僅管理員工在企業內部的身份，還要管理其在多個航空公司以及酒店中的身份。 4. 針對各個員工的喜好定製解決方案是非常複雜的。員工無法進行“DIY”定製。應用程序位於中央企業服務器上。IT專業人員定義和修改業務過程，而不是Dave。 如果Dave能夠實現一個簡單的個人版本的系統解決方案，這的確非常酷。如果我們概括ESB並將其視爲一種爲系統企業開發進行了優化的服務總線，那麼我們同樣可以設想一種爲機會開發進行了優化的服務總線。這就是Interne服務總線（ISB）。ISB更像是一個無處不在的分子。ISB將設備彼此鏈接、將設備鏈接到本地服務器、將網站鏈接到網站、將ESB鏈接到ESB，而且它本身就是一個ESB。ISB是一個用於“DIY”複合應用程序和業務過程的平臺。ISB還是一個軟件即服務(SaaS)的示例。 Internet服務總線 圖4概述了Internet服務總線的概念。（ISB的一個早期示例爲BizTalk Services；請參見參考資料。）ISB提供商類似於PHP網站託管公司。它們都提供在動態的應用程序平臺。PHP Web託管站點主要提供用於開發動態網站和與數據庫交互的Web服務的平臺。相比之下，ISB提供的平臺用於創建和部署集成其他站點提供的服務的複合應用程序。ISB、PHP Web託管公司以及服務型存儲（如Amazon的S3）都是支持基礎結構軟件即服務的應用程序的示例。這與Salesforce.com不同，它在一開始就封裝爲軟件即服務的應用程序。 核心ISB概念構建在統一資源標識符(URI)空間上。Dave的團隊處理了應用程序註冊問題，“擁有”了URI：http://ISB.net/DaveAndTeam。此根目錄下的URI表示應用程序集成點，它類似於Java Messaging Service中的目的地、面向消息的中間件中的隊列，或者發佈/訂閱系統中的主題。團隊通過將策略和功能與URI相關聯開發了一個ISB應用程序。此複合應用程序是一組URI、策略和功能。ISB提供了身份和訪問功能，用於控制哪些消息可以由誰發送給URI。身份和訪問功能就是將策略與URI關聯的示例。 例如，Dave可以選擇保留公共網站上某個顯示其旅行預訂的wiki頁面。Dave會希望控制對此wiki頁面的訪問。在他的個人網站上建立和維護身份驗證和授權數據庫是非常單調乏味的。如果Dave在多個網站上都有頁面和數據，則這個問題會變得更復雜，例如： l 驅動PHP站點的個人數據庫 l 使用http://www.twiki.org/構建的一系列協作門戶 l 存在於某個個人空間站點，如Windows Live Spaces (http://home.services.spaces.live.com/)。
圖4：Internet服務總線（單擊圖片查看大圖） Dave的朋友Don可以註冊ISB的身份組件並且創建一個用戶ID [email protected]。Dave可以使用該身份組件的Web UI指定Don可以訪問Dave的哪個ISB URI。Dave還可以定義組並授予組訪問權限。Don登錄到ISB之後便可以訪問URI。ISB簡化了Dave的安全管理，因爲他可以維護一箇中央數據庫，然後授予“ISB”訪問其wiki以及其他資源的權限。ISB通過對其前面的ISB URI進行訪問控制保護實際資源。ISB的優勢在於，Dave擁有一個空間，可以定義和維護Web上所有與其“服務”有關的身份、組、資源以及訪問策略。 我們剛剛已經討論了通過網頁的顯式用戶操作。另一種比較常見的方法是讓參與複合應用程序的端點上應用程序使用Web服務API訪問ISB。 身份組件還將支持WS-Security的Security Token Service (STS)功能以及與其他STS的聯合。這樣便允許Dave管理未向ISB註冊的身份的訪問。如果foo.bar是一個Dave信任並且實現了STS的公司，則Dave可以爲經過foo.bar身份驗證的身份定義訪問策略。 一段時間之後，ISB將提供可以連接到URI的其他策略和實現。示例可能包括WS-Reliable Messaging或隱式消息記錄。此概念類似於服務質量策略與面向消息的中間件的關聯。 ISB構建於身份和訪問功能之上，爲應用程序（甚至包括位於防火牆之後的應用程序）提供“安全普遍的連接性”。這包括對廣泛的連接性模式和協議的支持。示例包括面向REST的HTTP、WS-*以及很多企業應用程序中的事件驅動模式。確切的說，ISB的連接性組件還提供了三個核心功能： l 中繼，使ISB和防火牆之後的應用程序之間能夠通信。有很多技術可實現該功能（Biztalk Labs，請參見參考資料）。中繼功能不再需要爲簡單方案建立系統跨企業連接。 l 協議，提供一組用於交換消息的公共協議，如WS-*或REST。ISB還提供使用不同協議自動連接端點的協議映射。例如，可以將RSS feed連接到WS-*消息連接，而不必修改任何應用程序。 l 功能，支持將簡單的類似於ESB的功能與URL關聯。示例可能包括多播、WS-Eventing、持久消息等。 連接層在基礎結構技術級別上運行。它避免了由於不同的“plumbing”（例如，REST與WS-*）而引起的複雜性，從而簡化了解決方案開發。必須在該級別實現的基礎結構集成的項目會導致大量成本和風險。ISB解決了這些問題。 連接層不感知應用程序級別元素和消息格式。構建複合應用程序要求適應連接的服務所實現的各種消息格式。ISB功能的一個示例就是將HTTP GET中的參數轉換爲XML消息中的元素。ISB提供一個簡單的工作流程（服務編排），該流程提供對應用程序級別映射的支持（圖5）。
圖5：ISB消息處理（單擊圖片查看大圖） ISB爲簡單的功能提供了一組模板“活動”。工作流程是一個由實例化的活動模板組成的圖形。假設航空公司通過RSS feed發出了航班狀態，並且Dave的部分應用程序希望收到WS-Eventing通知以便更新。連接層支持將RSS與WS-*集成。仍然有必要將消息負載從RSS格式轉換爲Dave的應用程序所期望的XML事件格式。通常，ISB將提供一個可配置的、可重複使用的活動模板，用於將RSS轉換爲XML映射。 另一個常見的活動模板是基於選擇的路由。Dave的應用程序可能發出一個取消汽車預訂的消息（ID=1234）。如果一個城市汽車服務的預訂代碼以“LE-”開頭並且另一個以“OL”開頭，則Dave的應用程序可以將取消事件發送到一個ISB URI。然後，選擇器處理該消息並將其路由到相應的端點。 組合這些活動以便處理更復雜的消息是非常有用的，這將是ISB的一個共同功能。作爲示例，圖6顯示了Dave定義的用於接收取消汽車預訂消息的URL上的活動： 1. 使用WS-*接收XML格式的取消消息。 2. 提取預訂ID元素並在表中查找前綴。 3. 將消息轉換爲城市汽車服務的期望格式，即 a) 用於某個提供商的HTML電子郵件 b) 用於另一個提供商的HTTP POST。
圖6：ISB消息處理（單擊圖片查看大圖） 構建消息處理功能非常簡單。很多常見應用程序方案都是模式和模板的簡單實例。ISB提供商將提供一個簡單的基於Web的應用程序開發工具，該工具允許開發人員通過Web表單選擇活動模板並設置配置參數。對於路由，Web表單將允許開發人員指定路由表中路由的消息字段和值。一段時間之後，ISB將提供更強大的工具，如BizTalk中的消息處理工具。 消息處理（路由、轉換等等）的功能非常強大，足夠供很多應用程序方案使用。但是，對於其他應用程序來說，需要進行簡單的順序和流程控制。考慮當Dave進退兩難時在達拉斯預訂酒店的任務。該過程的簡單描述如下： 1. 向酒店鏈AAA發送預訂請求 2. 接收響應。 3. 如果成功，則退出 4. 向酒店鏈BBB發送預訂請求 5. 如果成功 工作流程活動藉助控制流（while、if ... then …等等）的活動模板擴展消息處理。ISB將不斷增加對簡單工作流程的支持，以擴展基本消息處理。 工作流程似乎是比較複雜的概念，系統企業工作流程解決方案功能強大，但比較複雜。但大多數專用應用程序、機會應用程序的工作流程都非常簡單。結構並不比簡單的PowerPoint圖表複雜。存在很小的一組“剪貼畫”用於連接和圖形，開發人員在圖形上設置屬性以表達活動的行爲。 大多數工作流程傾向於使用嵌入的列表結構。這樣便可以使用簡單的工具構建工作流程。簡單的XSD可以提供定義嵌入列表的工作流程XML文檔的結構。虛擬工具允許開發人員指定活動及其實現，或者對外部服務的連接。很多開發人員都熟悉此模型，原因是Web UI框架通常提供類似的頁面流和轉換的概念（例如，Struts）。 系統工作流程解決方案通常比較複雜，因爲它們都是任務關鍵型解決方案，支持許多人使用的應用程序。過程建模和引擎必須能夠表示過程的所有功能，並且能處理複雜的錯誤條件、審批等等。相比之下，對於大多數專用機會解決方案，很少人使用此工作流程，因此該團隊不斷修補它以便進行改進。 服務級別目標 在ISB上部署應用程序的企業希望定義服務級別協議(SLA)，用於指定響應時間、吞吐量、可用性等等。SLA將確定ISB提供商收取的費用。爲任意應用程序實現SLA這一常規問題常讓人感到棘手。但是，ISB的任務更加簡單，因爲它不部署任意用戶代碼。爲策略、發佈/訂閱、工作流程活動等實例化和配置的預定義模板限制了應用程序。這簡化了實現SLA、可預測成本以及完整性的過程。 機會應用程序的軟件和服務的參考架構 圖7展示了一個高級概覽，將本文所述的內容結合在一起。首先，Internet服務總線是無處不在的，它連接所有系統和服務器。將存在很多複合應用程序，這些應用程序中的一些元素在“ESB”上，另一些在ISB上。多組織複合應用程序是一個非常明顯的示例，它可以動態將元素部署到ISB上。另一種可能是在短時間內存在一個組織複合應用程序。例如，企業使用複合應用程序管理內部會議。與獲取、安裝、配置和支持硬件和軟件以“靜態”運行應用程序相比，重新使用預先配置且“動態”安裝的軟件平臺效率更高。
軟件和服務，以及Internet 服務總線
結束語
參考資料
關於作者.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
圖7：生態系統和業務模型（單擊圖片查看大圖） 如果企業在多個會議中重新使用專用應用程序，則系統解決方案可能來自於機會解決方案。機會解決方案爲系統解決方案提供了一組具體的用例。它還可以提供一些指標，用於確定應用程序的哪些方面經常使用。 第三方將增值服務連接到ISB。第一種類型的服務將是基礎結構服務，如更強大的工作流程引擎或支持XML查詢的數據庫。開發人員可以將服務連接到其應用程序中的URI，以在其解決方案中包含這些服務。這些基礎結構服務說明了第三方如何通過提供高級基礎結構作爲服務加入生態系統。 第二種類型的服務將是可重複使用的業務服務，例如，用於維護產品信息和目錄的預建服務。另一個示例可能是安排集會的會議室。這個示例說明了第三方如何通過添加應用程序“構建塊”服務加入生態系統。ISB複合應用程序可以將複合應用程序中的URI連接到構建塊服務，以便使用構建塊。 最後，系統集成商和解決方案提供商將提供可配置的、可擴展的解決方案，即模板。第三方可能提供支持很多會議/大會管理功能的可配置的解決方案。封裝的應用程序供應商可以支持“試用”。潛在客戶只需“動態”實例化某個版本即可，無需發佈需要安裝應用程序和先決條件的CD。 社區是Web 2.0的一個重要方面。實際上，它是最重要的方面。基礎結構服務、基本應用程序構建塊以及解決方案模板也將通過與提供和共享代碼的ISB關聯的社區出現。社區還提供論壇，以支持自助服務並建立“軟件即服務”供應商的名譽。 軟件+服務 整個“軟件即服務”是一個神話。所有有意義的SaaS解決方案最終包含一些內部（on-premise）軟件，即它是混合的。實例化解決方案的某些元素將位於總線（例如，工作流程）中，一些元素位於連接到總線的服務中（如XML內容管理系統），一些元素將在內部“安裝”。幾乎所有使用ISB和SaaS的方案實際上都是內部（on premise）和外部（off-premise）軟件的混合。 還有一個例子，請考慮Dave用來在其應用程序中存儲路線的數據存儲提供商。始終使用遠程訪問來讀取/更新路線容易出現問題。存儲提供商將可能提供內部（on-premise）和on-PC軟件包，該軟件包已通過緩存、複製、版本控制等等優化了數據存儲。用一個術語表示混合模型就是“軟件+服務”。 幾種趨勢集合在一起從根本上改變了Web應用程序模型。目前，Web主要用於幫助人們連接到文檔和應用程序。最基本的改變是將Internet和Web作爲執行應用程序的平臺這一思路。具有基本編程技巧的專業人員編寫個人應用程序，通過該程序可以更加有效地利用Web。他們將與沒有什麼計算機知識的朋友和同事共享這些應用程序。隨之出現了社區，它通過社區提供了傳播個人解決方案“meme”的另一種方法。 不可避免的是，個人應用程序的元素將“走向全世界”。只要原因將是“虛擬”PC的廣泛使用，“虛擬”PC可以根據用戶和附近的設備進行組裝。虛擬PC不是在酒店房間中使用筆記本，而是通過旅行者的手機和TV、Internet連接以及房間中的鍵盤組裝而成。也有可能組裝虛擬機(VM)，��只包含執行特定方案所需的軟件。 VM還提供： l 應用程序隔離 l 實現類似於用戶管理個人計算機的方式的概念模型，進行最終用戶管理。 l 向外擴展基於多核處理器的自然剝離。 l 會聚這些趨勢的企業的優勢包括： l 大大提高員工效率和士氣。工作不再單調，業務價值任務更加突出，可能還比較有趣。 l 提高了靈活性和敏感度，因爲應用程序開發和修改可能發生在幾小時而不是幾個月之內。 支持這些改變的主要技術就是Internet服務總線。SOA、Web服務和mashup都能夠快速進行復合應用程序開發，這些應用程序集成、定製和擴展了基本的應用程序構建塊。在Web中支持這些複合應用程序是下一個重要飛躍，也是Web 2.0的核心方面。實現這個前提的關鍵元素在於Internet服務總線。除了支持靈活的應用程序開發之外，ISB還支持軟件提供商的生態系統。ISB的功能支持“編程”專業人員的加入，尤其支持自下至上通過社區開發長期應用程序。計算領域的統一理論是軟件和服務，而ISB是此新應用程序模型的基礎。 l Biztalk Adapter http://(zh-cn,2.microsoft.com/zh-cn/library/aa744368.aspx l Biztalk Labs http://labs.biztalk.net l 企業應用程序集成(EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration l 企業服務總線http://en.wikipedia.org/wiki/Enterprise_service_bus l Mashup http://en.wikipedia.org/wiki/Mashup_(web應用程序混合) l 模型視圖控制器http://en.wikipedia.org/wiki/Model_view_controller l OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/ l SAP RFC http://en.wikipedia.org/wiki/ABAP l 直接處理http://en.wikipedia.org/wiki/Straight_Through_Processing l Struts http://struts.apache.org/ l 用例http://en.wikipedia.org/wiki/Use_cases l WS-Eventing http://www.w3.org/Submission/WS-Eventing/ l WS-Security Security Token Service http://sts.labs.live.com/ l Zorro的ISB博客http://zorroisb.spaces.live.com Donald Ferguson博士是Microsoft CTO辦公室負責平臺與策略的高級研究員（Technical Fellow）。Don主要從事業務上發展和改革信息技術的角色。加入Microsoft之前，Don曾經是IBM Fellow和IBM軟件集團(SWG)的首席架構師，他主持SWG Architecture Board，主要研究產品集成、跨產品計劃以及新出現的技術，包括Web服務、模式、Web 2.0以及業務驅動開發。Don的主要愛好是Kenpo空手道。他在2005年12月贏得了黑帶。 Dennis Pilarinos是Microsoft的互聯繫統分部的高級技術主管。您可以從他的博客www.dennispi.com上詳細瞭解有關他的工作。 John Shewchuk領導Microsoft互聯繫統分部(CSD)的技術戰略團隊。在CSD中，John已經開發了Microsoft的應用程序平臺，包含在應用程序消息技術（如Windows Communication Foundation）、Web服務互操作規範（如WS-Security）以及身份和訪問技術（如InfoCard）方面的工作。John協同成立了Indigo團隊並且已經成爲跨行業互操作方面的主要驅動力。John與Indigo團隊的其他人員一起領導了Web服務架構和規範的開發，並管理與廣泛行業合作伙伴的技術協商。
軟件和服務，以及Internet 服務總線