微软《SOA in the Real World》笔记06——第一章

微软《SOA in the Real World》笔记06——第一章

抽象的SOA参考模型

虽然计划周详和执行良好的SOA项目能够帮助组织在变动的市场中表现出极高的响应能力，但并不是所有的面向服务的努力都能成功。当SOA项目是由不熟悉组织战略的开发人员从下而上推动时，SOA只能获得有限的成功。没有参照业务场景，为SOA而建造SOA是没有组织原则和指南的项目。结果就是没有业务关联的混乱的实现。另一方面，从上而下的SOA方法需要相当长的时间，以至于项目完成时，解决方案已不能满足业务需求了。（这当然是SOA假定能够解决的问题之一！）

相反，微软提出了一个middle out（丛中间开始）的方法，该方法结合了从上而下和从下而上两种方法。在这种方法中，SOA努力是由战略愿景和业务需求驱动的，但通过渐进的、迭代的SOA项目来达到目标，这些SOA项目一次只交付一个满足业务需求的业务功能。从1999年.NET framework首次发布开始，微软就已经在使用这种技术来帮助客户进行他们的SOA行动了。

SOA的概念从几个可能的角度来审视。因为没有一个或一组这样的角度能够代表一个确切的SOA视图，所以从整体来看，这些角度能够帮助理解那些相关的架构需求。微软相信在SOA中有三个抽象能力层次：

层次的分类和他们之间的关系如下图所示：



暴露
暴露把重点放在如何把已有的IT投资暴露为一组广泛的、标准的服务，以便使这些投资能够为更多的消费者所使用。已有投资可能是基于异构的平台或是不同的厂商。如果这些应用程序本身不支持Web服务，就需要一组应用程序或者是一组包括特定协议的适配程序。面向服务可以是细粒度的（单个服务可以映射到单个的业务流程），也可以是粗粒度的（多个服务组合在一起执行一组相关的业务功能）。暴露同样关心服务是如何实现的。如果IT资源支持Web服务，就直接使用他们，如果不支持，就通过一个适配程序来使其支持Web服务。 “服务实现架构”一节揭示了如何开发、部署和管理服务。

组合
服务一旦创建，就能用来组成更复杂的服务、应用程序或者是跨职能部门的业务流程。由于服务是相互独立的，他们能够得到最大灵活程度地组合和重用。当业务流程变化时，业务规则和业务实践就能进行调整，而不用受到所采用的应用系统的限制。服务组合能够促进跨职能部门流程的出现，允许企业采用新的业务流程，调整流程以获得更高效率，或者是提高服务客户和合作伙伴的水平。“服务集成架构”一节解释了一组功能，这些功能可以把服务和其他组件组合成更大的组成部分（如业务流程）。组合服务需要某种工作流或者编排机制。Microsoft通过BizTalk Server 2006 (BTS) 或者是 Windows Workflow Foundation (WF)提供了这种机制。虽然BTS和WF可以满足相似的需求，他们实际上非常不同。BTS和WF是两种互不的技术，用来满足如下两种非常不同的需求：

BTS是收费产品，用于实现跨不同应用和平台的工作流（编排）。

WF是一个开发人员框架，用于在应用程序中实现工作流功能。使用和部署WF不需要费用和版权限制。

我们在第五章（工作流和业务流程）研究工作流、编排和BizTalk/WF的使用。

消费
当创建了新的应用或业务流程，新的功能必须能够被IT系统、其他服务或者是最终用户所访问（消费）。消费的重点是交付新的应用程序，用来提高生产力和增强业务的洞察力。用户能够通过多种方式来使用（消费）服务，这些方法包括web门户、富客户端、Office business application(OBA)和移动设备。可以快速地拉平应用程序的服务导致了新的业务功能，或者提高了生产力。这种应用程序的拉平能力可以用于测定SOA中的投资回报率（ROI）。“面向服务应用架构”一节解释了如何通过业务流程、新的服务或新的终端应用程序来消费服务的。这种概念有时被称为组合应用，这可能意味着服务是被终端用户所消费的。Microsoft的 Office business application(OBA)支持组合应用的实现，这种实现是中交易系统，并通过常见的Office环境扩展了用户界面的范围。

我们在第五章（用户体验）中更详细地研究消费。

在暴露/组合/消费中描述的架构可以是相互独立的，是松耦合的。这使得服务的管理、版本处理和配置独立于服务是怎样暴露的。