面向服务架构的支持者常常用革命性的用语来谈论这种技术，强调SOA在跨越信息障碍和颠覆软件开发世界方面的能力。

　　SOA承诺的是一个松耦合信息技术

　　服务或任务的即插即用软件环境。它取代了处理具体任务的紧密集成的应用软件。那么SOA采取的方案是甚么样的呢? 它使用标准界面将应用软件分解为几大块，将每一块看作是执行基础任务的服务，让其他的软件开发商在他们的应用软件中使用自己的服务。SOA认为没有必要为每一个任务重新编码，应用松耦合的服务，人们就能够创造新的应用软件。

　　SOA的价值是自由地使用软件，迅速适应变化的业务需求，结合新的职能并将稀少资源用于开发新的功能，而不是对现有功能进行复制。

　　但在应用软件开发的兴奋感过去之后，人们必须要考虑SOA应用软件地管理。

　　国防部信息系统局(DISA: Defense Information Systems Agency) 前企业应用软件部主管Bernal Allen “一种新兴的看法是：SOA性能的关键所在以及SOA设计模式是一个明确定义的可实施的治理性能，SOA治理必要的成分则是服务层面的协议。”他目前在Raytheon信息解决方案公司担任业务经理一职。

　　服务水平协议(SLA)是建立在服务供应商和服务消费者之间的契约，是在真实的情况下管理和实施对于性能的期望的一种方法。

　　SLA并不是新生事物，它们是软件管理原始工具之一。尽管SOA展现出作为新型软件范例的各种骄傲和自信，SLA在SOA环境中并没有改变。Raytheon为国家海洋和大气管理局的高级气象交互处理系统(AWIPS)的编程经理Buddy Ritchie指出从商业的角度来看，其环境是一样的。2005年，Raytheon赢得了价值3亿美元的合约来管理AWIPS并对其应用软件进行修改使之在SOA环境中运行。

　　Ritchie说：“SLA是客户告诉我们他们所认为重要的事情，不管我们是在现存的软件架构中还是在新的架构中，这种对话都必须继续。”

　　但是，在人们了解SLA的目的所在之后，他们仍然认为在SOA环境中准备和实施SLA存在特殊的挑战。行销官员应该在SOA环境中制定SLA时，遵循四个步骤：

　　1 确定期望的成果

　　表面上看来，比起较为传统的编程模型这个规定似乎没有什么不同，制定关于用户要求的长长的列表，然后信息技术部门编写代码来满足这些要求。

　　但是，咨询公司Capgemini的技术转型副总裁Sam Ceccola说：在SOA环境中，人们应该要考虑常规业务的替代选择方案。“我们在做些什么以改变常规业务?”这个问题在SOA项目开始之初就应该提出来。

　　Ceccola还说，人们可以利用SOA去执行以前的软件能够执行的同样的业务任务，但往往错过了SOA的灵活性和适应性以改变业务需求。

　　在开发SOA应用程序时，业务或程序领导者应该明确他们所要的结果和专家建议。将这些期望的结果嵌入组织的业务和技术之间的SLA中。首席信息官往往抱怨他们的业务同事对于设计新的IT环境漠不关心，但事实上他们是应该关心的。

　　国防情报局一位前首席技术官Bob Gourley向遭遇抵触的首席信息官们提供建议“我见过的唯一有效的做法就是，如果你具有具有业务经验的聪明的IT人员，他们多业务模型做出假设，如果这些假设是正确的那么就勇往直前，反之，则忍痛观望。”目前Gourley正担任一家技术研究和咨询公司Crucial Point的首席技术官。

　　2.让技术要求与业务需求相符合

　　出于某些方面的原因，软件设计人员必须要为技术服务选择一些确切的业绩指标衡量，包括服务的可用性，占用带宽或是响应时间。来自Forrester Research分析机构的资深分析师Larry Fulton用自动柜员机应如何被消费者所使用举例，解释了技术SLA应用应该怎样去制定。

　　“这个比喻并不是说当你插如你的银行卡并输入个人识别信息即可从自动柜员机中要求获取现金。” Fulton说道，“而应该是当这个动作实现的时候，其响应的快慢程度与可靠性以及安全级别之间的权衡。”

　　不同的业务需求需要配合不同的技术支持。一个军事方面的应用程序需要最高水平的可用性，但是相对而言对于一些级别比较低的业务来说可能一些最初级的数据分析工具就可以在正常的工作中运用并足以胜任。

　　“对于不同的人来说只有不断权衡和调整的SLA才会是真正关键的。” Merlin International国际IT公司的首席技术官Mark Zalubas如是说道，“并不是人人都适合于同一尺寸的。”

　　因为在SOA应用中需要有很多松耦合的服务，而SLA的存在让这些服务变的复杂起来。举例来说，软件设计师在重用服务的时候需要一个性能保证。在这个时候，你就需要技术SLA在服务提供商和服务使用者之间建立起一个统一的协议标准。

　　这样一来事情就会变得很棘手，Zalubas说道。因为每一项单独的服务在建立的时候都会基于对某种技术SLA的遵从，但是在整体的应用时却不能满足整体的业绩基准。然后技术SLA却不可能是事后才能制定的，他如是说道。它应该是整体系统的一部分，在SOA开发商在建立服务或挑选服务重用的过程中就应纳入并采用了。

　　但是，从用户角度而言一个成熟的SOA应用应该有着一个统一的SLA，即便在其背后有着许多附属的SLA加以支持，Gourley说道。

　　3.监控性能

　　技术SLA可以让你知道SOA应用能够达到什么样的性能，但是你怎么知道这个性能已经是这项应用所能达到的基准?

　　DISA以网络为中心的企业服务计划创建了一个SOA框架，用结构化的方式监控所有服务信息的传递。

　　“传统的框架在捕获服务信息的时候并不会在意此项服务究竟是来自程序或是企业实体。一个资深的计算机科学公司技术专家Victor Harrison如是说道。该公司是DISA公司SOA基础项目的赞助者。但他们并未对此展开讨论。

　　你可以考虑采用一种在供应商那里称为企业服务管理(enterprise service management，ESM)解决方案的低结构化监控这一方式。来自AmberPoint公司的副总裁John Emerson说道，ESM是分散在SOA环境中的一系列监测手段。

　　“在大部分的时候，他们不断的收集数据并很快的做出一个关于服务的复制信息。” Emerson说道，“根据这些他们所搜集到的信息，将其集合起来并发送到服务器的ESM系统中去。”

　　不管它是如何去实现这一点的，性能监控是一个重要的步骤，它可以作为在发现服务及其所负责内容这一方面责任失败的重要依据。

　　4 实施协议

　　如果一个协议没有对于违反协议规定的惩罚机制就不成其为协议。但是，这样的情况有时候会在SOA服务水平协议(SLAs)中出现。

　　一个用户机构可以说它拥有的SLA保证了性能的水平;而供应机构则会争论大会并不是以金钱为目的，因此应用供应机构来修复另一个机构的IT问题是合理的。

　　美国政府责任办公室(Government Accountability Office )IT 机构和系统问题主管Randy Hite表示：尽管根据各种法律，特别是1933 的经济法案，机构能够与其他机构签订服务合同，但当法律应用于SOA时“就进入到一些棘手的领域，是IT人士能力之外的。这就开始牵涉到律师团体。”

　　Harrison说：由于法律和资金一部分问题，SOA研究表明仅有5%的可再利用服务真正的被重新利用。

　　我们很容易就可以找到组织在执行SLA协议时失败的例子，Gourley说：每一次这种情况发生时，就会有一些顽固的老程序经理会说“你看，我告诉过你。我们应该自己完成，而不是借用其他服务。”

　　他指出，由于这个原因，SLA在联邦政府的单一组织中最为有效，这种组织的各个部分具有同一个资金来源。不在组织外部寻求可再利用服务被认为是谨慎的做法。

　　但这种限制并不适用于与SOA服务厂商签订合同。政府机构能够尝试惩罚那些不能达到期望值的可再利用服务的供应商。但，厂商在获得酬劳之前并不愿意承担额外的责任。

　　Raythen公司的Ritchie说：“除非有人提供金钱酬劳，技术成本和日程表，那也仅仅是客户的期望而已。”

　　即使是在单一组织范围内，要使得程序经理信任SLA也是需要领导力的。Gourley说：“第一个反应总是‘自己完成’。”

　　SOA专家指出SOA最终实现其灵活性的的承诺的可能性还是很大的，但他们也说SOA也有失败的可能。Ceccola说：目前为止，大多数组织并没有从SOA使命中得到真正的价值，他们得到的仅仅是IT价值而已。

　　Ceccalo说：技术的发展也曾经经历过同样的路线，当时的SOA被称作面向目标编程。十五年前，组织和文化的障碍类似于目前SOA面临的被挤压的面向目标编程。

　　但是，Ceccola也表示他认为如果组织能够使得SLA起作用，SOA是可以在面向目标编程未能成功的地方取得成功的。“这取决于技术层面和业务层面服务水平协议，它们应该结合在一起，这样我们才能看到SOA继续存在并变得普遍。”