最近在一份针对2009年所做的预测报告中曾指出：

　　“那些可以在企业内部（甚至企业间）的SOA实例之间提供可扩展性的服务和消息访问的域间SOA技术、或高扩展性的安全中间件技术将会获得更多的关注。实际上，当前的大多SOA方案即使在单个问题域也缺乏扩展性，因此这种技术必将成为SOA战略成功的关键。”

　　随着SOA从项目层扩展到整个企业，SOA架构师和实践者们也迅速认识到了通用服务与数据管理问题的重要性。今天我们将讨论利用什么方式与使能技术才能为我们的企业寻找一个通用的可扩展且安全的机制，从而保证企业中的所有SOA实例都有技术无关的设备基础。从根本上讲，架构设计师们应该可以自由地挑选能够满足项目需求的最佳技术并且可以根据与技术和供应商无关的通用服务和信息管理设备而做出决定。

　　原本企业服务总线（ESB）要负责为企业提供主要的信息集成服务共享。这在微域（即项目层）确实有其应有的效果。但是用来解决有关企业SOA主要设备大型问题的ESB，很快就被发现这并不是一项适用于微域中的技术。虽然ESB在子域中的核心集成与服务共享方面表现得非常不错，但是它需要更具体且具有高度可扩展性的设备支持才能在企业（宏域）层次上推动SOA。

　　据Forrester最近的一则报告，要解决在SOA问题域中以及域之间的有关服务与信息共享的核心问题，就需要域间技术。并且，Intel的Joseph Natoli最近也在他的博客里强调了“合适”的SOA的必要性：”这里的关键是要让架构和技术决策与目标吻合，并且适用于解决将SOA与企业联系到一起的关键业务问题。”这是一个战略性技术，而且将成为企业中最重要的连接，因此它必须能够支持业务所需要的功能。

　　要明白这项技术的最好办法还是了解这项技术所能带来的投资回报（ROI）。它对于业务的最大优势是什么？或者说，也是更重要的一点，如果没有这项技术，业务方面会产生多少损失？这将是一个了解经济世界真实性的有趣的经历。

　　认识ROI

　　最好的办法当然是了解如果继续使用当前的方式和技术方案的话会造成多大的损失。一旦了解了这一点，相对地就能更容易地了解利用域间SOA技术可带来的影响、评测其对架构效益的影响、以及其对业务产生的影响。这里要指出的是，所有企业与域都是不同的，因此你必须根据实际情况对你的方式和数据点进行调整。

　　因为这是一个根据企业或问题域的具体情况而定的多变的非常复杂的问题，那么使用一个相对较简单但是合理的方式来计算利用这项技术所带来的ROI应该会有效得多。

　　为了达到这个目的我们来看几个关键数据块：

　　·“当前（as is）”方式与技术方案的架构低效性每年在业务上产生的的有效花费（成本）。

　　·“将来(to be)”的方式与技术方案的架构有效性每年在业务上产生的的有效费用（价值）减去“当前”或域间SOA技术成本。

　　·复杂度，这通常（但不一定是）取决于所管理的服务与数据库属性的数量。

　　·重用度，这取决于在微域内或单独的SOA实例中重用的服务。
　　
　　·软性问题–比如用于提高IT方案所能带来的客户满意度、雇员士气、商务智能等新方式或新技术的能力，它不像硬性问题那么容易定义。

　　“当前”的代价

　　现在实施SOA的人倾向于使用战术性方式和技术解决战略性的架构问题。结果就是产生了一个架构有效却缺乏对企业的整体价值的实例。实际上，问题域能共享信息和服务的程度越高，对企业的价值也就越高。这是我们进行分析的核心。

　　当然并不是说企业级的SOA不是由各个项目构成的，也不是说它无法确定许多问题域，只是说我们的最终目标让它对企业和业务有普遍的价值。

　　这个架构在在狭义的微架构或微域层次的SOA中通常具有以下属性：

　　·缺乏安全性。

　　·缺乏访问一般服务的扩展性。

　　·缺乏访问通用数据的扩展性。

　　·缺乏共同的技术方法。

　　·缺乏已验证的扩展性。

　　·缺乏共同的SOA治理策略。

　　实际上，如果只是SOA的一个实例，那么解决的通常是具体的战术问题，而不是企业的架构问题。这些狭义域是一个好的开始，但是必须对其进行有效组合才能形成企业范围的解决方案，进而满足企业的需求，而不是仅仅满足一个部门或某一方面业务的需求。

　　而且，在这些微域中，安全性通常都会放在最后考虑，或者仅仅在某个特殊的范围内执行。而核心服务和核心数据的共同的安全性策略的缺乏会导致企业变得非常脆弱。因此，要把共同的安全性设备放在重要的优先级上考虑，建立跨越整个企业的安全策略。

　　除了安全性，还需要有用于处理服务和信息的通用方法。这通常是从当前的信息系统比如ERP、核心数据库、商务智能、或者核心企业系统API中提取出来的。

　　因为有如次众多类型的接口，所以在这些接口之间还需要一个中间层。这个中间层可以十分简陋，但是它能在架构中有序地对服务和信息进行管理。换句话说，这个中间层将高度规范化和结构化的信息绑定到抽象模式中，形成对业务系统来说更逻辑化的抽象模式，比如客户数据、定单信息或产品的呈现。

　　虽然这种通用设备具有明显的优势，但是如果这种设备无法提供所需的扩展性，那么一切都等于乌有。在单独一个SOA微域里同样的一个服务可能会有四个系统对其进行访问，如果这个服务同时被企业中所有的150个系统同时访问，那么扩展性和可靠性就会成为很大的问题，而且是战术性技术无法处理的问题。虽然SOA提供了更高程度的重用性和敏捷性，但是服务共享必须符合消费者的服务等级协议（SLA）。

　　最后，你还得在其中加入SOA治理。虽然传统的运行时和设计时SOA治理技术对于小型域已经足够了，但是企业范围的SOA治理必须能够在高级事务层上同时管理政策和服务，并且要避免成为瓶颈。

　　知道了这些缺陷，你就得每年播出一定的款项来处理上面所列的各种侵蚀公司的问题。比如一个具体的企业，可能要在安全性问题上每年花费50万美元，在通用服务的扩展性问题上花费175万美元，等等。

　　这些费用是通过分析每个问题再与当前的架构状态进行比较而得出的，前提是架构已经”完美地优化”过了，这样这些问题才算彻底解决。换句话说就是以当前的状态有多糟糕与可以改善得多好进行对比，以及这将花费我们多少成本。或者说对当前架构和技术方案在微域层次上进行的分析是否能够扩展到企业层次上。

　　“将来”的价值

　　鉴于上面我们讨论，我们需要创建企业范围的更为整体化、策略化的方案。问题是：什么样的方式才是正确的方式？什么样的技术才是正确的技术？还有这将给我们省多少钱？

　　作为开始，你先要考虑方式的核心概念。从实质上说就是分层分析架构。比如与业务方案相关的微观层，或者说将服务和信息汇集到过程或组合应用中以满足企业的业务需求的能力。再往下看就是微域服务，或者那些某个域特有的服务，比如用于运输部门的物流过程、主机上的服务、或者通过SaaS实现的外部服务。

　　在这些域中有许多SOA实例。实例包含管理中的服务，而且大多含有对整个企业有价值的服务，因此应该使其可以以安全和可扩展的方式在企业中共享。

　　这一点正是这个方法的本质，或者把这些服务放到支持任何数量的消费者同时对服务和信息的扩展性和安全性访问微域下的技术层上。换句话说，就像是一种类似于网络路由分发数据包的功能，保证所有人都能够访问到自己所需的服务。这样我们就得到了企业服务路由（ESR）。有了ESR，就可以实现微域或策略性企业范围的SOA了。

　　ESR可能会成为架构的核心层，不管解决问题所用的是何种技术或标准，也不管旧技术是否存在，都可以为企业SOA的所有实例提供所需的通用服务和执行平台。从根本上说，这是一种技术无关的方法，它不但不会逼迫架构师选择某种具体的技术或标准，还能为通用服务和信息提供具有高度可扩展性和安全性的访问和管理组件。

　　这种方式有许多优势：

　　·利用通用服务和数据管理设备通过规模经济节约成本

　　·由于服务会以具有高度可扩展性和安全性的方式混合匹配来满足业务的需求，因此可以获得敏捷的战略性优势

　　·可以利用当前的技术，而不是必须进行成本昂贵的应用和数据迁移

　　·过程与服务重用的战略性优势，这也是SOA的核心价值

　　·减少了复杂性，但可以在企业范围提供一致的通用服务部署和访问机制

　　·可以利用既有的资产，这样就无需对当前的系统和信息做出改变

　　这样我们就得到了一个与上一部分”当前”成本消耗类似的”将来”每年所能获得的价值。

　　当然这个价值每年都可能发生变化，而且可能还要考虑其它数据，不过基本想法都是一样的。我们就是用这个想法来了解“当前”与最优化的架构（“将来”）对比所产生的成本影响，从而看到如果什么也不做会有多少成本消耗。所以这要么是“将来”的架构的有效价值，要么是实施优化方案的成本。下面以一个高层次的商业案例来具体看一下将所有这些信息结合到一起的情况。

　　创建适用于域间SOA技术的商业案例

　　你会发现“当前”架构的低效率所造成的成本消耗几乎等同于利用通用域间技术方案（比如ESR）的“将来”架构所带来的价值。我们通过两次计算的对比得出了解决问题的价值和解决问题后所产生的价值。如果你的比值超出了30%，那么你可能需要重新进行分析，或者重新检查你所用的技术方案。要记住没有任何东西是完美的，很可能你在企业架构中实行了优化却没有得到成果。你只要尽力就可以。

　　此外，你还要考虑我们之前讨论过的其它因素，包括复杂度–这是成本消耗或收益的乘数。实际上，你的架构越是复杂，那么它低效率时所产生的成本消耗就越大，而优化后所带来的价值也就越高。这个复杂因子通常在0.5～1.5之间。

　　与复杂性一样，你也要同样对待重用性–即微域内外重用的服务的数量。你可以将这个看作一个百分比，服务重用百分比为15%–这是一个很常见的比例。你也可以将其看作一个乘数因子，根据重用的服务数量它通常在0.95`1.05之间。某些企业几乎不重用服务，也有企业重用很多。这取决于业务与架构的需求。

　　虽然我们上面定义的分析性问题可以产生一个相当诱人的商业案例，但是实际价值通常在难以定义的软性问题上。不过它确实能提供一个更为有效更为积极的IT架构，能让顾客和雇员都感到满意。你的具体方式要取决于你的业务范围，但是不管怎样，它所能带来的价值是很可观的。

　　实际上SOA在小部门层次的问题域上（即本文所提到的微域）几乎没有什么价值。因为，要想取得SOA的价值，我们就要建立一个策略在企业范围（或宏域）内同时共享服务和信息。这是让你的商业案例发挥作用的第一步。

　　要实现这一点，最好的办法是明白你自己的业务驱动，然后做出一个计划从徽域和宏域两个方面解决SOA问题，这意味着以渐进的方式解决各个域和业务中的问题。还有，你必须确定在各个域中和域间发生的信息和服务共享问题，以及相关的技术问题。SER应该具有良好的扩展性、安全性和可靠性，并且是标准的、和技术无关的。就像连接各个城镇的高速公路一样，你也必须连接企业内的各种技术，从而最大化SOA的价值。