建立服务水平协议确保SOA实施

面向服务架构的支持者常常用革命性的用语来谈论这种技术，强调SOA在跨越信息障碍和颠覆软件开发世界方面的能力。 　　SOA承诺的是一 个松耦合信息技术服务或任务的即插即用软件环境。它取代了处理具体任务的紧密集成的应用软件。那么SOA采取的方案是甚么样的呢?它使用标准界面将应用软 件分解为几大块，将每一块看作是执行基础任务的服务，让其他的软件开发商在他们的应用软件中使用自己的服务。SOA认为没有必要为每一个任务重新编码，应 用松耦合的服务，人们就能够创造新的应用软件。 　　SOA的价值是自由地使用软件，迅速适应变化的业务需求，结合新的职能并将稀少资源用于开发新的功能，而不是对现有功能进行复制。 　　但在应用软件开发的兴奋感过去之后，人们必须要考虑SOA应用软件地管理。 　 　国防部信息系统局(DISA: Defense Information SystemsAgency)前企业应用软件部主管BernalAllen“一种新兴的看法是：SOA性能的关键所在以及SOA设计模式是一个明确定义的 可实施的治理性能，SOA治理必要的成分则是服务层面的协议。”他目前在Raytheon信息解决方案公司担任业务经理一职。 　　服务水平协议(SLA)是建立在服务供应商和服务消费者之间的契约，是在真实的情况下管理和实施对于性能的期望的一种方法。 　 　SLA并不是新生事物，它们是软件管理原始工具之一。尽管SOA展现出作为新型软件范例的各种骄傲和自信，SLA在SOA环境中并没有改变。 Raytheon为国家海洋和大气管理局的高级气象交互处理系统(AWIPS)的编程经理BuddyRitchie指出从商业的角度来看，其环境是一样 的。2005年，Raytheon赢得了价值3亿美元的合约来管理AWIPS并对其应用软件进行修改使之在SOA环境中运行。 　　Ritchie说：“SLA是客户告诉我们他们所认为重要的事情，不管我们是在现存的软件架构中还是在新的架构中，这种对话都必须继续。” 　　但是，在人们了解SLA的目的所在之后，他们仍然认为在SOA环境中准备和实施SLA存在特殊的挑战。行销官员应该在SOA环境中制定SLA时，遵循四个步骤： 　　1 确定期望的成果 　　表面上看来，比起较为传统的编程模型这个规定似乎没有什么不同，制定关于用户要求的长长的列表，然后信息技术部门编写代码来满足这些要求。 　　但是，咨询公司Capgemini的技术转型副总裁SamCeccola说：在SOA环境中，人们应该要考虑常规业务的替代选择方案。“我们在做些什么以改变常规业务?”这个问题在SOA项目开始之初就应该提出来。 　　Ceccola还说，人们可以利用SOA去执行以前的软件能够执行的同样的业务任务，但往往错过了SOA的灵活性和适应性以改变业务需求。 　　在开发SOA应用程序时，业务或程序领导者应该明确他们所要的结果和专家建议。将这些期望的结果嵌入组织的业务和技术之间的SLA中。首席信息官往往抱怨他们的业务同事对于设计新的IT环境漠不关心，但事实上他们是应该关心的。 　 　国防情报局一位前首席技术官BobGourley向遭遇抵触的首席信息官们提供建议“我见过的唯一有效的做法就是，如果你具有具有业务经验的聪明的IT 人员，他们多业务模型做出假设，如果这些假设是正确的那么就勇往直前，反之，则忍痛观望。”目前Gourley正担任一家技术研究和咨询公司 CrucialPoint的首席技术官。 　　2.让技术要求与业务需求相符合 　　出于某些方面的原因，软件设计人员必须 要为技术服务选择一些确切的业绩指标衡量，包括服务的可用性，占用带宽或是响应时间。来自ForresterResearch分析机构的资深分析师 LarryFulton用自动柜员机应如何被消费者所使用举例，解释了技术SLA应用应该怎样去制定。 　　“这个比喻并不是说当你插如你的银行卡并输入个人识别信息即可从自动柜员机中要求获取现金。”Fulton说道，“而应该是当这个动作实现的时候，其响应的快慢程度与可靠性以及安全级别之间的权衡。” 　　不同的业务需求需要配合不同的技术支持。一个军事方面的应用程序需要最高水平的可用性，但是相对而言对于一些级别比较低的业务来说可能一些最初级的数据分析工具就可以在正常的工作中运用并足以胜任。