将各个组织连接起来：寻找粗粒度服务

　　这是一个不错的问题。其他人标识了很多类型的服务。我将仅回答有关“最佳候选服务”和“第一步”的问题。同时，我对这些问题也进行了一点改动。因为，SOA首先是一个具有很多好处的体系结构模型。很多其他文章已经对其优点进行了说明，我将不在此处进行重复了。

　　Web服务是一组为SOA启用互操作性的标准。WS-Interop提供运行时互操作性，而WSDL/WS-Policy提供工具之间的互操作性。例如，WS-Interop支持.NET和WebSphere运行时通信。程序员在Rational Application Developer/WebSphere Integration Developer和Visual Studio之间交换WSDL/WS-Policy，以开发协作应用程序。各个供应商均支持优化，例如JMS/MQ上的SOAP（一种基于XML的消息传递协议）和SCA的Java接口。

　　既然这样说，我认为最佳的候选服务应该是：

　　·由一个组织发布而由另一个组织使用的服务。即，首先使用SOA跨越组织边界。
　　·非常粗粒度的服务。程序员应该寻找在发送方和调用方要进行大量处理的文档交换一类的服务（即使使用远程调用）。

　　实现第一种类型的服务通常是为了解决迫切的业务需求；例如，企业间的集成或企业内LOB间的集成。实现SOA的Web服务提供了一个用于集成异类基础设施和应用程序接口的公共模型。这是Web服务的一种很好的用法，通常可解决迫切的业务问题，并同时允许不同组织内保持自主权。

　　从粗粒度服务开始，可以确保首次尝试Web服务不会遇到性能或可靠性问题。此方法还允许实现SOA的一些好处，如松散耦合、消息路由和消息审计。

　　您可能已经在使用SOA了

　　如果您刚刚开始采用SOA，或许要做的第一件事情就是使用IBM SOA Self Assessment工具（该工具是免费提供的）。根据评估的结果，可以确定当前的成熟度水平，并更好地为了实现SOA解决方案所需要进行后续步骤。也可以参阅“SOA compliance”白皮书，该白皮书描述了在这一漫长的过程中的可以采取的初始步骤。

　　阅读了所有相关材料后，您可能会惊喜地发现您已经在使用SOA了。例如，Rational Application Developer从V4（当前产品为V6）开始就提供Web服务支持了。您可能已经使用过其提供的向导来将简单Java对象、存储过程、SQL命令和无状态会话Bean转换为具有Web服务描述语言（Web Services Description Language，WSDL）接口的服务。WebSphere Integration Developer之类的新外接程序允许使用各种标准（如业务流程执行语言——Business Process Execution Language，BPEL）来将这些服务装配为业务流程。

　　结合使用各种方法

　　服务标识显然出现在SOA生命周期的开始位置，在很多情况下都会为整个项目的成功打下基础。服务标识通常采用域分解、现有资产分析和目标服务建模的自顶向下、自底向上和折衷技术的组合。自顶向下通常可提供业务用例所定义的业务服务的规范。这包括使用业务用例将现有域分解为功能区域和子系统。

　　在自底向上方法中，会将现有系统作为实现的可行候选者进行分析和选择。例如，可能会分析IBM CICS遗留环境的现有功能，以确定可能的SOA转换。通过确定表示组件和业务组件是否紧密耦合，可确定是否可以方便地为应用程序启用服务。

　　这种方法包括使用目标服务建模来发掘在用例（自顶向下）和现有系统（自底向上）方法中没有真正捕获的服务。由细粒度组件和其他服务组织的服务是作为服务实现的最佳候选者。标识了服务后，就可以开始服务的分类分级阶段了。此步骤无疑将帮助减少部署数千细粒度组件时的服务增殖问题（这些细粒度组件可能在未应用正确的控制时导致性能、可伸缩性和管理问题）。

　　常用服务

　　“中间相遇”方法可非常好地确保减少连接断开的情况。进行自顶向下业务流程分析，以标识最高级别的业务流程，然后将其划分为更为细粒度的服务。同时，对组织中已经存在的应用程序和基础设施采用自底向上的方法进行分析，以尽可能对现有资产进行重用。

　　因此，首先要考虑的服务是那些多个应用程序间最常用的内容——您可能会在不同的应用程序中发现对这些内容进行了多次实现！这可以很快降低成本，并立即体现出其价值。要考虑的主要方面之一就是，为了能有效地对服务进行重用，需对接口进行良好的设计。另外，您可能需要将实现新应用程序所带来的成本和好处与通过包装在相应的接口中来重用现有应用程序进行比较。

　　首先实现基础设施服务

　　有三种类型的服务可在整个企业内作为共享或可重用服务公开，如下所述：

　　公共基础设施服务：在操作级别对所有应用程序和系统都必要的服务。我所说的“操作”是指支持系统和应用程序本身的运行时环境所必要的任务——如目录/LDAP 服务、安全性服务、发现服务和服务管理。

　　公共企业服务：可以在整个企业范围内作为构建块提供的服务，可用于组合成新的服务和应用程序，如协作服务、消息传递服务和内容服务。

　　域特定的服务：提供特定业务功能的服务。域服务通常是企业内现有业务应用程序的扩展，如addCustomer、getEmployee或submitOrder。我建议企业就公共基础设施和企业服务支持的初始域服务集达成一致。

　　知道了这些区别后，要实现的第一种服务类型应该为基础设施服务，然后是支持初始域服务所需的那些公共企业服务。然后应使用基础设施和公共企业服务作为构建块来开发域服务，以扩展现有业务应用程序。选择正确的域服务进行组合实际上是对整个 IT 投资组合的潜在重用和可组合性进行评估的过程。

　　数据封装、遗留系统

　　您很可能从我们这里得到一个答案是，使用IBM SOA Self Assessment工具，该工具实际上更多的是确定您的组织对SOA的准备情况。快速了解服务概念的另一个标准答案的参阅白皮书“Five SOA projects that can pay for themselves in six months”。虽然这样说，但还是让我们了解一下可能需要使用服务的技术场景类型：数据和遗留功能的封装。

　　服务是一种访问高度依赖数据的行为的好方法。服务可对数据进行封装，简化客户机交互，并可在必要时从远程位置访问数据和行为——当数据快速变化或高度敏感而很难复制数据时，这将尤为有用。信用卡验证信息就是一个很好的例子；服务可以对支付操作进行验证，并同时保证信用卡数据库的安全。另一个不错的例子是股票报价服务，其中的当前数据在频繁发生变化，而历史数据又非常多。

　　服务也是包装遗留系统的好方法，可以更方便地访问和重用其功能。不必在新应用程序中重复相同的功能，而可以委托给已经具有此功能的现有应用程序。如果现有应用程序并不允许通过这种方式方便地调用此功能，可以使用代码对其进行包装，以将该功能作为服务公开。假定您的大型机订单处理系统已经知道订单的状态；要在网站上公开这个信息，请将相应查询作为使用大型机的服务实现。与此类似，如果该系统提供了创建、修改或取消订单的方法，请将这些任务作为您的网站也能使用的服务公开。

　　包装数据库或大型机的服务应是什么样呢？它们应该与用例类似。我所说的用例是对“客户计划如何使用数据或功能？”这一问题的回答。将重点放在客户希望服务做什么，而不是如何使用数据库或大型机将其实现。将重点放在用例上，可以确保服务不仅从技术上可行，还能确保服务在实际中有用。