技术开发 频道

理解SOA中的服务生命周期:运行时

复合应用程序和服务分层

    此前,我描述了传统应用程序开发和SOA实践之间的差异,SOA实践是一种突破单体应用程序的局限性、缩短开发/发布/测试周期的途径。只有专注于复合应用程序的概念才能获得这样的敏捷性。按定义来说,复合就是把一些现有和新建服务装配到一起,从而创造出满足业务需求的新功能。在成熟的SOA环境中,通过使用为快速满足业务需求而复合的现有服务,即可将完整的业务应用程序可能装配在一起。为确保此供应过程的灵活性,服务工程团队在设计时必须非常谨慎,避免把业务逻辑编码到服务实现中。另外,为了保证在供应时不会丧失这样的敏捷性,SSLC的运行时阶段应集中保证服务契约、策略和元数据不会给未来的需求造成阻碍。获得这种运行时灵活性的一种方法就是要设计和提供一些服务,来定义一些层,这些层可能会形成系统的逻辑和概念分层。
    在SOA计划中,复合是通过以高度有序的方式利用现有资产的能力而实现业务灵活性的一个完整组成部分。以我的经验看来,许多企业在过于细粒度的层面上开发服务,以至于许多小的特定服务的增殖难以复合成更大的逻辑服务。对服务定义和构造采取分层定义的方法,服务工程团队更可能获得满足现在和未来业务需求所必需的粗细粒度合理的混合服务。
    为了说明分层服务的概念,我们来考察一下需求目录(如上图2所示)中定义的电子商务和企业内部网示例,它确定了整合组织的企业库存系统和相关流程的的长期需求。BEA SOA Domain Whitepaper(PDF)中定义了许多可能存在于企业面向服务环境中的逻辑层,它们构成了SOA参考架构的一部分。这些层——信息和访问、共享业务服务、复合服务和表现服务,是定义职责分离的较好途径。我们还可以从更为细粒度角度观察服务需求,从而进一步分解这些服务。这样的角度应对了把服务组织成物理、规范、逻辑类和应用服务类的需求。下面就让我们详细地了解它们。

    物理服务
    信息和访问服务可能表示以原始形式检索数据的功能。看一下需求目录,需求之一就是要能读取订单。物理服务可按照与图3类似的方式定义。


图3 订单物理服务


    以上定义的物理服务可构成企业参考架构的信息和访问层的一部分。这样一个服务应该支持特定数据源上的细粒度CRUD(创建、读取、更新、删除)操作。

    规范服务
    规范服务定义企业信息的标准视图。通常,这样的视图会使用像SWIFT这样的业界标准格式或其他特定于企业所属行业的标准。通过建立通用的混合语,清晰的生产者层(producer layer)就开始成形了。这个标准层独立于物理服务,可作为共享服务或复合应用程序的起源使用。
    从上面定义的物理服务可以看出,物理服务已被建模为返回一份订单的原始表示。服务工程团队现在必需实现一个概念层,来返回标准规范模型。一开始,如果订单服务返回了所需的一切数据,您也许会觉得订单的规范模型没有存在的必要。再看看前面服务工程团队开发的需求目录,它显示出,这个假想的企业不只有用于书籍或录像的库存系统,从长远角度来看,企业还有整合这些系统的要求。在抽象层面上定义同时表示书籍和录像的标准规范,您也就开始以一种非常灵活的方式获得这种透明性了。
    图4所示的订单服务定义为接受标准规范,这种标准规范以xml模式定义,与以传入的xml文档为基础的多个库存系统交互。


图4 基于规范的订单服务


    服务实现以消息上下文为依据,处理需要物理库存系统的逻辑。

    逻辑服务
    在企业内建立标准规范结构时产生了一个问题,就是这些结构需要支持大量的数据资源占用。结果,当服务的所有使用者真正想要的是结果的较小子集时,由于从此类一般服务返回的信息过多,使用者可能要担心性能降低。建立逻辑服务提供了更细粒度级别的交互,而不会牺牲在规范结构上构建的好处。而且,上游应用程序(upstream applications)可能需要对信息进行逻辑分组,例如客户的单一视图。标准的逻辑服务提供了复合功能,还提供了重用和缩短上市时间等立竿见影的收益。目前的工具,比如BEA的AquaLogic Data Services Platform,也提供在执行时编译出(compile-out)这些层的功能;这就带来了高度优化的查询,而不会牺牲设计时和运行时的灵活性。图5的示例定义了客户配置文件服务,它提供了消费信息的逻辑分组。


图5 客户配置文件逻辑服务


    为了为下游服务(downstream service)的使用快速提供标准应用程序结构,而且几乎不需编写新功能,该客户配置文件服务描述了在整个需求目录中复合服务的能力。

    应用服务
    最后,服务工程团队可能会开发许多应用服务,旨在供应用程序以独立于业务线的方式直接使用。需求目录中,有两种特顶的受众可能对客户配置文件服务感兴趣:想要更新信息、核对订单等等的实际客户;可能有兴趣在所有订购了某本书籍(举例来说)的客户上运行报告的内部网用户。结果是,服务工程团队可能会生产两种特定于应用程序的服务。正如SOA Domain Whitepaper(PDF)中定义的那样,这些服务可能通过像portlet这样的表示服务而公开。

0
相关文章