组合应用程序软件与面向服务(SOA)的解决方案共享了大量普遍的东西……

　　很久以前，当所有的应用软件程序都专注于大的、昂贵的大型机，其放置在玻璃墙后面，人们给其穿上了白色的外套(并且由带着枪的人保卫着)。最终，随着小型机接着是个人电脑和服务器的兴起，其支持的硬件和软件系统从玻璃墙后面走了出来。

　　如果我们快速的回溯这四五十年，可能会发现我们正在经历着的这个周期：许多新的应用软件程序当时是依赖于正式的数据中心的。主要的差异在于那些新的解决方案(当前所遇到的则是“主机应用软件程序”合软件即服务)能从任何你能获得Internet链接的地方存取。通常通过最小的投资定金就能获得，他们已经戏剧性地为他们的用户减少了所有权的全部成本。尽管如此，与该利益相伴随的是新的挑战，尤其是在应用集成领域和防火墙之后的已存在的解决方案。

　　阻碍：管制及其他

　　当所有的应用都位于防火墙之后，集成而不是一个传送带，将会简单很多。为了保持那些系统的同步，企业利用了大量的技术。从通过数据仓库、通过企业服务总线(ESBs)析取、传输和加载(ETL)，在他们的核心，那些方法都包括复制各个信息孤岛间的数据。尽管如此，当其运用基于SaaS的解决方案进行集成时，存在很多原因致使其遇到麻烦：

　　·管制和法律阻碍——政府和其他的监管团体经常围绕(尤其是以客户为中心的)数据制定一些高度限制性的规则。因此，你的企业也许不能复制内部的信息到基于SaaS的远程主机系统。
　　·组织政策——即使你的没有遭遇任何管制或是法律问题，你的企业也可能不愿意将敏感的内部信息放置在由外部组织监管的服务器上。
　　·数据容量——这是根本的阻碍——你的组织所拥有的全部数据量也许超过了主机应用的可获得容量或是不合理的可获得带宽，使任何形式的数据复制策略变为泡影。

　　现在你已经排除了数据到主解决方案上，你的下一个选择就是要求你的用户平行地开启每一个应用(好在系统间就是简单的Alt-Tab)。这是最好的权宜之计，加注沉重的负担到用户身上，其必须对于如何关联应用之间的信息做出实时的决策。这就是问的太多，尤其是当你考虑其可能会相当复杂时，如果不可能执行这些数据类型的实时决策。

　　组合方法

　　如果存在一个可将所有的相关信息以单一和统一视图表现给你的用户的方式，又将如何?如果其可通过一个单一的用户界面实时、安全进行，又将如何?

　　幸运的是，通过应用集成的新的样式和以组合应用著称的开发可能实现。也经常被描述为企业捣浆糊，这些新的技术移除了用户生活中复杂性，同时赋予他们显著增加的权利和洞察力。

　　如果你对门户网站相当熟悉，那么你已经在理解组合应用是什么及其工作原理上有了一个好的开始。简单地说，他们通常呈现一个单一的用户界面，其实时地跨越了多个数据孤岛。在很多情况下，组合应用软件程序是从一个“主的”应用用户界面启动的。当实际上这个都是在后台进行处理时，这个使其看起来像是主应用软件程序通过组合应用软件程序以加载新的功能的方式进行了扩展。

　　图1：代表了一个由组合应用软件程序组成的后台提供的统一和联合角度的门户

　　比如说，看图1。它展示了一个主机的CRM包中的用户界面及一个键入Account页面的组合应用。组合应用软件程序在运行时展现了来自其他应用的重要信息，如订单管理、存货控制、财务数据等等。除非你在CRM包方面特别地擅长，你将不会知道为了展示这些数据访问了三个或是四个系统。而且，不想那些通常要求信息复制和与中心数据仓库同步的门户，组合应用软件程序能基于一个及时系统找回它的累积信息。

　　企业捣浆糊和门户网站另一个关键的差异是前者往往采用嵌入的语义的协作性(即逻辑跨孤岛的关系)同时后者则要求用户自己做出其精神上的决策。

　　图2展示了用户界面。在这个例子中，你能看到在一个HTML界面中用户是如何保留的，还有平稳地与来自与多个系统的数据交互。观察组合应用是如何将信息从多个孤立的系统(包括内部和外部)拉进实时，并协调数据为一个单一的用户界面。当然，这只是配置这样一个解决方案的一种方式。

　　图2：图1中展示的同一个门户页面，只是其底层的数据源展示了出来。

　　让我们看看一个组合应用软件程序的质量。

　　一个组合应用软件程序的通常的特性

　　虽然很难让两个开发者在一个组合应用软件程序的组成部分上达成一直，当还是存在一些获得普遍接受的特性：

　　实时存取——如果用户被迫看来自其他信息孤岛的陈旧信息，就不需要获得太多。比如说，想像一个错误的决策，其可能基于一个销售电话，如果用户认为客户的帐户已经开始征收，而实际上所有过期的发票已经在三天前支付了。

　　·最小化跨信息孤岛的运动——将数据留在其本来的信息系统中是组合应用背后一个关键的原理。尽管如此，存在奇怪的场合，其要求复制外键或是其他参考信息到变化的孤岛中。
　　·事物处理——这是组合应用软件程序的一个更加具有争议性(因此可选的)的特性。如果底层系统的商业逻辑和规则允许它(而如果用户拥有授权)，那么基于事物处理的交互在理论上是可以通过单一用户界面实现的。尽管如此，正如我马上要描述的，大多数组织选择在第二或第三阶段配置事物处理组合应用。
　　·准时制集成——对于组合应用的一个普遍的关注就是他们的绩效影响。尽管如此，实现无任何资源消耗直到用户通过用户界面发出请求依然是很重要的。比如说，你可能已经架构了你的企业捣浆糊从一个ERP系统中获得关于客户的交易历史的信息。在很多情况下，虽然ERP系统只在用户要求该具体信息时进行链接。
　　·语义协作性——这个特性指的是企业捣浆糊的理解和处理所有应用之间数据关系的能力。比如说，组合应用需要知道在CRM包中的客户编号以转换为在帐单系统中的一个帐户标志符。这是在不同信息孤岛同步中保持交叉引用信息的主要原因。

　　为何是组合软件程序?为何是现在?

　　开发者进行了几十年的应用建设;为什么只是到了最近组合解决方案才得以接受?

　　下面是一些驱动因素：

　　·传输层标准——以前在广泛应用内部协作性上的尝试，如CORBA，依赖于对于不可知的传输层协议的广泛接受性。现在HTTP(S)和TCP/IP已经得到了广泛的接受，而使能的线级基础设施也随处可见。
　　·Web服务的应用供应商支持——回望以前那些不甚好的日子，每一个应用供应商都希望提供他们自己的私有的API或是集成技术(与昂贵的咨询师的负载以喂养那些现金牛)。尽管如此，基本上这些供应商现在为他们的解决方案提供网络服务接口，使得跨系统的组合应用更容易开发。这些新的服务也帮助解决了在很多Internet时代集成中的内生的防火墙挑战。
　　·面向服务的设计原理——正如软件供应商为了简单化集成所做的，强健的面向服务的设计方法已经获得了广泛的接受。正如我在稍后所描述的，组合应用利用了很多关键的底层的面向服务的原则。实际上，大量的组织运用组合应用以突出其在投资面向服务的架构上的收益。
　　·久经考验的技术栈——在不久之后，我将引用一个面向Microsoft的的技术栈，其使组合应用的开发更加容易。在缺少这样一个栈的情况下，开发者将在何时应构建一个企业捣浆糊上承担更大的责任。
　　·HTML用户接口——最后，如果不存在简单的配置组合应用的方式，所有上述的因素将产生更小的影响。在此现代技术已经很好地帮助了我们，尤其是随着基于HTML的用户接口的上升。这些类型的前台较之以前的基于客户端的GUIs更加灵活和易于配置，因此很容易就引导其自身结合组合应用的设计。

　　需要克服的挑战

　　即使新的技术和设计原理不像其看起来(或是我们希望的!)那样简单和平稳。在建立组合应用的路上仍存在一些关键的阻碍，还有与之而来的如何克服他们的指导：

　　·语义协作性——当你没有任何关联孤岛数据的方式时，很难建立一个好的组合应用。围绕这个问题，许多企业组成了跨越多个信息孤岛的更高水平的网络服务。这些新的、抽象的服务将组成组合应用架构的基础。
　　·登录和许可——成功地维持单一应用的安全基础设施就足以让人敬畏。人们将惊叹于保持三个、四个或是更多同步应用的安全的想法。幸运的是，这并不像你想象的那么难。该文的稍后部分，我将介绍一些简化跨孤岛的组合应用的安全脚本的方法。
　　·潜伏期——对于很多系统和数据管理者来说，当评估一个组合应用时第一件映入脑海中的事就是他的跨孤岛性能在绩效上的影响。就如它所证明的，一个设计良好的组合应用只有很少或是没有增加的潜伏成本。实际上，假设它将节约用户和数据服务器的时间是合理的。我将即刻引用一些最好的实践。

　　缺少面向服务的基础设施——应用开发者因为其假设一个成熟的面向服务的架构是必需的而放弃架构一个组合应用的数量是惊人的。正如我的关于网络服务使能的关系数据库的前些日子的文章中所说，存在很多划分面向服务的架构阶段的方法，而不需要一个主要的预投资。

　　组合应用和面向服务

　　你也许想知道一个用户接口驱动的解决方案如一个组合应用是如何处理面向服务的一般原则的。事实上，一个设计良好的组合应用利用、反映、而且依赖于那些已建立的设计原则，其归档于Erl的“SOA：服务设计的原则“：

　　·服务的重用性——当你不想重用一个组合应用(因为其是为了一个特定的目的开发的)，你可能能重新使用底层服务的很多以获得未来的解决方案，如果不是全部。
　　·标准化的服务合约——这是你需要注意的一个地方。当一个服务仅与其他的服务交互时将会很轻率地修改一个服务合约。尽管如此，当一个用户接口(一个人在驱动它)依赖于服务则是另一个故事。
　　·服务松散耦合——设计得最好的组合应用以集成工具的形式服务，将松散耦合服务的集合分组为一个有意义的、业务驱动的解决方案。
　　·服务抽象——理想地，你将能组合或是聚集你的业务逻辑为一套高间隔粒度服务，接着组合应用将利用它。另一个选择是编码这些逻辑为组合应用自身，其将使其他应用对其的重用比你想像的困难。
　　·服务的组合能力——从定义上来说，一个组合应用作为组合粒度服务的集合为一个定义良好、面向用户的解决方案的结果。
　　·服务自治——当驱动一个组合服务的核心服务成为自动化，应用本身服务于集合这些服务为一个价值增值的包，其提供孤岛间的语义内部协作性。
　　·服务无国界——只读解决方案是一个组合应用的典型开端。因此，这些应用在设计上是无国界的。因为开发者开始架构可修改本地化孤岛中信息的应用，他们将依赖于底层服务的国家维护能力。
　　·服务的发现能力——从用户的角度来说，这稍微有些不相关的，因为他们将与已经架构的解决方案进行交互。尽管如此，用于建立一个组合应用的开发工具将利用这些能力。

　　现在你已经决定配置一个组合应用以解决你的最初集成体哦啊站，在你开始你的旅途之前还有一些事情必须铭记于心。

　　选择一个开发技术栈

　　将一个能够工作的技术栈放在一起来建立和维护组合的应用程序软件也许没有你想象中的那么恐怖和困难。就像现在大多湖的软件项目一样，至少有三个派系可以供你选择，他们是：微软，Java以及开源软件。在这篇文章中，我将使用微软的体系作为参考：

　　·用户界面——网络表单以及扩展的应用程序标记语言(XAML)
　　·Web服务——ASMX以及窗口通信基础(WCF)
　　·数据库——ActiveX数据对象(ADO)
　　·工作流——工作流基础(WF)以及BizTalk
　　·开发环境——Visual Studio.NET

　　需要注意的是，1)我们并没有足够的空间来详细描述如何部署这些技术，2)在每一个层上Java和开源软件也都有相应的支持的技术。

　　为好性能而设计

　　就像我在前面提到的，对于管理员来说，将组合的应用程序软件看作绩效的杀手，认为他们接触的系统都会降低生产率这件事是在自然不过的事情了。但是，这没有必要成为例子。下面有三个简单的步骤你可以采纳，从而保证你的应用程序软件的速度。

　　1.使用索引或者其他的优化过的查询——举例来说，如果你的组合的应用程序软件向财务系统发出了呼叫，想要找到过去的财务信息以及其他的一些信息，你一定要确保调用的服务是使用了索引或者是其他由底层应用程序提供的和性能相关的技术。

　　2.让用户决定何时找回数据——很多过于热情的程序开发人员给他们的组合的应用程序软件设计了这样的结构：当用户接口初始化装载的时候，应用程序将获得所有的可能的数据。但是，这将会严重的影响多系统的绩效，而且是非常没有必要的。举例而言，假设用户并没有想要或者并不需要看到一个已有记录的跨库数据，他将精力放在一个单一系统包含的数据当中。为什么要让用户决定何时以及是否去查询次要的和第三等的应用程序呢?

　　3.不要允许非法的审前调查——一个一定能够让应用程序软件(无论是组合的还是其他的)陷入困境的方法就是让用户拥有不受限制的查询权利。而在部署组合的解决方案当中这样做将会特别的危险。因为可怜的查询保护将会在同一时刻破坏多个数据仓。强迫用户将精力集中在主要的应用程序的记录当中然后在使用记录中的关键信息从而获得其他数据仓的数据的方式会比不受限制的查询要好得多。

　　安全的捣浆糊

　　安全是组合应用程序软件的开发人员以及管理人员经常(也是有理由的)十分关心的问题。对未经授权的访问(甚至更坏的，改写)次要的系统感到恐怖是非常正常的事情。谢天谢地，你可以通过很多的方法来减轻你的风险。

　　只发表只读权限的应用程序软件——这是大多数程序开发人员正常采用的第一步。尽管他并没有消除未经授权访问的潜在可能性，但是这样做的确阻止了不想要的数据修改的可能性。

　　依赖主要系统的安全模式——一个典型的组合应用程序软件是从一个主系统中出发的。例如，在这个例子中，组合的应用程序软件应该是从一个带有CRM包的客户记录的一个实例出发的。你可以假设如果用户正在从CRM包中阅读客户记录的信息，他们应该能够看到相关的财务以及次要系统当中能够提供的其他信息。

　　使用简单的安全仓库——如果你有时间，金钱以及纪律的话，这样做应该是最有效率的技术来在所有的底层系统中确保一致的安全政策的方法了。这也是一种理想的组合应用程序软件的支持方式。

　　结论

　　组合应用程序软件与面向服务的解决方案共享了大量普遍的东西，包括概念合和技术两个方面。实际上，组成服务的应用理所当然地取得了组合的资格。术语“组合应用“某些时候与具体的应用特性(如联合用户接口)相联系;尽管如此，以前对比组合设计和面向服务的原则的证据表明，组合和面向服务应用的协同是不可否认的。我们只需要提醒我们自己面型服务的设计的基本的颂歌就是服务必须是具有内在的组合性。