系统技术架构

1.1. 系统技术架构1.1.1. 总体架构广东网通BSS系统重构项目的主要技术目标包括提高应用系统的可重用性和流程的可配置性，以解决在业务快速变化的市场环境下，如何保证业务支撑软件及时交付高质量的软件版本，同时尽量降低业务软件的重复性开发工作量。为了满足日益复杂的业务需求，确保能够在第一时间里推出市场所需的服务、并且业务支撑系统的改动量最小，我们建议在系统中采用SOA架构。SOA是从企业的需求开始，把IT系统和商业流程连合在一起，以服务集成形式实现新的而又灵活的应用功能。SOA简化了IT，让IT变得更有弹性，以便更好地发展和优化业务流程，从而促进企业与合作伙伴的业务需要，也使供应商和客户之间动作流程的端到端整合，让企业可以快速灵敏地响应客户和市场不断变化的需求。SOA能够加强对整个企业架构的控制能力；并且由于具有高级别的重用性，有助于提升开发效率，加快开发速度；采用只需少量改动的核心企业级IT应用，让运营企业和厂商只需优化基于标准技术的IT技能，从而降低了在客户化和人员技能方面的投入，从而节约了成本。以SOA在基础，结合功能和非功能性需求的考虑，我们对广东网通BSS系统给出如下的系统架构：在系统架构中，不同的功能可以被分为纵横几个不同的层次，基于底部的是服务的提供者，上面则是服务的消费者：l 资源层指系统已经存在的程序资源，例如网元操作平台、银行系统等外部系统，以及BSS系统自身的数据等。l 组件层在这一层中用不同的组件把底层系统的资源封装起来。l 服务层在这层中用底层功能组件来构建所需要的不同功能的服务。l 商业流程层在服务层之上为商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。流程是可以组合的，一个流程可以作为另一个流程的子流程使用，更好地提供了流程的重用性及灵活性。纵向贯穿系统的是集成架构和基础架构，集成架构的核心为企业服务总线（ESB）；而基础架构则为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。将体系架构映射到J2EE的技术平台上面，可以得出如下的模型：这是一个扩展的J2EE架构实现，表示层的内容可以运行在WEB容器之上，商业流程、服务层、组件层的内容则会运行在EJB容器之上，基础架构的安全，管理及监控也会实现成EJB容器之上的服务，而一般来说，现有的应用服务器都可以提供企业服务总线的功能。这个实现除了支持Web应用之外，还支持J2EE的远程客户，具有远程EJB的分布式应用，以及其它类型的客户端。该体系结构在WEB层（或者是其他远程客户）与业务对象之间使用RMI，WEB层通过业务接口和业务委托来远程访问业务逻辑会话EJB，业务逻辑处理数据，然后业务逻辑会话EJB通过DAO访问数据存储，也就是把数据持久化。这种架构的最大好处是通过一个中间层来支持所有的J2EE客户类型；还允许各种构件在不同的物理服务器上分布；这样给应用实现最大的可伸缩性，EJB容器为远程客户提供一个综合性接口。1.1.2. 表示层Web界面及Web服务接口这一层用来与用户交互，并把来自系统的信息显示给用户。J2EE使用JSP/Servlet技术支完成这一层的任务。这里，我们引入JSF、JSP标准标记库和AJAX技术，应用框架采用改进过的Struts2。Web服务接口标准（比如SOAP）不再要求使用RMI和EJB来支持远程客户，从而使客户的远程访问不必使用EJB接口。传统的Web服务接口运行在同一个Web容器中。使用SOAP基于XML，并且是自描述的，这样的服务标准具有跨平台性，支持J2EE客户之外的客户，比如日后的电话语音订货系统与互联网系统等应用。Web服务传输协议运行在HTTP上面。1.1.3. 接入服务统一接入平台对于其它类型的客户端，BSS系统构建统一接入平台，为其提供服务。建统一接入平台包含了接口连接管理、接口逻辑管理和接口服务三部分： l 接口连接管理：提供接口接入处理完整的管理功能，在接口连接管理中包含了传输管理、通讯服务、负载均衡、动态配置管理、网络调度等功能；l 接口逻辑管理：提供了和接口业务相关的数据管理、优先级管理、交换分发和完整性管理等功能；l 接口服务：是对BSS系统服务层提供的商业流程封装后提供给对端系统的相应服务，以阻断对端系统和业务层的直接通讯，同时安全高效的支持外围接入服务。1.1.4. 表示层业务接口业务对象对外暴露为EJB，在Web组件层与业务对象之间使用RMI（远程方法调用，当然，远程方法调用的通信细节由容器来实现并隐藏），为了减少远程调用的性能开销，系统架构采用常用的设计模式业务接口和接口实现业务委托来处理对远程EJB的访问。另一方面，由于EJB对象的查找及实例化是相当消耗系统资源的，业务接口可以缓存EJB对象的远程句柄，这样节省了查找和实例化的时间，从而提高系统的性能。1.1.5. 逻辑层业务逻辑EJB这一层处理应用的核心业务逻辑。所有的业务组件都实现为EJB容器内的Stateless Session Bean组件。EJB容器提供了业务组件生命周期管理、多线程调度、同步处理、事务管理和资源分配等，这样业务组件只需要专注于业务需求的实现即可。由于业务逻辑都集中在EJB组件实现，而客户端只用来与用户的交互，这样保证了业务逻辑的统一。如上所述，J2EE结构中的逻辑层，对应于我们系统架构中组件模型的组件层、服务层及流程层，也就是说，我们将使用EJB去实现组件、服务及流程。首先，我们使用EJB去封装后台数据库的数据对象（通过DAO去访问数据库），由于系统涉及到多个数据库，这样可以使上层的应用忽略了数据的来源，并且提供了基本的事务功能。在封装数据对象之后，我们同样使用EJB去实现一些基本的服务功能，这些EJB的粒度将会比较细，只完成单一的功能，如客户资料查询等。最后，我们再使用EJB，将细粒度的服务组件按商业流程连合在一起，完成更完整的流程。在设计的理念上，流程是可以组合的，一个流程可以作为另一个流程的子流程使用，更好地提供了流程的重用性及灵活性。甚至在发展到一定的程度后，可以引入工作流引擎，如BPEL，通过描述的方式去定义一个工作流程，从而使整个商业过程灵活可配置，面向业务人员。1.1.6. 逻辑层规则引擎使用规则引擎（如：ILOG），可以在原有的业务逻辑层中抽取出业务规则层，一方面实现应用逻辑与业务逻辑松散耦合，使系统能够在用户期望的时间规定内完成业务需求功能；另一方面从体系架构上保证业务规则层能够在BSS系统的各个功能模块中具备业务编辑配置能力。规则管理系统功能主要包括一下模块:1. 规则的设计与编辑模块2. 规则调试分析模块3. 规则管理模块4. 规则执行模块如下图所示，使用ILOG规则引擎，可以较大程度的提高系统的灵活性，不过，使用ILOG规则引擎也会导致程序性能有一定成都下降，这是因为程序每次执行前都需要访问规则库，并进行规则比较。另外，使用ILOG规则引擎也会在一定程度上增加操作复杂性，这是因为要进行规则配置。因此，ILOG建议应用在规则变动较频繁，而且可以通过灵活配置而不修改程序可以实现的模块。ILOG建议应用在规则变动较频繁，而且可以通过灵活配置而不修改程序可以实现的模块。1.1.7. 商业流程工作流引擎流程做为SOA世界中重要的概念，有个方面的问题可以关注，一是业务流程的建模，是指使用流程进行建模反应业务需求。 二是工作流的应用，其实工作流是前者的一个子集，强调人机交互，人工干预流程(通常是长流程)。 而业务流程中是可以没有人工干预的，其中一种观点就是，将商业逻辑用规则引擎管理，这样人干预的节点越少，做为企业来讲，流程的效率越高，从中获取的商业利益也越大。 在这个领域，工作流管理的概念在前，其标准WFMC也经历了很长时间，但一直没有得到很好的应用和推广。而是近几年随着SOA概念的推广， OASIS的BPEL 越来越多的被关注，现在版本是2。0。 BPEL的全称是WS-BPEL。这个标准是基于WebService的。 所采用的引擎是否一定要实现某某规范和标准值得探讨，因为当前流程这方面的标准规范存在的太多，也没有一个强势的标准(最强势的现在来看也是bpel了)。但从功能上，流程引擎(或者扩展后的流程系统)需要支持下面几种要求： 图形化的流程定义。能够 API灵活易用。流程容易开发。 清晰的流程概念和运作方式，一定要具有人机交互能力。(角色，权限相关联) 支持流程的热部署。 提供灵活的扩展方式，良好的和外部系统/模块的交互能力(本地代码交互和分布式的系统的交互)。 如果做为模块，能够易集成。 完备的文档及其他可寻求的帮助方式 以上几点依次从流程分析定义，流程开发，流程部署，流程运行期和外部的交互， 如何集成等几个方面进行考虑。 大概比较一下基于BPEL的引擎和JBPMl BPEL优势 符合最流行的流程标准规范。 适于大规模编程，集成特性好。 良好的图形设计工具。 是SOA重要的组成部分。 劣势 比较复杂，或者说很复杂。需要非常了解BPEL标准。(如何利用bpel设计流程?) 一定要熟悉webservice的开发和其相关的标准。注意: 以上两项如果有现成的封装并且团队中已经有人熟悉问题也不大。 依赖特定引擎实现 本地代码交互。 依赖于特定的引擎实现人机交互。l JBMP优势 简单易用的编程模型。做为模块容易集成。也可设计成子系统。其概念模型也很清晰。 良好的基于eclipse的图形设计工具。(易用性强) 很灵活。 可以方便的测试流程设计(脱离数据库运行)。 易于扩展。 内部已有比较好的研究。相关社区比较活跃。劣势 不是标准(jbpm 有一个子项目支持bpel) 在大规模集成方面不如BEPL相关实现。无论是采用哪种实现方式，最好都能了解流程设计的pattern， process design pattern 是流程设计中常用的一些场景，可做为原子组合成复杂的场景。 对日后快速建模提供相应支持。1.1.8. 资源层DAO这一组件用于处理存贮系统的数据。业务组件通过调用DAO组件实现对数据库的操作。DAO实现了用来操作数据源的访问机制。数据源可以时RDBMS，LDAP，File等。依赖于DAO的业务组件为其客户端使用DAO提供更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当低层数据源实现变化时，DAO向客户端提供的接口不会变化，所有该模式允许DAO调整到不同的存储模式，而不会影响其客户端或者业务组件。重要的是，DAO充当组件和数据源之间的适配器。使用数据访问服务层之后，BSS系统实现了几个重要的效果：l 透明性业务对象可以是使用数据源，而无须了解该数据源实现的具体细节。访问是透明的，原因是实现被隐藏在DAO的内部。l 更容易的迁移DAO层使应用程序更加容易地迁移到一个不同的数据库实现。业务对象不了解低层数据实现。因而，该迁移只涉及对DAO层的变化。更进一步说，如果使用工厂策略，则有可能为每一个低层存储实现提供一个具体工厂实现。在这种情况下，迁移到不同的迁移实现意味着给应用程序提供一个新的工厂实现。l 减少业务对象中代码复杂度由于DAO管理所有的数据访问复杂性，它可以简化业务对象和其他使用DAO的客户端中的代码。所有与实现有关的代码(比如sql语句)都被包含在DAO中，而不是包含在业务对象中。这样做提高了代码的可读性，已经代码生产效率。l 把所有的数据访问集中到一个独立的层。因为所有的数据访问操作现在被委托给DAO,所有单独的数据访问层可以被看作把数据访问实现与应用程序中的其他代码相隔离的。这种集中化使应用程序更容易地维护和管理。这里，我们使用了一个第三方的LIBHibernate。Hibernate相对于Entity Bean来说，性能高了不少。还有一点的是，Hibernate将会是EJB 3.0的CMP底层实现机制，那意味着Hibernate是一个很好的产品，并且会发展下去。1.1.9. 资源层外部后台系统接口外部后台系统接口负责管理与外部后台系统的连接，访问外部系统数据，调用外部系统的功能。外部系统接口组件提炼、封装了对外部系统的访问，向使用者业务逻辑组件，提供统一的API，那么，一方面将外部系统的访问细节，如系统登录、语法语意的转换、日志记录等，完全隐藏起来，使得业务逻辑组件有一个很简单的调用；另一方面，外部系统的改动将不会影响到本系统的业务逻辑，只需要适当修改外部系统接口组件就可以了，从而降低外部系统和核心业务组件的耦合。