金蝶BOS的SOA技术实现

***BOS的SOA技术实现

如上图所示，***ERP的技术体系主要由四个层次和一套完整的生命周期管理工具构成，而这五部分的集合按照现在业界的划分称之为“业务基础软件平台”，在***软件的产品体系中他被命名为***BOS（业务操作系统）。

传统的分布式N-tie（三层）架构的应用程序，在软件功能的组件化的方向上取得了长足的进步。组件化的封装让组件之间通过接口的方式进行通讯，增强了复杂而庞大的应用程序本身的可管理性，包括对版本的管理、应用部署的管理等，同时在一定程度上也提高了功能模块在飞速增长过程中软件质量的一致性。但N-tie技术架构随着管理软件复杂度的爆炸性增长，其历史局限性不可回避的呈现出来：

N-tie技术架构的组件颗粒度和接口的划分没有实际的标准和规则，一个组件可以大可以小，接口也可以随意定制，除了一定要符合编程语言的语法结构之外基本上没有可以控制的手段，完全依靠组件开发人员的分析与设计能力。

N-tie技术架构的组件内部构造的可视化程度很低，当开发人员在添加新功能和对组件进行修订的时候，面对一个或大或小的组件黑盒，无法准确的理解组件所暴露出来接口的含义，组件之间的透明式的通信难以实现，要进一步的修改组件的处理逻辑就更加困难。

N-tie技术架构无论最终采用B/S或者C/S的系统访问结构，都是针对特定的技术平台的硬编码，包括服务端所使用的应用服务器、数据库与操作系统。整体系统在企业客户上线时，对IT的基础设施的投资要求比较高，如果需要进行技术平台的迁移和审计，涉及到对系统的整体改造，需要付出昂贵的代价。

N-tie技术架构更多的着重于解决系统开发的可管理性，但在信息系统的应用模式上仍然保留着从DOS时代开始的“菜单”模式，强调与突出系统的结构性。在体系结构的规定上并没有给用户带来操作感受上的提升，用户需要在浩如烟海的功能与菜单中不停的探询或者长时间的培训才能找到具体需要处理的工作。所以在N-tie技术架构下诞生了一个个的功能堆砌的庞然大物，满足了越来越多的应用需求，但却加重了用户的操作负担。

基于***BOS构建的***ERP遵循SOA（Service-Oriented Architecture）的架构体系，有效继承了N-tie技术架构的优点，锐意在N-tie架构的历史局限性上寻求突破并创新，而且已经取得了良好的用户反馈。

信息门户

信息门户是将企业不同角色的相关人员通过Internet紧密地结合在一起协同工作，并能有效整合第三方的系统。对应到SOA的“访问服务”（Access Services）。

信息门户的诞生不仅解决了管理系统跨互联网对应用系统访问的瓶颈，只要有网络的地方就可以享受到信息系统带来的便利。而且在用户进入***ERP后，可以直接使用根据不同的岗位、职责所设定的甚至按照自己需要定制的个性化门户，可以在短时间内找到自己需要在ERP系统里所需的内容和操作，加快用户上手的过程。

在企业使用了多套系统的时候，信息门户的单点登录（SSO）所带来的效益更加明显的。单点登录技术是一种认证和授权机制，它允许用户只登录到系统上一次，而后授权访问其他连接的系统，无需再进行登录。这样不仅仅增加了用户操作的便捷性，同时因为SSO登录可以使用数字“证书”等等多种身份认证的手段来代替静态的用户ID／口令，系统的安全性得到大大的加强。实现认证和授权的集成还简化了雇员离开公司后的清洗工作。管理人员不用再跟踪雇员可能访问过的所有系统和资源，只要简单地删除掉这名雇员的SSO账户就行了。

信息门户中访问的内容主要分为三类：

1.业务协作

2.流程中心

3.管理分析

业务流程

业务流程是由各类服务组件按照特定的规则组装而成，对应于SOA中的“集成服务”（Integration Services）。通过可灵活配置的流程引擎、可视化的流程展现，用户可以随时查阅每一项业务的流程的规则、路线、处理状态及参与者，并根据实际的业务的变化对流程进行调整。用户的操作不仅变得更加简单和直观，由传统的“人找事”转向了真正的“事找人”，而且系统的灵活性与可扩展性得到了空前的提升。

业务流程包括了对流程控制的管理，还包含了流程中数据状态转换的管理。让计算机数据贴切的模拟出了丰富多彩管理活动的同时，通过可视化的展现形式，让这一切变得不再冰冷进而鲜活的跃然于纸上。于是业务流程不再单纯的一项计算机技术的突破，让企业客户与合作伙伴可以低成本的根据业务实际情况进行业务流程的更改，同时也有效促进了管理的科学化。它不仅通过实现流程可视化管理，可以对各业务处理流程进行监控和优化，剔除流程盲点，突破流程瓶颈，而且可以通过对业务工作量、人员配置、工作效率的分析，为企业进行工作负荷分析、流程重组、人员优化提供科学的依据。

业务服务

业务服务提供了统一的业务组件标准，规定了业务组件的用户访问行为、数据组织方式、功能封装方式、业务处理逻辑的标准“语法”。对应于SOA中的“应用程序与数据服务”（Application and Data Services）。

在N-tie的架构中，我们也有看到组件标准，但是它的标准是更加底层的，通俗的说是更加技术化的。譬如如何的实现远程的方法调用，如何实现数据库的连接等等。而在***ERP中业务服务的标准是面向应用的，譬如不同的公司在处理不同类型的订单时应该录入和关联什么样的数据，不同业务处理类型的公司在合时的时候开发票，不同类型的采购业务完成后应该如何更新库存等等。这种服务的封装在包括***软件等国内外的大批软件厂商在内，他们过往的产品中都有一些的阶段的成果，但业务服务提供了一整套规范化的标准和严格的要求，为组件之间通过接口进行通信提供了有效的保障。

业务服务不仅保障了遵循其标准的应用程序，在针对具体的应用需求，可以将不同的业务作为功能插件连接在业务流程上，并可以根据用户的需要来决定是否使用甚至更换。同时通过实现了应用程序与数据服务的分离，让基础数据不统一而带来的繁重的信息集成的噩梦得以化解，我们甚至可以将供应商、客户、职员、物料、银行账户等数据服务单独的进行安装与部署，供以各种不同的应用系统使用。

一个业务组件由四个基本要素构成：

1、组织架构管理（Organization Mgmt）：负责约定业务组件的外部访问模式，包括对系统用户的管理、权限分配的管理、组织结构策略的管理。

2、主数据管理（Master Data Mgmt）：负责为业务功能和流程提供统一的基础数据的管理，譬如客商资料、银行账户、商品物料、会计科目等内容，。在基础资料统一的前提条件下，不同的业务功能之间的交互只用提供基础资料的编号就能够准确的理解操作的具体含义。

3、业务服务（Business Service）

4、业务流程（Business Process）

基础平台

基础平台将包含有各种底层存储、计算和传输的技术细节通过封装进行屏蔽，有效降低系统集成、应用部署的复杂度。对应于SOA中的“部署服务”（Deployment Services）以及安全性和管理服务（Security and Management Services）。

基础平台的概念曾不止一次的泛滥成灾，所有只要和具体的应用程序不相关的，作为技术底层服务的内容，都被概括为“基础平台”。于是数据库、操作系统、应用服务器似乎都可以称之为“基础平台”。

在***ERP产品的技术体系中，基础平台有其明确的定义和清晰的内容。主要包括用以支撑业务服务所定义的组件标准：

多通道访问引擎：用以解决如何通过手机、PDA、邮件等多种访问方式来访问业务组件所提供的功能和获取存储在数据库中的信息。

消息引擎：解决流程驱动下人机交互过程中，将各流程节点的操作提示和系统通知、预警等信息发送到用户的消息中。

发布引擎：用以解决将按照业务服务标准进行封装的业务组件，快捷的发布到***ERP系统之中，并保障不同的组件之间无缝的信息集成与共享，发布引擎同时屏蔽了不同厂商的应用服务器的技术细节的差异。

流程引擎：是业务流程中的控制流程，根据已定义的流程路线依据不同的规则，将任务有效的分配给人工处理或者交由预定义的自动节点进行处理。流程引擎同时提供对流程运行状况的监控与管理。

集成引擎：集成引擎更像一个信息的路由器，它能根据已定义的异构系统之间数据交换的映射规则，将数据中转和路由到需要集成的系统中。集成引擎是可以通过业务操作触发驱动或者按照时间规则进行调度执行。

规则引擎：规则引擎可以用来定义复杂的业务逻辑，流程跳转规则、数据转换规则、数据筛选规则、事务预警规则、任务调度规则等多种包含复杂逻辑关系的处理，都可以统一的通过规则引擎进行解析。

分析引擎：能够提供对数据库数据进行报表展现前的数据加工，分析引擎可以将多个相关的二维数据表转换成三维表结构，同时也可以提供结果集级别的分类汇总、小记、汇总和数据筛选等特性。

安全引擎：解决应用程序功能的访问权限，数据记录访问权限，组织架构隔离权限等数据安全性问题。

数据访问引擎：解决SQL Server，DB2，***等主流数据库SQL语法差异的屏蔽层，按照KSQL语法编写的SQL语句能够自动翻译成不同数据库的SQL语句。