REA应用的快速实施

    前文所说到的这个示例是否也在另一个角度展现了REA应用所能提供的快速实施示例?首先我们得清楚，用户是处在一个驾驶人员的位置，他们手中握着这个异常强大的“交通工具”的方向盘。这种用户可授权性的REA应用对于各个行业中的雇员都是同样可行的，例如医疗病例卡管理人员，销售代表，呼叫中心工作人员，信贷分析师或是索赔理算人员。

    其次，在这个REA应用的示例中(几乎所有的REA应用都是如此)，Ajax和SOA是紧密联系在一起的。很难确定究竟是SOA的原因引入了Ajax还是说Ajax更多的让SOA深入到了企业的架构计划当中。或许这也取决于企业自身的优势以及对于实施时间曲线安排，通过Ajax和SOA展开具体的应用。可以确定的一点，将这两种技术有效的结合起来会是比任意一种技术单独使用产生更大的效用。

    还有非常重要的一点，千万不要错误的认为REA应用只是针对门户方面。反之，应该将REA应用作为一种没有传统门户服务的门户去考虑。当前的门户已经是作为企业信息的一个单一切入点，它们已经变成了一个太多太多信息所屯集的一个地方。REA应用作为门户形式的展现在另一方面的作用在于不仅仅让用户能够找到他们愿意去查找的信息，更能够将一些不相干的信息数据混合到一起并给予用户个性化的观点认识——这就是REA应用所带来的全新的以用户自身意识为驱动的整合应用。当用户共享这些特定的微小整合时，在本质上则是造就了整合效应的“长尾”发展。

    REA应用如何填补IT业务中用户驱动这一空缺

    但是正如你可能已经意识到的，在目前典型的企业架构中本来是存在着一些组件可以用来支持REA应用的，而这些组件却在传统应用中失去踪影。适当的服务粒度在整个企业架构应用中仍是一门艺术形式。将数据推向基于流览器的应用并非普遍，而“虚拟化”服务和“混合式服务”更是前所未闻。

    所有这些沟通都需要在符合底层服务所确定的可用服务政策的前提下安全实现，这也是对于各层次分布的用户群而言一种优雅的度量准则。

    我们千万不能忽视，当前大部分的企业并没有拥有一个属于自己的企业级Ajax开发团队，他们更多的只是在等待SOA项目能够在生产中发挥效用。他们需要一些支持可视化开发的工具，一些调试工具，一些从IDE所得的“表和按纽”的窗口式开发的代码重用工具。IDE还得是帮助他们创造一些轻量级代码以及能够在流览器中优化执行的。

    还有一些较小但同样重要的问题，如何解决门户网站的浏览器兼容问题，多语言支持问题，网页内易读性指引问题以及共存策略问题，等等。

    如上种种则是为什么Ajax和SOA，当然你也可以如同本文中所称的那样称他们为REA应用对于未来企业架构规划和设计可能产生巨大影响的原因。从IT业务中REA应用型功能的最终用户需求可以明确的看到，新一代的企业架构将会无可避免的以用户驱动为前提。在未来的数年内，大部分的业务应用将作为REA应用的基础存在，IT部门 则是有责任为这方面需求安排计划。