过去的一年对于面向服务的架构(SOA)来说是至关重要的一年，这一年，SOA蓬勃发展。毫无疑问，2008年，还将会有更多SOA工程被实施。

　　我们继续向前迈进的时候，不应该忘记过去的教训。我已经仔细回顾了2007年SOA的得与失，总结出十大SOA的成功要诀。

　　1.首先明确你的需求，然后再选择使用的技术。

　　这实际上是SOA倡导者David Linthicum的专业口头禅，通常，只要他一读到关于推荐适用于所有SOA技术解决方案的文章时，他都回不厌其烦的重复其口头禅。Linthicum的观点是：SOA是一种架构，而不是一种技术。

　　“在你想出要在解决方案中使用什么技术、标准和模式之前，架构需要进行一些分析和理解。”Linthicum在他最近的一篇文章中表示。

　　2.找到一个合格的SOA顾问。

　　当你在企业内部部署SOA时，你不会找到所需要的所有专业知识。你仅仅是不能找到—当然，除非你为IBM、微软、SAP或其他一些大型厂商工作。在一篇名为“IT业务常见问题”的文章中，　Linthicum建议当你部署SOA　时，你最好找一个合格的SOA架构师，他可以指导你的SOA实施。

　　他建议寻找一位经验丰富的非厂商认证(non-vendor certification)企业架构师—ZapThink和The Open Group都提供这种认证。其它企业架构框架包括Zackman Framework和国防部企业架构参考模型(Department of Defense Enterprise Architecture Reference Model)。

　　3.将服务与业务流程相结合。

　　关于是否应该推广SOA或者同商业用户谈论这一转变时，甚至能不能使用SOA这个词，存在很多的争论。不要在乎其他人怎么想，做你想要做的。

　　但不要忘记，IT部门做任何改变都会影响企业业务—所以，你一定要考虑清楚，循序渐进以确保这种改变会带来积极影响。这意味着将服务捆绑在业务流程中。这样做的一个方法是通过业务流程管理来实现。

　　但是，SOA还提供了一个难得的机会，让你和商业用户能够反思一下并且改进业务流程。所以，让他们从一开始就参与进来。让他们知道，这是一个解决问题、修补错误的机会，并且可以使他们的工作更容易。然后你可以听取他们的意见。

　　在设计服务时，把开发者和商业用户摆在相同的位置上。在规划阶段，使用直观的SOA服务表示方法。
　
　　4.清楚什么时候使用服务。

　　并不是每件事都需要有一个服务。服务真正的伎俩，是确保他们的粒度不会太小或太大(太大的话就变成了应用)。而定义业务流程可以做到这一点，因为它可以帮助你确定哪些可以作为一个服务，哪些不行。

　　5.搭建SOA时，从大处规划，从小处着手。

　　关于搭建SOA时，你应该从底层、中间层还是上层开始，有很多的争论。自顶向下的方法存在的问题是，它可能太大、太具压倒性因而不能成功地交付政治上需要的小胜利。

　　从底层开始着手的话，当你扩展SOA时，你可能会发现在编写服务的时候范了很多错误，这些不容易被抽象到SOA的其它层次上。

　　这仅仅是一种猜测，自底向上的SOA项目可能非常类似于应用开发流程，所以我怀疑问题可能在于自底向上的方法会导致项目返工。关于自底向上的SOA搭建方法存在的问题，博客家Joe McKendrick写了一篇文章，有兴趣的话大家可以参考一下。

　　许多人主张“由中间开始(middle-out)”的办法，不过，坦率地说，我还不是很清楚这是什么意思。我认为这种方法应该综合了自底向上和自顶向下两种方法。但我认为见到过的最好的搭建SOA的方法是从大处规划—设计一个体系结构并预测如何将它运用到整个组织—但是实施的时候从小处着手，这样你就能很轻松地解决问题并给企业提供一个概念证明。

　　6.不要忘记安全。

　　在某篇文章中，我看到一个预测说2008年SOA安全将成为一个热点问题。我当然希望如此，因为2007年，它受到的关注比较少。我们没有从互联网上学到东西吗?安全应该始终都是一个大问题。SOA给你一个机会纠正一些过去的安全错误，因此在搭建SOA的时候，创造一个安全模型。

　　7.更新你的测试过程。

　　测试是SOA面临的另一个挑战，它很少被提及道，但可能会导致大问题。程序员一般都是在软件开发完毕或接近完毕的时候进行测试工作，但对于SOA，这种模式是行不通的。

　　因为在一个应用适用的服务，并不意味着在其它应用中也会发挥作用。你需要分开测试每一个服务。Serena Software分析师Kelly Shaw博士是应用程序生命周期管理方面的专家，他说，这种独特的挑战要求开发时间治理

　　2007年，IT Business Edge对Surgient产品战略副总裁Erik Josowitz进行了采访，双方探讨了对SOA“许多移动部分”的测试是如何影响开发周期的：

　　所以，进行应用开发的大部分企业都认识到了在任何开发周期中，时间最长的就是测试。加快软件交付的真正挑战在于不影响质量的前提下如何加快测试。

　　Surgient公司是位于得克萨斯州奥斯丁的虚拟化实验室软件供应商，并提供托管服务。所以，Josowitz还向大家介绍了虚拟测试如何加快SOA部署。

　　8.继续建设。

　　继续建设是什么意思?这是我对2007年有关SOA的两个重要教训的简略的表示方法。教训之一：使用你的服务达到临界质量(critical mass)可能需要一段时间。Public CIO在去年4月份发表的一篇文章中谈到了这个问题，但它仍是一个很好的建议：从小处着手，但是要看到实实在在的效果，你将需要把它建立在你的成功之上。这有重新回到了服务可用性的问题上，SOA专家David Linthicum认为，服务重用不应该被视为SOA的一个核心好处。

　　即使你确信重用并不是那么重要，　“持续建设”依然是一个很好的口头禅，因为教训二：你需要在你取得的成功上继续发展。Public CIO的一篇文章称这为“特许权”，用你第一个成功的SOA项目作为以后SOA部署的模型。这可以追溯到第六条“从大处规划，从小处着手”。

　　当然，在某一点上，持续建设有可能成为坏的建议。我猜测，真正的警示作用是不要过早地放弃。正如Linthicum说的那样，　SOA是一种架构，建立一个架构是需要时间的。同样，要看到回报可能也要花一段时间。

　　9.SOA治理。

　　2007年，SOA治理是一个热点话题。如果你是一个SOA领域的新手或者刚刚开始接触SOA，那么你就可以从经验丰富的人那里学到很多知识。

　　SOA治理涉及到SOA的很多方面—我之前已经提到了开发时间治理—但它主要是指利用存储库和注册库(repository　/　registry)进行服务管理。Shaw在一篇文章中很好地解释了你为什么需要一个存储库，以及它如何同注册库配合使用。

　　你什么时候需要考虑服务治理呢?对于这类问题的回答几乎都是“从一开始”。但在Information Age的一篇文章中找到一个更现实的答案。在这篇文章中，Tibco资深产品行销经理Robert Meyer主张，当企业建立了大约50个服务的时候，它就需要SOA治理了。

　　Meyer表示，如果你的公司符合上述条件，但却没有添加SOA治理，你会发现你其实在服务开发上花费的时间要比传统的应用软件开发花费的时间要多。

　　偶尔，治理可能会涉及到你如何为一个松散耦合的架构管理成本分配。Quinton Wall在他的“SOA治理反思”这篇文章中很好地总结了各级财政治理。