购买应用集成工具需要好好看看你的公司需求，知道从供应商里面要寻找哪些关键功能。
购买应用集成工具意味着要平衡两大使命(推动工作的工具以及处理组件的工具)、三大驱动力(业务敏捷性、组件化以及云)，还要考虑应用运行所在的技术和业务框架。这些驱动力的相对重要性将决定应用集成工具所需功能的平衡。所有这些信息对于询价书(rfp)或更为正式的购买流程中的沟通都非常重要，但是你的购买决策中某些领域的一些特别重要的地方我们会在下面突出说明。
记住，关键一点是应用集成所有这三个驱动力的重要性都在增加，并且扩散到了业务的更广范围，因此表明你将需要对所有这三大驱动力做出响应—业务敏捷性、组件化以及云计算，最终都得如此。
收集信息和做出产品选择的过程交织着技术和业务框架问题。这个过程从定义跨应用边界(既包括流，也包括应用被发现的位置)传递工作的最佳策略开始。它必须适应你的业务目标，你当前的应用接口和实践，以及你的技术趋势。往下读的时候，记住，做出决定的最好办法不是根据技术特性，而是根据那些特性如何满足需求来做出。
工作流包括两类产品
“工作流”是在应用之间移动信息的机制，可分为两大产品门类。第一个是服务或消息总线，可提供类似于高速公路机制，让应用和组件在上面跑，第二类是用于显式链接应用的直接耦合工具。
如果是根据可变业务规则在应用中控制业务事务的话，服务或消息总线产品是最好的，这意味着在需要可观的商业敏捷性时它们最合适。好的工作流产品会通过提供控制总线的业务流程语言，以及提供适合于当前和未来业务运营的事务负载支持来适应业务敏捷性的驱动者。在现实环境中，这一组合是往往在归类为“服务总线”的产品中最常见，但最好还是看看服务和消息总线产品，并根据功能自己将它们分类一下。你的产品选择应该根据业务语言操控的灵活性以及性能来对产品进行分类。
应用的直接耦合意味着一个应用对另一个进行“调用”来交接工作。在用的有三类主要的应用调用结构：
远程过程调用(rpc)或基于对象面向服务架构(soa)，也叫web服务表述性状态转移(rest)，常用于互联网
因为应用必须针对特定的直接耦合架构来编写，大多数情况下选择架构是不可能的，这只是一个产品。直接耦合的办法主要的区别在于用于浏览有用的组件、安全和可靠性、以及事务控制(多阶段提交)的标准功能有多少植入到了耦合机制里面。soa和基于corba的对象代理结构是最复杂的，也是最难使用的，但为应用间的工作交换提供了标准机制。注意，这两个结构服务或消息总线也可以用于与应用的连接。
直接耦合的产品选择应该首先确定在用的软件或待购软件能否适应产品体现的结构，以及产品是否支持结构的全功能集而不是子集。大多数情况下，除非你的业务对未来变更的敏捷响应几乎没有需求，否则应用往往会发展到超出结构限制的范围，因此要确保你的产品能适应这种发展。
在工作流策略中你的主要驱动力处于业务敏捷类。你的公司的敏捷性或者对敏捷的渴望需要与供应商沟通清楚。
考虑目录策略
部署在服务器并通过网络连接的应用或应用组件需要进行寻址以便将工作传递给它们。这一地址被存放到目录里面，可通过浏览或/及应用的逻辑引用名来访问。
目录必须支持这两种访问，以便获得一个应用地址，以及更新，以把部署时应用或组件的正确地址存进去。选择目录策略时最重要的考虑是与你的应用和操作过程预期用到的访问及更新机制的兼容性。
如今最常见的目录是互联网的域名服务(dns)组件。dns只提供基本的逻辑到物理转换，对于更为复杂的工作流连接来说是不够的。uddi结构主要是为了soa中复杂工作流的连接而开发的，不过它从未获得广泛的接受，可能的话应该尽量避免。ldap是大多数提供dns之上的现代目录服务的基础。
在选择目录产品时，第一个需求是要支持兼容在用或规划的访问及更新机制的目录策略。其次，要看性能;看目录产品能否服务应用可能生成的请求数量。你的公司组件化的使用以及云是选择目录产品的重要驱动力，也是需要与未来供应商进行沟通时最重要的一点。
需要考虑的技术影响
应用集成是更广的组件集成问题的子集。你的应用集成策略应该尽可能与你的组件集成策略兼容—如果可以的话，要做到完全兼容。
确保集成方案兼容性的方法之一是考虑主要软件供应商作为你主要的应用集成来源，除非被证明不可能。所有的主流软件/系统供应商，包括戴尔、惠普、ibm、微软、oracle、redhat及sap现在都开发和分销组件化的软件，因此也提供集成工具。一定要找这些来源进行应用集成工具的报价，并用你的主要软件供应商的能力作为参照来对比其他的产品选项。
如果你没有统一的软件方案，就得创建一个图表来显示当前软件已有的集成选项。公司很少会调整不断变化的软件来建立统一的集成模型—选择支持你现在使用的所有集成选项的工具会更好。
最后要考虑的技术问题是虚拟化和云。在传统it里面，应用及其组件往往是位于同一位置的，或者至少位于数据中心综合体内的。它们往往还会呆在被放置的位置，除非出现硬件失败。而在云端，未满负荷的横向扩充会复制出多份应用副本，而地理位置分散的副本可以支持分散员工拥有更好的体验质量。云使得高效工作分布变得更加困难，因为它把应用分成了不同的块，并给目录管理增加了一个动态维度。
需考虑的业务影响
it决策必须适应高度易变的业务环境。通常，这应该把你的决定偏向集成的工作流模式，通过对于业务流程语言的强劲支持来操控基于业务因素的工作。这也意味着你有可能需要所有的工具具备更高的性能表现，以及每个产品具有范围尽可能宽的集成接口和选项。
你正在朝着成为更敏捷业务，以及组件化或向云转变，这一事实说明你正面临着相当激烈的it实践变化，激烈到意味着有可能值得去检查一下部分底层的应用选择，并考虑作出可改进整体敏捷性的变化。
要经常看看你的应用工作流的发展趋势。事务或支持员工数的增加也许会对应用的体验质量产生影响，除非你的工具能够跟上节奏。确保与未来的供应商就当前和预期的活动率进行沟通。
跟供应商框定你的选择
应用集成工具提交rfp是没有必要的，甚至可能是没有成效的，除非你能把采购需求缩小为单个产品目录。不过无论你做了什么，你都应该把自己的详细需求跟潜在供应商沟通清楚。解释好你明确下来的使命，选择工作流或应用的直接耦合的原因，以及你的技术和业务框架
从以上析取出来的技术需求，包括应用/组件接口支持，基于业务策略操控工作的支持，以及产品旨在满足主流供应商特定软件框架的程度。然而，不要仅仅是提出这些问题，最好是利用本文提供的结构，让供应商响应你自己的需求结构来获得信息。
你的应用集成工具未来的成功大部分取决于供应商的愿景与你自己需求的复合程度如何。确保把你的交互愿景传达给预期的供应商，确保要弄清楚他们的产品演进路线。一旦你确定了应用的发展路径，你和你的供应商就要一起为之努力了。