精通SOA构建企业应用服务组合

理想状况下，您的SOA组合应当首先包括粗粒度服务界面，该界面直接与业务语义相对应。高级服务在动态的业务环境中灵活得多，因为它们没有紧密地耦合到下层基础架构之中。粗界面还允许您利用来自异类环境的其他服务来构建应用程序和流程，而不必考虑细节和差别。

相反，低级服务是和下层基础架构或API紧密耦合的，不能轻易加以修改以适应不断变化的业务需求。实际上，将一个服务包装在一个现有业务对象周围（例如企业JavaBean（EJB））将不可避免地产生细粒度界面，把每个可供呼叫的方法显示在bean上。

用于处理机构内部非常特殊的案例的服务可以通过细粒度界面执行，这将为使用这些服务的客户端应用提供更多的灵活性。不过请记住，在灵活性增强的同时还须面对复杂性增加所带来的成本问题。

一般来说，您应当避免将低级界面公开出来作为服务组合的一部分以试图满足业务需求。可考虑改为将一组细粒度服务结合起来组合成粗粒度服务。

最后，需要记住的一点是，一个服务是否适当并不在于其是粗粒度还是细粒度，而要看其是否能使业务价值最大化。

服务获取

定义完服务组合之后，下一步是确定如何获取实际的服务：内部构建、获取服务或预订外部供应商提供的服务。

按照一般规则，那些关键性业务服务（即有益于业务流程、能为机构争取竞争优势地位的服务）最好是由内部提供。

您很可能在服务的发现阶段就已经在内部把可以映射到候选项的服务识别出来了。例如，倘若贵机构拥有ERP或CRM系统，则主要界面（客户、订单、帐户）都 是可以加入到您的组合中去的服务。已经在企业内部使用的自定义应用程序可能也值得加以分析，以便识别可用的界面。

提供更多商品驱动的功能的服务（例如提供股票报价）可能是外部预订的候选项，很可能来自于贵机构已经与之建立关系的业务伙伴。一旦您开始搜寻符合您需要的服务，服务分类的需要便立即显现出来了。

显然，在识别候选服务时，有许多支持产物也需要创建和管理，例如，用于控制服务的策略；服务所使用的消息类型；以及将输入和输出消息转换成适当格式所使用的XSL转换。

创建一个这些产物及其相应服务之间的关系的目录将大大有助于构建您的组合。UDDI注册表对本任务来说是一个价值极高的工具，它使您能够构建一个服务和相关产物的完整的在线目录。

SOA管理需要考虑的事项

最好您的SOA基础架构能提供一个针对如下管理性能的平台：监控与诊断、外化的安全性、集中式审计与事件记录以及服务级协议与策略管理。有许多特定于 SOA的组件可以用来进一步提高管理能力，例如企业服务总线（ESB）可用来实现可靠的消息传递；业务规则引擎可用来捕获和自动化业务策略；业务活动监控 解决方案可用来优化服务。

采用中间Web服务管理服务器尤其受益。在这种配置中，服务通过一个向用户开放的代理URL被”虚拟化“，因此请求是通过媒介而不是直接发送到服务端点 的。利用本集中管理平台可在服务上统一地设置策略，并为运行时策略的执行提供了一个单独的点。它还简化了服务度量和使用情况统计信息（对维护服务组合的运 行状况至关重要的数据）的捕获。

服务虚拟化还具有提供位置透明度的优点：通过公开代理，可以在不影响服务用户的情况下对下部基础架构进行改动。该媒介必须维护其自身的虚拟服务到服务端点映射，或者利用UDDI注册表发现一个有效的服务端点。

结论：

SOA作为沟通IT世界和业务世界的桥梁这一论断在不断地发展着。服务组合的构建是一项时间和资源的投资，它必将在面向服务的业务应用程序方面带来巨大的回报。对这些面向服务的应用程序可以加以修改以满足企业不断变化的业务需求。