服务分类
发现一组候选服务之后，对它们进行分类是对其进行设计、开发和后续执行的至关重要的一环。
分类可以按照功能、用途、结构和调用等标准进行。例如，将服务分为基础架构服务(DNS 查找、电子邮件)或工具服务(转换)是基于功能进行的分类。
这种分类方法有助于识别属于同一功能域的服务、允许定义标准和非常好的方法并对不同服务类的要求进行管理和监控。对服务进行分类的过程还将会发现业务服务的规则，可以将这些规则转换成一组应用于不同类型服务的、标准的、可重用的策略。
虽然服务进行分类还没有业界统一的标准，但通用描述、发现和集成 (UDDI) 注册表正在成为事实上的标准。UDDI 不但允许将元数据设置在服务上，还允许将其设置在诸如策略和 XML 模式等相关产物之上。
例如，您可以在 UDDI 注册表中创建下列分类模型以简化服务的发现、管理和控制:
服务所有者和联系人信息
服务或产物的功能描述
版本信息/状态，例如“版本”或“状态:测试 | 生产 | 维护”
服务类型(“订单输入”)或业务范围(“会计”)
使用模式/建议，例如“事物处理 | 子事物处理”、“同步 | 异步”
预期的错误信息，用于现有服务的重用
服务相关性，可能包括相关的策略、XSL 转换和 XML 模式
可用的服务端点，以及 Web 服务中抽象的和具体的 WSDL 位置给 UDDI 注册表中的服务和产物分类，不但可以使您能够更好地为潜在的候选项分类，而且还能发现可以重用的现有服务，从而避免了功能的不必要重复。
确定服务粒度
争取合适的粒度级别将实现使用、重用和可管理性方面的非常好的化。优异的、业务驱动的分析通常会发现与现有需求相对应的高级(粗粒度)服务。例如，一个粗粒度服务可能表示“流程采购订单”，它清晰地映射到一个业务流程。
由于自下而上的分析专注于 IT 基础架构和现有的 API，因此该方法通常会产生大量的粗粒度服务和低级(细粒度)服务。激活低级任务(例如“插入订单行项”)的功能就是一个示例。
理想状况下，您的 SOA 组合应当首先包括粗粒度服务界面，该界面直接与业务语义相对应。高级服务在动态的业务环境中灵活得多，因为它们没有紧密地耦合到下层基础架构之中。粗界面还允许您利用来自异类环境的其他服务来构建应用程序和流程，而不必考虑细节和差别。
相反，低级服务是和下层基础架构或 API 紧密耦合的，不能轻易加以修改以适应不断变化的业务需求。实际上，将一个服务包装在一个现有业务对象周围(例如企业 JavaBean (EJB))将不可避免地产生细粒度界面，把每个可供呼叫的方法显示在 bean 上。
用于处理机构内部非常特殊的案例的服务可以通过细粒度界面执行，这将为使用这些服务的客户端应用提供更多的灵活性。不过请记住，在灵活性增强的同时还须面对复杂性增加所带来的成本问题。
一般来说，您应当避免将低级界面公开出来作为服务组合的一部分以试图满足业务需求。可考虑改为将一组细粒度服务结合起来组合成粗粒度服务。
最后，需要记住的一点是，一个服务是否适当并不在于其是粗粒度还是细粒度，而要看其是否能使业务价值最大化。
服务获取
定义完服务组合之后，下一步是确定如何获取实际的服务:内部构建、获取服务或预订外部供应商提供的服务。
按照一般规则，那些关键性业务服务(即有益于业务流程、能为机构争取竞争优势地位的服务)最好是由内部提供。
您很可能在服务的发现阶段就已经在内部把可以映射到候选项的服务识别出来了。例如，倘若贵机构拥有 ERP 或 CRM 系统，则主要界面(客户、订单、帐户)都是可以加入到您的组合中去的服务。已经在企业内部使用的自定义应用程序可能也值得加以分析，以便识别可用的界面。
提供更多商品驱动的功能的服务(例如提供股票报价)可能是外部预订的候选项，很可能来自于贵机构已经与之建立关系的业务伙伴。一旦您开始搜寻符合您需要的服务，服务分类的需要便立即显现出来了。
显然，在识别候选服务时，有许多支持产物也需要创建和管理，例如，用于控制服务的策略;服务所使用的消息类型;以及将输入和输出消息转换成适当格式所使用的 XSL 转换。
创建一个这些产物及其相应服务之间的关系的目录将大大有助于构建您的组合。UDDI 注册表对本任务来说是一个价值极高的工具，它使您能够构建一个服务和相关产物的完整的在线目录。
SOA 管理需要考虑的事项
最好您的 SOA 基础架构能提供一个针对如下管理性能的平台:监控与诊断、外化的安全性、集中式审计与事件记录以及服务级协议与策略管理。有许多特定于 SOA 的组件可以用来进一步提高管理能力，例如企业服务总线 (ESB) 可用来实现可靠的消息传递;业务规则引擎可用来捕获和自动化业务策略;业务活动监控解决方案可用来优化服务。
采用中间 Web 服务管理服务器尤其受益。在这种配置中，服务通过一个向用户开放的代理 URL 被“虚拟化”，因此请求是通过媒介而不是直接发送到服务端点的。利用本集中管理平台可在服务上统一地设置策略，并为运行时策略的执行提供了一个单独的点。它还简化了服务度量和使用情况统计信息(对维护服务组合的运行状况至关重要的数据)的捕获。
服务虚拟化还具有提供位置透明度的优点:通过公开代理，可以在不影响服务用户的情况下对下部基础架构进行改动。该媒介必须维护其自身的虚拟服务到服务端点映射，或者利用 UDDI 注册表发现一个有效的服务端点。
结论：
SOA 作为沟通 IT 世界和业务世界的桥梁这一论断在不断地发展着。服务组合的构建是一项时间和资源的投资，它必将在面向服务的业务应用程序方面带来巨大的回报。对这些面向服务的应用程序可以加以修改以满足企业不断变化的业务需求。
