IBM专家将提供各自的个人观点，以推动IT体系结构实践方面的发展，从而帮助您更好地担当架构师这一职责。

　　引言：将SOA理论付诸实践

　　注意：有关观点与展望 专栏的全面的信息，请参阅以前的部分：

　　·“第1部分：选择SOA的原因和时机”
　　·“第2部分：如何将业务需求转转换为IT要求？”
　　·“第3部分：什么是最有价值的IT体系结构技能，如何学习？”

　　您可能已经认识到面向服务的体系结构（Service-Oriented Architecture，SOA）适合您的IT系统——或者您尚未认识到这一点。但为了讨论方便，让我们假定您已经决定开始设计和实现您自己的SOA系统了。您将问自己的第一个问题是“我该从哪里开始？”

　　IBM等企业提出的SOA方法定义了四个采用SOA的阶段，其中第一个阶段是：

　　·实现各个Web服务

　　您需要创建各个基于软件的服务——任务或任务集，以软件组件的形式编写，可通过发布和可发现接口在网络上为其他应用程序提供服务。这些服务可以是从头创建的基于软件的任务，也可以是需要从现有非SOA应用程序转换为服务的任务。（我建议您阅读关于面向服务的体系结构的采用的所有四个层次部分，以确保按照正确的方向进行相关工作。）

　　理论上很简单，是吧？您所需要做的就是编写包含这些服务的组件，或直接根据已定义的SOA接口将现有大型应用程序“组件化”。您可能会想：“说起来容易，做起来难。”正如我在Rational软件组的一位同事说的，“从理论上说，理论和实践是完全相同的，但在实践中，它们却并不相同。”

　　SOA采用的第一个层次虽然很简单，但您仍然可能会询问与以下类似的问题：

　　·就实践而言，我如何知道怎么开始实施SOA？
　　·我如何知道哪些可作为一个好的服务？
　　·是否可以使用已经编写的代码，或者，我是否需要完全重新编码？
　　·应该如何处理现有代码，以将其变成服务？

　　为了帮助您回答这些重要的SOA采用方面的问题，我们邀请我们的IBM体系结构专家组回答以下问题：

　　如果我刚刚开始采用SOA，哪些类型的软件特征是作为服务实现的最佳候选对象，开始实现过程的第一步是什么？

　　和以往一样，专家们给出了很多意见和建议，我们希望他们的这些观点和看法能帮助您将SOA理论付诸实践。如果您有其他问题或对本主题有任何看法，请告知我们，可以通过pdreyfus@us.ibm.com给我发送电子邮件，或在IT体系结构讨论论坛发表您的问题或看法。我们将尽力为您提供帮助。

　　Paul Dreyfus
　　developerWorks SOA and Web services
　　pdreyfus@us.ibm.com

　　另，developerWorks SOA专区(www.ibm.com/developerworks/cn/webservices)提供了关于此主题和SOA采用过程中的其他主题的详细指南。除了参考我们专家组的意见外，还请参阅SOA新手入门和SOA技术文档库。

　　面向服务的建模和架构

　　确定在SOA中公开哪些服务的过程称为服务标识。可从developerWorks文章“基于服务的建模和架构”了解关于此过程的更多信息（该过程包含三个相互补充的技术，均在这篇文章中进行了说明）。

　　首先，您需要清楚而全面地定义转换的范围：最首要的问题是，为什么要启用服务？定义了这个范围后，将应用目标服务建模、流程分解和现有资产分析，以获得候选服务组合。这些经过归类的候选服务集属于您的服务模型的一部分。

　　在您工作的下一个阶段，将确定和设计每个服务。需要进行服务公开决策：在数量相当多的服务中，我要实际公开哪些服务？以一系列选择标准为“石蕊试纸”，对最初候选的所有服务执行一个“PH值测试”，就可以得到这个问题的答案。这包括基于各种标准（如其与业务需求的一致性）测试服务的“良好度”或相称度。

　　这将筛选出一个列表，其中包含应该开始进行设计且在SOMA的规范化阶段发生的服务。在此步骤期间，将详细指定服务的很多详细特征，以供实现过程中使用。

　　实现是在SOMA过程的实现阶段完成的，在此阶段，将通过一组体系结构和来源确定决策对服务进行准备、来源确定或实现。该过程的这个部分的成功是类似于以下所示的声明：

　　·我将使用此包来实现提供此服务的组件。
　　·我将从头构建此服务。
　　·我将对这两个遗留事务进行包装。
　　·我将使用这些事务实现第三个服务或它的一些操作。

　　插入点

　　一个标识服务（无论是纯Web服务还是其他更一般的服务类型）的反模式是，了解现有系统，并使用已经获得的主要接口对服务进行包装。

　　之所以认为这个做法非常不好的原因是，这些接口——用于表示系统的错误边界——通常可能很糟糕，是经过多年使用而逐渐从原始状态发展而来的，其表现具有偶然性，行为并不是最开始就确定的。这也是技术第一的解决方案的一个例子。

　　标识良好服务的一个更好的模式涉及到定义简洁的抽象。根据您的系统提出一些基本的使用场景。将重点放在交叉点上（即多个方案的成功均依赖于一个较小的软件集的位置）。在这些交叉位置之间的巨大间隙中，您将找到使用服务的位置，其相关粒度可由这些方案本身的特性确定。不过，是否将这些服务包装为纯Web服务还是别的什么，这需要进行进一步决策。

　　各种入口点

　　SOA策略不应是大规模替换现有IT环境；相反，这应该是一个循序渐进、不断发展的过程。因为各个企业通常具有复杂的操作环境，因此不可能进行完全替换。因此，整个路线图应体现为一个迭代重复的过程。

　　根据我参与多个客户的相关工作的经验，并没有用于构建SOA解决方案的“万能”完美方法。不过，存在各种入口点，可用于帮助采用SOA。可以将这些入口点大致归类为以下数个类别：

　　初始采用。这通常适合那些希望进入这个领域但又担心有风险的用户。体系结构方面的工作通常限制在一个临时环境中，相关的活动包括从概念验证到早期的试验性部署等活动。初期工作体现出业务和技术价值后，会在更大范围内开始采用SOA。

　　业务线采用。具有技术眼光的进步的业务线（line-of-business，LOB）执行人员可能会认识到SOA的价值。在这个过程中，将首先标识一组业务流程和功能的灵活性要求，定义具有关键成功因素和结果指标的解决方案概要，最后实现解决方案体系结构。有时候会使用服务建模和分析技术来对服务标识、规范化和实现步骤进行正式化。IBM咨询师喜欢使用SOMA方法来进行此过程。

　　企业采用。这是开明的CIO决定开始以增量方式逐步对整个企业的应用程序进行转换时的情况。通常会涉及到业务分析和建模，以便创建一个区分了优先级的企业组件图。为了获得这个组件图，IBM顾问通常使用组件业务建模（Component Business Modeling，CBM）方法。该图中每个需要进行重构的业务组件都会使用服务建模技术（如SOMA）进行分解，从而最终实现可重用的、价值驱动的服务：

　　我与人合著的《SOA Compass， Business Value， Planning， and Enterprise Roadmap》一书可帮助您了解SOA采用过程中的各个基本组成部分——工具、技术和方法。“SOA Project Planning Aspects”（WebSphere？ Journal，2006年1月）对该书的内容进行了简要介绍。