購買應用集成工具需要好好看看你的公司需求，知道從供應商里面要尋找哪些關鍵功能。

購買應用集成工具意味著要平衡兩大使命(推動工作的工具以及處理組件的工具)、三大驅動力(業(yè)務敏捷性、組件化以及云)，還要考慮應用運行所在的技術和業(yè)務框架。這些驅動力的相對重要性將決定應用集成工具所需功能的平衡。所有這些信息對于詢價書(RFP)或更為正式的購買流程中的溝通都非常重要，但是你的購買決策中某些領域的一些特別重要的地方我們會在下面突出說明。

記住，關鍵一點是應用集成所有這三個驅動力的重要性都在增加，并且擴散到了業(yè)務的更廣范圍，因此表明你將需要對所有這三大驅動力做出響應—業(yè)務敏捷性、組件化以及云計算，最終都得如此。

收集信息和做出產品選擇的過程交織著技術和業(yè)務框架問題。這個過程從定義跨應用邊界(既包括流，也包括應用被發(fā)現(xiàn)的位置)傳遞工作的最佳策略開始。它必須適應你的業(yè)務目標，你當前的應用接口和實踐，以及你的技術趨勢。往下讀的時候，記住，做出決定的最好辦法不是根據技術特性，而是根據那些特性如何滿足需求來做出。

工作流包括兩類產品

“工作流”是在應用之間移動信息的機制，可分為兩大產品門類。第一個是服務或消息總線，可提供類似于高速公路機制，讓應用和組件在上面跑，第二類是用于顯式鏈接應用的直接耦合工具。

如果是根據可變業(yè)務規(guī)則在應用中控制業(yè)務事務的話，服務或消息總線產品是最好的，這意味著在需要可觀的商業(yè)敏捷性時它們最合適。好的工作流產品會通過提供控制總線的業(yè)務流程語言，以及提供適合于當前和未來業(yè)務運營的事務負載支持來適應業(yè)務敏捷性的驅動者。在現(xiàn)實環(huán)境中，這一組合是往往在歸類為“服務總線”的產品中最常見，但最好還是看看服務和消息總線產品，并根據功能自己將它們分類一下。你的產品選擇應該根據業(yè)務語言操控的靈活性以及性能來對產品進行分類。

應用的直接耦合意味著一個應用對另一個進行“調用”來交接工作。在用的有三類主要的應用調用結構：

遠程過程調用(RPC)或基于對象面向服務架構(SOA)，也叫Web服務表述性狀態(tài)轉移(REST)，常用于互聯(lián)網

因為應用必須針對特定的直接耦合架構來編寫，大多數(shù)情況下選擇架構是不可能的，這只是一個產品。直接耦合的辦法主要的區(qū)別在于用于瀏覽有用的組件、安全和可靠性、以及事務控制(多階段提交)的標準功能有多少植入到了耦合機制里面。SOA和基于CORBA的對象代理結構是最復雜的，也是最難使用的，但為應用間的工作交換提供了標準機制。注意，這兩個結構服務或消息總線也可以用于與應用的連接。

直接耦合的產品選擇應該首先確定在用的軟件或待購軟件能否適應產品體現(xiàn)的結構，以及產品是否支持結構的全功能集而不是子集。大多數(shù)情況下，除非你的業(yè)務對未來變更的敏捷響應幾乎沒有需求，否則應用往往會發(fā)展到超出結構限制的范圍，因此要確保你的產品能適應這種發(fā)展。

在工作流策略中你的主要驅動力處于業(yè)務敏捷類。你的公司的敏捷性或者對敏捷的渴望需要與供應商溝通清楚。

考慮目錄策略

部署在服務器并通過網絡連接的應用或應用組件需要進行尋址以便將工作傳遞給它們。這一地址被存放到目錄里面，可通過瀏覽或/及應用的邏輯引用名來訪問。

目錄必須支持這兩種訪問，以便獲得一個應用地址，以及更新，以把部署時應用或組件的正確地址存進去。選擇目錄策略時最重要的考慮是與你的應用和操作過程預期用到的訪問及更新機制的兼容性。

如今最常見的目錄是互聯(lián)網的域名服務(DNS)組件。DNS只提供基本的邏輯到物理轉換，對于更為復雜的工作流連接來說是不夠的。UDDI結構主要是為了SOA中復雜工作流的連接而開發(fā)的，不過它從未獲得廣泛的接受，可能的話應該盡量避免。LDAP是大多數(shù)提供DNS之上的現(xiàn)代目錄服務的基礎。

在選擇目錄產品時，第一個需求是要支持兼容在用或規(guī)劃的訪問及更新機制的目錄策略。其次，要看性能;看目錄產品能否服務應用可能生成的請求數(shù)量。你的公司組件化的使用以及云是選擇目錄產品的重要驅動力，也是需要與未來供應商進行溝通時最重要的一點。

需要考慮的技術影響

應用集成是更廣的組件集成問題的子集。你的應用集成策略應該盡可能與你的組件集成策略兼容—如果可以的話，要做到完全兼容。

確保集成方案兼容性的方法之一是考慮主要軟件供應商作為你主要的應用集成來源，除非被證明不可能。所有的主流軟件/系統(tǒng)供應商，包括戴爾、惠普、IBM、微軟、Oracle、RedHat及SAP現(xiàn)在都開發(fā)和分銷組件化的軟件，因此也提供集成工具。一定要找這些來源進行應用集成工具的報價，并用你的主要軟件供應商的能力作為參照來對比其他的產品選項。

如果你沒有統(tǒng)一的軟件方案，就得創(chuàng)建一個圖表來顯示當前軟件已有的集成選項。公司很少會調整不斷變化的軟件來建立統(tǒng)一的集成模型—選擇支持你現(xiàn)在使用的所有集成選項的工具會更好。

最后要考慮的技術問題是虛擬化和云。在傳統(tǒng)IT里面，應用及其組件往往是位于同一位置的，或者至少位于數(shù)據中心綜合體內的。它們往往還會呆在被放置的位置，除非出現(xiàn)硬件失敗。而在云端，未滿負荷的橫向擴充會復制出多份應用副本，而地理位置分散的副本可以支持分散員工擁有更好的體驗質量。云使得高效工作分布變得更加困難，因為它把應用分成了不同的塊，并給目錄管理增加了一個動態(tài)維度。

需考慮的業(yè)務影響

IT決策必須適應高度易變的業(yè)務環(huán)境。通常，這應該把你的決定偏向集成的工作流模式，通過對于業(yè)務流程語言的強勁支持來操控基于業(yè)務因素的工作。這也意味著你有可能需要所有的工具具備更高的性能表現(xiàn)，以及每個產品具有范圍盡可能寬的集成接口和選項。

你正在朝著成為更敏捷業(yè)務，以及組件化或向云轉變，這一事實說明你正面臨著相當激烈的IT實踐變化，激烈到意味著有可能值得去檢查一下部分底層的應用選擇，并考慮作出可改進整體敏捷性的變化。

要經常看看你的應用工作流的發(fā)展趨勢。事務或支持員工數(shù)的增加也許會對應用的體驗質量產生影響，除非你的工具能夠跟上節(jié)奏。確保與未來的供應商就當前和預期的活動率進行溝通。

跟供應商框定你的選擇

應用集成工具提交RFP是沒有必要的，甚至可能是沒有成效的，除非你能把采購需求縮小為單個產品目錄。不過無論你做了什么，你都應該把自己的詳細需求跟潛在供應商溝通清楚。解釋好你明確下來的使命，選擇工作流或應用的直接耦合的原因，以及你的技術和業(yè)務框架

從以上析取出來的技術需求，包括應用/組件接口支持，基于業(yè)務策略操控工作的支持，以及產品旨在滿足主流供應商特定軟件框架的程度。然而，不要僅僅是提出這些問題，最好是利用本文提供的結構，讓供應商響應你自己的需求結構來獲得信息。

你的應用集成工具未來的成功大部分取決于供應商的愿景與你自己需求的復合程度如何。確保把你的交互愿景傳達給預期的供應商，確保要弄清楚他們的產品演進路線。一旦你確定了應用的發(fā)展路徑，你和你的供應商就要一起為之努力了。