SOA Methods 从金融案例谈服务规划与实施方法论.ppt

* 1 minute. * 测试是针对合约的 * * 1 minute. * * * * 虽然是在开发应用系统时同时构建的，但共享服务有独立的生命周期。共享服务之间，以及服务与应用之间，其生命周期并不同步。 因此，把所有的共享服务打包在一个部署单元，以及把共享服务作为应用的一部分部署，同样是不合理的。 通常，使用相同db schema和访问相同后端系统的服务可以部署到一个单元中。 总的原则是，具有独立的生命周期的服务或服务组，应部署到独立的单元中，可以实施独立的版本和运行管理，这也是系统敏捷性的要求。 * * 有三类工具可以帮助组织和控制元数据与软件资产 他们具有截然不同的目的，为特定的用途进行优化，面向特定的用户 * 2 minutes. 总结它的定义 Good place to talk about the typical scenario where a customer needs a project done, and states that they would like it done using SOA? SOA is not an application architecture! * * 13，返回并生成一个投保单和保单（核保校验动作） 12，发送查询吗到交强险平台，返回确认码 12，确认码到核心进行投保。 正确的方式 14，15合并成核保申请服务，放在12步之后 16，17，18为一个服务，返回结果为预保单 19后增加一个服务为，发送查询码到交强险平台，预确认 24之前，发送预确认码去交强险平台 * Complete SOA reference architecture logical view * Complete SOA reference architecture logical view * * 增加信息和访问服务（交强险，车船税，银行网关） * * * 2 minutes. 总结它的定义 Good place to talk about the typical scenario where a customer needs a project done, and states that they would like it done using SOA? SOA is not an application architecture! * ESEF是一个轻量级的交付方法，所以它是传统交付方法的扩充和协同： 工程交付由两个并行的轨迹组成，其一是服务工程轨迹，完成SOA的服务交付， 其二是传统的项目交付轨迹，负责交付共享服务之外的业务需求。 由此可见，完整的服务交付流程是采纳SOA的企业对原有软件开发流程的一种自然扩展，它并不是具有特殊目的的、孤立的流程实体。 * * 按照时间的顺序，分析关联关系 * * * 以往的应用系统往往是针对部门独立开发的，传统的需求管理方法，只针对应用系统调研就足够了。 而SOA是面向全企业的，因此传统的需求管理方法，首先在管理范围上就很窄小。 此外，SOA的需求是企业级的需求，它用于构建企业功能模型，有独立的分类方法，有独立的生命周期（相对普通应用需求）， 不能与应用需求混为一谈。 例如对于“产品需求”，在市场部门是一个定义，在销售部门又是一个定义，在客服部门可能还有一个定义， 这里就有一个如何综合分析，多个项目需求精炼出企业需求，并且独立管理的问题。 因此SOA 需求管理是对传统需求管理技术的扩展 和补充 * 通过数据模型和流程模型分析，得到服务候选， 服务候选可能被实现为一个真正的服务，也可能被打回到原项目中作为普通功能实现。 为了作出这样的决策，需要考察已有的服务、已有的功能实现等多种因素。 最后形成服务候选建议和SOA发布计划。 * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * 1 minute. * * 服务交付就是将服务候选交付为一个或多个服务。它包括若干交付阶段，可以概括为四个核心的工程活动： 定义：从服务候选中定义服务合约。 设计：为服务设计接口，实现重用最大化，在合约和消费者重用之间寻求平衡。 实施：不仅仅是写一些实现接口的代码，最佳实践是使用小型的传统软件工程方法实施。包括：设计、代码开发、测试、配置管理等活动 测试：独立与实施，针对合约进行测试。 * 在制定服务交付的方法的时候，必须实现要了解我们要处理的客体：服务的特性，也就是服务的组件和服务的生命周期。 服务的组件包括 服务的合约：表达了消费者对服务的要求，也就是服务需求； 服务的接口：是服务设