应用支撑平台技术白皮书

应用支撑平台技术白皮书

版本：1.9

https://www.sodocs.net/doc/6e13981749.html,

白杨应用支撑平台技术白皮书版本控制

版本号修改时间修改内容修改人审阅者

1.0 2007-07-21

创建，从老版概述文档迁移白杨

白杨

修正文档组织结构（6.3.3 -> 6.4）；

1.1 2007-08-09

纠正个别措辞

新增 web 应用扩展库说明白杨

1.2 2008-01-04

加入 bz2 算法支持白杨

1.3 2008-03-19

更新 AIO 框架；新增 SCGI 支持白杨

1.4 2009-12-02

重构文档；新增 HTTP 支持白杨

1.5 2010-04-27

新增 Web 框架性能比较表白杨

1.6 2010-06-13

新增HTTP Pipelining描述白杨

1.7 2010-07-06

白杨

1.8 2010-08-25

根据近期底层库的调整新增 LRU

Cache等组件

白杨

1.9 2010-08-27

新增典型的Web应用节点工作模型

说明

白杨应用支撑平台技术白皮书前言

白杨应用支撑平台从2002年发布第一版以来已有超过8年的历史了。在这8年多里，我一共为支撑平台编写了超过50万行C/C++代码。其中最基础也是最重要的libutilitis库基本上是完全由我亲手实现的。因为要实现libutilitis中包含的大量跨平台功能封装，除了原本就比较了解的Windows平台，我也逐渐熟悉并喜爱上了Linux、FreeBSD/NetBSD/OpenBSD、OpenSolaris等优秀的操作系统。

对于支撑平台中的其它库，我的主要做法就是以libutilitis为基础，设计一套界面/框架。然后依赖没有版权问题而且品质稳定的第三方代码来实现具体功能。例如：libcrypto中的密码编码学和数据压缩算法；libaudioio中的音频编解码器等等。

多年来，基于支撑平台的各种产品已被广泛部署于兴业银行（China CIB）、中石油（CNPC）、华安保险（Sinosafe Insurance）、淘宝网（https://www.sodocs.net/doc/6e13981749.html,）、法兴银行（SOCIETE GENERALE）、德尔福汽车（Delphi）、美联航（United Airlines）、GE（美国通用电气）、贝塔斯曼（Bertelsmann）等各大企业的生产环境中。生产环境下的大范围部署不但为上层应用提供了可靠的、平台无关的底层环境，也进一步检验了可靠性、稳定性、可移植性、高效性等各方面指标。

白杨应用支撑平台技术白皮书目录

版本控制............................................................................................................................................................................I 前言...................................................................................................................................................................................II 目录.................................................................................................................................................................................III 1概述. (1)

2总体构架 (2)

3跨平台基础功能库－LIBUTILITIS (4)

3.1基础模块－BASE (5)

3.1.1.基础模块底层 (5)

3.1.2.基础模块界面层 (5)

3.2系统工具模块－SYSUTIL (8)

3.2.1高效IO框架 (11)

3.3通用工具模块－FACILITY (12)

3.3.1.Web扩展框架 (16)

3.3.2典型Web案例 (21)

3.3.3FastCGI？SCGI？HTTP！ (27)

4跨平台密码编码学算法库－LIBCRYPTO (28)

4.1密码编码学算法模块－ALGORITHM (28)

4.1.1支持的块加密算法 (29)

4.1.2支持的流式加密算法 (30)

4.1.3支持的公钥算法 (31)

4.1.4支持的散列算法 (31)

4.1.5支持的消息验证算法 (31)

4.1.6支持的数据压缩算法 (31)

4.1.7支持的数据编解码算法 (32)

4.1.8优质随机数生成算法 (32)

4.2通用工具模块－FACILITY (32)

5跨平台音频IO库－LIBAUDIOIO (33)

6跨平台国际化GUI组件框架－LIBMLGUI (35)

6.1文件系统扩展 (37)

6.2国际化组件库 (37)

6.3快速帮助框架 (39)

6.3.1快速帮助机制 (40)

6.3.2扩展的快速帮助机制 (41)

6.4通用图形控件 (41)

7应用支撑平台的错误处理机制 (45)

白杨应用支撑平台技术白皮书1概述

应用支撑平台是一个产品的基石，也是产品与操作系统之间的通信接口，应用支撑平台在完整封装操作系统功能的同时，还提供各种通用工具。作为重要的通用组件，应用支撑平台在快速开发高质量跨平台应用中起着重要作用。

应用支撑平台为产品中的其它组件提供了众多通用功能，包括：

跨平台底层支持：封装所有与操作系统相关的操作，如：信号量、原子操作、共享内存／

文件映射、线程、网络操作（Socket）、文件管理、服务控制、注册表访问、进程间通讯、

服务器框架等等。是管理系统实现跨平台、多平台的关键组件。

通用功能：包括用户权限管理、基于PKI体系结构的强加密、常用网络协议、二进制和字

符集编码转换、自动化脚本引擎、表单处理、数据压缩、任务管理、日志记录、音频IO、

音频格式编解码、音频效果器、HTTP 协议和Web应用扩展等等。

跨平台GUI设计框架：封装各类窗体、控件、系统消息机制等系统相关功能，为GUI应

用提供一个统一的，平台无关的设计框架。

平台无关的国际化支持：结合跨平台GUI框架、为用户提供一个平台无关的多语言、国

际化工作环境。

白杨应用支撑平台技术白皮书2总体构架

作为所有其它组件的基础，应用支撑平在开发环境（硬件平台、编译环境和操作系统）与软件设计师之间提供一层平台无关的封装，为开发者提供一套可靠、高效、易用的跨平台通用功能组件和设计框架。

图表 2-1

如图表 2-1所示，应用支撑平台由以下相互关联的几个组件构成：

libutilitis：封装所有与硬件平台、编译环境及操作系统相关的基础功能，并以此为基础，

提供一般性的通用功能和设计框架。

libcrypto：依赖libutilitis和第三方密码编码学算法库及压缩算法库实现。封装所有密码

编码学和数据压缩、编码算法，并以此为基础实现一组与之相关的通用功能。

libaudioio：基于libutilitis实现，为用户提供一套平台无关的音频IO机制，同时提供各

类音频格式的编解码器和一些通用效果滤镜，并在此基础上提供音频播放和录制等通用

工具。

libmlgui：基于libutilitis和wxWidgets框架实现。为用户提供一整套平台无关的国际化

在以下各章节中，我们将逐一介绍这些组件。

白杨应用支撑平台技术白皮书3跨平台基础功能库－libutilitis

从体系架构上看，支撑平台位于整个产品的最底层，而libutilitis又是应用支撑平台的基础构造。libutilitis的主要工作是封装所有与底层硬件平台、编译环境及操作系统相关的各种细节，向上呈现一个易用、一致、平台无关的开发接口。同时在此基础上提供一些常用工具和功能框架。

图表 3-1

如图表 3-1所示，libutilitis本身又可分为如下3个相互依赖的模块：

白杨应用支撑平台技术白皮书3.1 基础模块－base

基础模块封装硬件平台和编译环境相关的细节，为上层提供一致的基本工具。

在着手开发一个软件模块的时候，我们总是希望能为用户提供最强大的功能、最灵活易用的界面、所有细节都实现的健壮、敏捷、优雅而富于美感、又不失效率……遗憾的是，在大多数时候，能够同时满足这些条件的事物并非当前人类文明所能企及。很多时候，我们不得不在一些方面做出痛苦的妥协和折衷。

因此，在开始设计前，事先权衡各个要素的重要程度是十分有必要的。这使我们能够开发出行为一致，容易理解的界面。base模块的设计权衡按优先顺序依次为：

1.可靠性（健壮性），正确性：要么执行任务，要么显式通知用户发生了错误。

2.效率：保证正确可靠的前提下，尽可能提高效率。

3.易用性：接口尽可能易于理解和使用，在可能产生非预期结果的位置给出醒目提示。

4.可移植性：尽可能降低在不同平台间移植的工作量。

5.可维护性，可扩展性：定义清晰的内部层次结构，在均衡以上各项目标后，尽可能保持

易于扩展和维护的体系架构。

按照与实现细节的相关程度，基础模块还可以分为以下两个部分：

3.1.1.基础模块底层

基础模块的底层部分直接处理与硬件特性和编译环境相关的问题。为了保持最高的执行效率，这一层完全由复杂的宏魔术和成打的typedef构成。

底层作为整个库的基础存在，所有逻辑判断都依靠大量的宏魔术完成，在完全消除了运行时开销的同时，也使得它们难于使用和维护。libutilitis的用户很少需要，也总是应当尽可能地避免直接使用它们（除了表意宏以外）。

同时，类似大多数可配置的库，可以通过在编译前指定或改变某些特定的开关宏来调整libutilitis中各种功能及行为方面的选项。

3.1.2.基础模块界面层

界面层封装底层实现细节，为用户提供更一致易用的接口。例如：

在不支持64位整型的编译环境中提供用户透明的INT64整型模拟。

白杨应用支撑平台技术白皮书为32位、64位和指针类型提供Acquire、Release以及无屏蔽语义的原子量操作。原子量

操作在Windows 平台上通过调用系统API实现，在其它平台上使用汇编实现。目前支持的非Windows平台包括：x86、x86_64、IA64、ARM、PowerPC、MIPS、SPARC等。

对于不支持硬件级原子量的平台，libutilitis提供了使用互斥量散列集合优化的模拟实现。

提供了针对读写、只读和只写的内存全屏障操作。与原子量支持类似，在Windows平台

上，内存屏障操作通过调用相应的Windows API实现。在其它平台上则通过汇编实现。

目前支持硬件级内存屏障操作的非Windows平台与原子量相同。对于不支持硬件级内存屏障操作的平台，libutilitis同样提供了使用互斥量模拟的实现。

有关原子量和内存屏障的进一步讨论，请参考拙作《C++编码规范与指导》中的“原子操作和 volatile 关键字”一节。

提供了很多与平台/编译器相关的标识宏。例如：强制内联指令、DLL符号表导出指令、

内联汇编指令；以及当前硬件平台、编译器类型、编译器支持的特性（如：是否支持模板嵌套、是否支持散列容器）等等。

提供了一系列与底层平台相关的优化指令。如：分支预判优化、预取优化、与硬件平台

类型相关的寄存器用法优化等等。

提供了全局对象初始化顺序保证机制。C++仅确保在同一编译单元内的全局对象按其定

义顺序初始化。对于在不同编译单元内定义的全局对象的初始化顺序没有任何保证。在GCC等不支持自定义全局对象初始化顺序的编译器中，libutilitis提供了一套编译器无关的全局对象初始化顺序保证机制。关于此话题的进一步讨论，详见拙作：《C++编码规范与指导》中的“全局对象初始化时的线程安全性和相互依赖性问题”一节。

在封装了底层实现细节同时，很多基础工具也在这里实现。例如：

通用句柄（带引用计数的智能指针）模板。通用句柄用于在绝大多数场合中替代传统 C

指针，其主要特性如下：

自动管理：用户无需操心资源应当在何时，以及由谁来进行销毁。

异常时安全：满足“资源申请即初始化（RAII）”语意，保证异常时不会产生内存泄

漏和程序错误。

高效：除创建、销毁和复制外，通用句柄的任何操作都与指针完全一致。创建、销

毁和复制时仅增加极高效的引用计数维护操作。

避免错误：有效防止内存泄漏和其它程序错误，大幅简化指针相关的程序设计。

自定义销毁策略和NIL值：虽然默认NULL为NIL值并使用delete操作销毁对象。

但您可以销毁策略和NIL值。例如：对于操作文件句柄的模板，可以指定销毁策略

为调用close 函数，并指定NIL值为 INV ALID_HANDLE。自定义的NIL值和销毁

白杨应用支撑平台技术白皮书策略均作为模板参数传入并在编译时绑定，不会增加任何运行时开销。

支持静态句柄（无权绑定）。

支持 DontInit 方式的构造，可帮助创建高效的、多线程安全的局部静态对象。关于

此话题的进一步讨论，详见拙作：《C++编码规范与指导》中的“局部静态对象初始化时的线程安全性问题”一节。

可以通过模板参数指定引用计数变量的类型。在使用的原子量类型（默认值）完成

引用计数时保证句柄的多线程安全性。

临时句柄模板：临时句柄模板与前文介绍的通用句柄模板类似，也支持RAII语义、自

定的销毁策略和自定义NIL值等等。与通用句柄相比，唯一的区别就在于临时句柄不支持引用计数，用户需要通过显式地放弃所有权来进行指针传递。与通用句柄常用来完成函数间的参数传递不同，临时句柄通常仅在一个函数或代码块内保证RAII语义和异常时的安全性。由于无需引用计数，故其所有操作的效率都完全等同于标准指针。

basic_buffer：与标准库basic_string模版兼容的高效缓冲区管理工具。basic_buffer模板

与STL basic_string完全兼容，但提供更高的时空效率以及更精细的存储管理机制。通过支持引用计数（reference counting）和写时拷贝（copy-on-write）、内存原地重分配、缓冲区预分配以及静态（无权）缓冲区等各项技术，basic_buffer 可以提供比 basic_string 高的多的时空效率。同时，basic_buffer 也针对 BLOB（basic_buffer）进行了特别优化。

字符串扩展工具：为 basic_buffer或basic_string提供附加的扩展功能。例如：支持流式

操作；支持类型转换；支持各类常见的字符串解析任务；支持各类反向操作；支持UNICODE字符集和BRE/ERE/ARE（TCL 8.2）的正则表达式操作；基于回调或符号表的换码操作等等。

高效链表节点模板：CListNode 模板封装了双向链表的节点相关操作。相对于 std::list 来

说，CListNode提供了O(1)时间且无需内存重分配的节点分离、交换、移动等更为底层也更为灵活的链表用法。在需要使用链表的场合，用户应当首先尝试使用 std::list容器，仅在该容器无法满足需求是考虑使用 CListNode 实现专用链表。

LRU Cache模板：基于最近最少使用（Least Recently Used，LRU）淘汰算法的缓存管理

器，提供设置、删除、匹配、遍历和管理等完整的操作集合。可由用户选择使用散列（hash_map / unordered_map）或B树（std::map）容器来进行 key-value模式的索引和匹配。缓存管理器内部使用CListNode维护高效的LRU列表。

其它标准库扩展，如：使用静态缓冲区并兼容std::vector的 fixed_vector 模板；兼容

std::deque的环形缓冲区容器；标准C库文件操作的封装类；以及通用的指针/下标访问到iterator封装和各类成员函数适配器等等。

异常处理封装：对new时异常、未捕获异常和delete时异常等情况提供满足RAII语义的异

白杨应用支撑平台技术白皮书常处理封装。关于此话题的进一步讨论，详见拙作：《C++编码规范与指导》中的“异常”

和“C++异常机制的实现方式和开销分析”等章节。

封底的错误处理机制：libutilitis会捕获所有应用程序未处理的严重错误，并将他们输出

到全局日志对象中。这些错误包括：C++运行时的错误，例如：未捕获的异常或者异常

中的异常；以及操作系统报告的错误，例如：非法内存访问等。

综上所述，基础模块封装了所有与底层平台和编译环境相关的基本功能。libutilitis以及应用支撑平台中的其它模块高度依赖这里定义的基本工具。

3.2 系统工具模块－sysutil

系统工具模块基于基础模块构建，封装所有操作系统相关的功能，为用户提供一个平台无关、易用、可靠的系统功能交互界面。系统工具模块在各个设计要素间的权衡优先顺序与基础模块一致。

系统工具模块的设计目标是封装绝大多数常用的操作系统级和硬件平台级服务。我们在经典操作系统教科书中能够找到的特征和功能，在这里几乎都有对应的功能接口。例如：

进程控制：实现了进程创建（包括以指定用户的身份创建子进程、输入输出重定向、创

建隐形进程等）；终止进程；等待进程终止；优先级和调度算法设置；可抢占性设置；处

理器粘滞性设置；内存、文件句柄等资源限制设置；CPU时间、内存尺寸等资源用量查

询；进程已加载的模块查询；系统已加载的进程查询；内存映射查询；根据给定地址反

查所属模块（例如：根据一个函数指针反查提供该调用的 dll/so 模块）等等。

线程、TLS：支持创建、运行、挂起、继续、停止、杀死等状态控制；支持优先级、调

度算法和可抢占性设置；支持处理器粘滞性和最优处理器指定设置；可获取线程当前运

行状态和统计信息；可主动释放时间片或强制将当前时间片赋予其它线程。支持TLS存

储区。

协程：协程（co-routine），又称为纤程（fiber）、co-process、用户线程（user thread）等，

是一种比线程更轻量级的并发机制。libutilitis支持完整的协程操作，同时提供了一个基

于线程池的协程运行环境和基本的FIFO调度算法。通过派生一个新的类型，用户也可

根据自己的需求方便地定义不同的运行时环境和调度算法。

信号量、互斥量、事件（条件变量）、等同步机制。同时，对于支持硬件原子量的平台，

libutilitis还实现了快速互斥量（FUTEX）和快速信号量、自旋锁等高速同步机制。快速

互斥量实现了支持递归调用的全用户态互斥量，由于不需要每次加锁和解锁的过程都进

入内核模式，所以大大提高了其工作效率。快速互斥量支持比Windows Critical Section

更丰富的功能（比如：超时等待），同时效率也要稍高于Critical Section。快速信号量与

此类似。libutilitis中的快速互斥量和快速信号量均支持自旋锁操作，并且可以自动检测

当前环境的处理器数量，并在单处理器环境中fallback到标准上锁模式。在不提供硬件

级原子量支持的平台，快速信号量等同于普通信号量，快速互斥量等同于普通互斥量。

白杨应用支撑平台技术白皮书因此用户无需修改代码就能够以平台无关的方式使用对当前环境来说最高效的同步手

段。

动态库（dll/so）加载工具：平台无关的动态库加载和api入口定位工具。

文件、网络、通信设备的同步及异步IO操作：libutilitis封装了文件、网络（socket，支持

IPv4和IPv6）、串口、并口和管道等通信设备的IO操作。并提供了一套平台无关的异步IO

框架（详见下文）。

文件映射和共享内存：支持读、写、执行和写时拷贝（COW）等权限设置。可以将映射

或共享内存建立在指定基址。

目录管理：包含完整的磁盘卷和目录管理工具。支持目录、文件和子目录的遍历、复制、

移动、删除、属性和权限设置等各种操作。可获得磁盘卷的拓扑结构和文件系统信息；

可取得当前平台中所有已挂载（mount）卷设备的详细信息。

系统时钟、时区、DST规则和时段操作：libutilitis提供完整并且功能丰富的时间和历法

相关操作。同时支持高精度性能计数器操作。

高精度时钟触发器：封装由操作系统提供的高精度周期性时钟触发回调机制。

系统日志：将日志消息记录到syslogd（unix）或System Event Service（Windows）中。

服务管理器：添加、删除和管理当前平台或指定计算机中的服务和驱动（Windows）。

服务（守护进程）框架：使用这个平台无关的框架开发Windows Service或Unix Daemon。

字符集编码转换：支持Windows API、POSIX libiconv、IBM libicu 和ISO C locale api。

根据当前平台的设置和字符集编码智能选择最优的编码转换器。

平台信息获取：与基础模块（base）中的那些预定义宏不同，libutilitis提供了在运行时

动态获取当前平台相关信息的工具。可获取的信息包括：操作系统类型、产品系列、版

本号、Service Pack / Patch 号、本次开机时间、内存页分配、CPU类型、CPU宽度、CPU

字节序、处理器数量等等。

注册表访问、用户终端（字符界面）控制等其它各类常用功能。

内存有效性（读、写执行权限）检查、系统管理（注销、关机、重启）、环境变量扩展

等杂项功能。

sysutil模块同时也为不支持某些特定功能的平台提供对用户透明的虚拟层。例如：在不支持注册表操作的平台中提供功能完全兼容的虚拟注册表实现等等，此类功能在不同平台间进行编译时，能够自动切换到最适用于当前平台的实现。例如：在Windows中优先使用系统提供的注册表服务，在其它平台则使用libutilitis提供的虚拟注册表服务。

此外，系统工具模块也提供了一些与底层平台密切相关的应用框架。例如：系统服务框架封装了服务程序的标准流程和工作模式。使用这个框架构建的应用程序在 POSIX 环境下表现为一个 Daemon，而在 Windows 环境下则会以 Service 的身为与系统上的 Service Manager 协同工作。以及要在下一个小节中专门讨论的高效IO框架等等。系统级的框架和工具对很多关键应用

白杨应用支撑平台技术白皮书的构建提供了极大帮助。它们在大大降低了跨平台移植成本的同时，通过高密度的重用提高了开发效率和代码品质。

虽然libutilitis应当做到尽可能地在各个平台上提供一致的功能，但显而易见地，仍然存在一些无法完全消除的差异。最有代表性的例子恐怕要属服务管理器了。WinNT系列平台提供了服务管理器，统一控制和管理当前系统内的所有后台服务和驱动程序。类似的机制在绝大多数"POSIX 类"（un*x/linux等）环境及DOS等环境中并不存在。很显然，因为涉及与系统中其它组件的广泛交互，类似功能难以在缺乏操作系统支持的前提下很好地仿真。

libutilitis设计的一条重要准则是可靠、正确和完善。libutilitis可以选择不包含某些功能，但是，一旦将某个功能供给用户，就必须保证该功能能够正确可靠地工作。对于某类特定功能来说，libutilitis要么不予提供，要么必须给出完整明确的操作界面（例如：不会提供一个不支持文件和子目录遍历的目录访问类。这保证了用户不会因为libutilitis提供的组件缺少了某些基本操作而被迫绕开它，而自行将相同的功能再重新实现一遍）。

基于以上设计准则，libutilitis库中可能有极少量功能无法达到完全透明的跨平台能力。关于这方面详细信息，请参考libutilitis的配套用户手册。

基础模块与系统工具模块一起封装了绝大多数平台相关的服务，但是在一个真实项目中，还是有可能碰到需要直接访问操作系统相关特性和硬件资源的情况。例如：项目依赖某个第三方COM组件；代码的热点地区需要使用内联汇编进行优化等等。

实际上，C/C++ 语言最诱人的特点之一就是同时提供了高级语言的易用、功能丰富的标准库、非常高的执行效率和直接访问底层硬件的能力。libutilitis的设计目的从来就不是为用户在这些任务上设置屏障，相反地，libutilitis致力于提供了一组专门的工具，帮助用户以更优雅、更便于移植的方式达到自己的设计目标。

libutilitis旨在针对大多数通用功能，为用户提供一套完整、高效、可靠的平无关实现。我们深切地体会到，缺少这三个条件中的任意一个，都将促使用户绕开libutilitis，转而自己实现某些对他（或对他的项目）而言十分关键的功能。libutilitis在大量减少与产品代码与底层平台直接交互的同时，也帮助用户以更结构化和更可控的方式完成那些必须直接与底层平台交互的任务。

例如：工具库中提供了用于判别当前编译环境和目标平台的宏，可以用于辨别编译器厂商、版本、编译器和标准库是否具备某方面能力；目标平台操作系统；目标平台 CPU 类型、位宽、字节序等细节信息。还包括了用来封装各编译器间不同内联汇编语法的宏，以及用于运行时动态获取平台类型和版本细节信息的工具类。

libutilitis替用户完成大部分通用任务，并帮助用户以更方便、优雅和便于移植的方式实现那些必须的底层交互部分，最终产生代码更简洁、更健壮和更利于维护的产品。

白杨应用支撑平台技术白皮书3.2.1高效IO框架

高效 IO 框架则封装了基于多线程的高并发、高负载IO伺服模型。总体来说，当前的IO伺服模型主要有以下几类：

模式1：同步—阻塞式IO + 多线程/多进程，每连接一线程/进程的模型。这是最基本最

容易实现的IO伺服模型，如著名的apache web服务器就使用这个模式工作。与此同时，

这也是效率最低的伺服模式。主要问题体现在：为每个连接创建一个线程/进程开销很大；

在高并发时服务器资源主要浪费在频繁的线程/进程创建和切换上；对于高并发+慢速连

接DDoS攻击缺乏有效的防御力；对需要长连接的高并发应用支持不好（因为每个连接

都要长期占用一个服务器线程或进程）等等。

模式2：同步—非阻塞IO + 高效poll（epoll/kqueue/event ports） + 多线程，每就绪连接

一线程的模型。此模式通过操作系统提供的高效轮询接口周期性地等待一个连接集合中

的某些连接可用。然后对可用连接进行非阻塞的读写（即：从底层协议栈的接收缓冲区

内读出数据或将数据拷贝到底层协议栈的发送缓冲区中），最后再次使用轮询接口进行

等待。这种伺服模型的优点是可以使用很少的线程处理大量并发连接，可达到较高的时

空效率。缺点是编程模型复杂，并且依赖于操作系统特定的API。

模式3：异步IO模式 + 多线程，每活动连接一线程的伺服模型。在这一模型中，应用程

序将需要的IO操作直接提交给操作系统，系统在该操作完成后通过回调机制通知应用程

序。理论上，这是效率最高的IO伺服模式：因为在这一模型中，应用程序可将需要传输

的内存地址直接提交给底层硬件，硬件通过DMA直接在这个内存位置完成IO操作，这就

实现了内存零拷贝。在完成IO操作后，硬件通过触发中断通知操作系统，并由操作系统

回调应用程序。这里避免了模式2中的轮询等待操作和连接集合维护操作。不但如此，

由于可以向底层驱动并发地提交多个IO请求，这就使操作系统和底层硬件有机会实现操

作合并（例如：将多个消息合并到一个网络帧或磁盘IO请求中完成读写）以及最优化请

求顺序（例如：调度磁头从最近的磁道开始读写请求）等等。此模式的主要缺点是编程

模型复杂，并且其实际效率取决于底层操作系统的实现方式。

由此可见，理论上讲，模式3所使用的异步IO架构拥有最高的IO效率。但是实际情况却极大地取决于操作系统的实现方式。例如：Linux和Solaris目前均不支持真正的，kernel级的socket AIO操作，这些系统上的异步IO操作都是在用户模式下使用多线程+同步—阻塞式IO（即：模式1）模拟而成的。可以预见，使用这些系统提供的AIO服务只会带来严重的效率劣化。

而另一方面，由于epoll / kqueue / port_get等高效poll接口均已在相应的系统中实现了O(1)复杂度，再加上大部分现代操作系统均已通过引用计数和写时拷贝完成了非阻塞IO的内存零拷贝实现。因此在实际环境中，具体何种IO模式能够为当前平台提供最高效率需要经由大量性能测试和内核源代码分析等工作才能最终确定。

libutilitis 实现的高效IO框架为用户提供了一套平台无关的IO机制，并且总是尝试使用对当前平台来说效率最高的IO伺服模式。具体说来：

白杨应用支撑平台技术白皮书在 WinNT 系列（NT/2k/xp/2k3/Vista/2k8/Win7....）平台上使用Overlapped IO + IOCP。

在 WinCE 系列（WinCE / WinMobile）平台上使用Overlapped IO + Event。

在FreeBSD / Apple Mac OS X / HP-UX / IBM AIX 等支持内核级 socket AIO 的平台上

使用POSIX AIO + Realtime Signal（但FreeBSD的socket IO仍使用kqueue，因为FreeBSD

在对高并发socket的支持上，kqueue要好于POSIX AIO）。

在 Linux 上，使用Nonblocking IO + epoll。

在NetBSD / OpenBSD / DrangonFly 上使用Nonblocking IO + kqueue。

在 (Open)Solaris 上使用Nonblocking IO + event completion port。

在RTEMS / eCos / DOS 等不支持任何高效 IO 模型的环境下，使用线程池+阻塞IO模

拟。

3.3 通用工具模块－facility

通用工具模块基于以上两个模块构建，提供一些基础的常用算法、功能、设计模式和处理框架，主要用于简化项目实施和提高代码重用率。由于此模块基于base和sysutil实现，所以自然也实现了平台无关性。此模块中提供的工具包括：

各类常用的同步算法：提供了满足RAII原则的临界区、全同步、读者/写者模型、生产者/

消费者模型等各类同步算法封装。

带有时区和夏令时规则的时间、时段工具和历法工具。

支持复杂规则的命令行解析器。

多线程安全的消息队列和消息处理机制：封装了用于线程间通信的高效消息队列机制，可

以使用std::deque、std::list、base模块中定义的环形队列以及std::priority_queue（优先级队

列）等多种容器实现（作为模板参数传入）。队列使用生产者/消费者算法，并有多种针对

不同用例调优的变体可供选择（作为模板参数传入，例如：使用快速互斥量和自旋锁的变

体）。

除了教科书式的经典消息队列外，libutilitis还实现了一种允许重复写入的消息队列。这种

消息队列允许生产者无限制的写入，但如果生产的速度超出了消费的速度而导致队列满，

则新生产的元素将剔除队列中尚未被消费掉的最老的元素。这种允许溢出的消息队列主要

在传递一些不需要可靠性保证，并且消息时效性很强的场合使用。

日志记录机制：libutilitis类为用户提供了一种分级记录日志信息的方式，用户可以为日志

对象设置允许记录事件的最低级别（最低紧急程度）。每一个日志对象都可以同时绑定多

白杨应用支撑平台技术白皮书个记录器（Logger）。Logger 代表一类用于存储日志信息的数据目标，例如：窗口、文件、系统日志服务等等。当用户向一个日志对象中写入日志时，它将被分发给所有绑定到这个对象上的 Logger。libutilitis 已实现了包括文件、终端窗口、标准输出设备、周期性文件、内存缓冲区、网络连接、系统日志记录服务（Windows Event Service / UNIX syslogd）以及syslog协议（RFC 3164）服务器在内的多中日志记录器。通过简单的派生，用户也可以非常方便地实现自己的日志记录器。

日志对象还支持一种被成为过滤器的工具，日志过滤器为用户提供一种回调机制，监视和过滤当前对象的日志记录情况，并决定是否允许一条日志被记录。libutilitis已为用户提供了基于通配符和正则表达式的日志消息过滤器。用户也可以非常方便地实现自己的过滤机制。

为了提高并发性，并吸收日志浪涌时产生的延迟和性能下降。日志对象支持以非阻塞方式记录日志消息。在使用非阻塞模式时，应用程序将日志消息提交到一个消息队列，日志对象会在单独的工作线程内完成所有日志过滤和记录事务。用户无需等待日志记录被写入记录装置（如：磁盘、网络、屏幕等）即可返回继续工作。

modem控制功能（基于串口通信的AT指令控制）：支持完整的AT指令集、支持带超时的

操作、支持拨号和背靠背连接，可用于低成本的远距离窄带传输。

由Bell实验室定义，广泛用于Avaya交换机及其它高可靠性领域中的RSP（可靠会话协议，

Reliable Session Protocol，基于TCP和串口通信类）协议。RSP协议维护自己的收发窗口，并实现了超时重传、心跳检测，以及基于RTT的流控算法。

基于消息的高效会话层协议：使用两种方式实现，AIO版基于libutilitis高效IO框架实现，适

合大型服务器等高并发、高负载场合。同步IO版简单易用，适合用于实现客户端和低负载服务器。

HTTP和FTP客户端：支持FTP被动模式、支持HTTP Keep-Alive Connection、支持SSL/TLS、

支持HTTP/FTP/SOCKS代理。

基于高效 IO 框架和 HTTP/FastCGI/SCGI 协议的Web扩展框架（详见下文）。

键树和规则键树容器：键树是一种常用的容器，通常用于对某种键值信息的分层式前缀匹

配，例如自动完成和电话区号匹配等等。规则键树的行为与普通键树相似，但是加入树中的token可以被指定的分隔符分成前后两部分。其中前半部分使用标准的键树命中；在前半部分命中之后，可以对匹配内容中的后续部分进行若干次可选的，用户指定的规则匹配（例如：可以追加正则表达式限定规则）。仅当规则匹配成功时，这个项目才被真正被认为是命中了的。

时钟触发器：与在sysutil模块内基于操作系统相关服务实现的高精度时钟触发器不同，这

里实现的时钟触发器是基于libutilitis自己维护的计时线程而实现的。之所以要自行实现时

白杨应用支撑平台技术白皮书钟触发器，是因为操作系统提供的高精度触发器通常有很多资源开销以及创建数量上的限制。例如：Windows 上的每个进程最多仅能同时创建16高精度触发器。不但如此创建，高精度触发器会修改整个系统的时钟中断频率，从而对系统造成负面影响。

libutilitis触发器能够支持大量时钟触发的周期性任务，并且支持时钟分组模式。即：将所有时钟触发任务按照类型分为若干组，每组时钟任务都可以与其它组互不干扰地运行在专用的计时线程上。这样做有几个好处：首先，在不同线程中运行可以消除时钟间的相互干扰；其次，可以为不同的线程指定不同的时钟分辨率和优先级；再次，可以为需要较高精度（毫秒级）的时钟组打开系统时计校准功能。开启了系统时计校准功能后，该类型时钟触发器的触发间隔将根据计时线程的实际阻塞间隙和到期触发器执行消耗等多方面实际因素计算。

任务管理器（基于时钟触发器）：作业计划工具由两个部分组成：任务管理器和计划执行

的任务。它们提供与时钟触发器非常相似的功能。实际上，任务管理器本身就是基于时钟触发器实现的。如果从头说起，每个应用程序中可以存在任意数量的计时线程（但是大部分应用程序只需要一个就足够了）；在每个计时线程中，又可以包含任意数量的时钟触发器；而作为一种特别的时钟触发器，在每个任务管理器对象内又可以包含任意多个计划执行的任务。

在 libutilitis 中提供以上三级定时触发体系决不是因为一时心血来潮，它们是从对实际应用的仔细观察中得来的。其中提供多个计时线程的原因已经在与时钟触发器相关的说明中详细地阐述了，下面来说说使用任务计划与直接使用时钟触发器的区别：

触发器对象只能按照固定的时间间隔触发，但是可以为计划任务设置非常复杂的触发

条件。

多个相关触发器对象间的相互协作比较困难，但是计划任务可以按不同类别进行分组，

并方便地相互协作（通常每组任务分别放入不同的任务管理器中进行管理）。

计划任务支持按照不同的优先级顺序被执行。而触发器对象不支持。

计划任务通常在堆中创建，使用智能句柄维护，支持"fire and forget" 语意。用户只需

简单地创建任务，无需关心何时由谁销毁它。

消息处理框架：定义了支持职责链和命令模式的通用消息处理框架。并实现了消息预处理

和消息分发机制。

原型工厂：定义了基于散列表或平衡树实现的高效原型工厂框架。

持久化框架：定义了对象持久化（序列化）框架，并且实现了两种对象集合序列化存储格

式，其中一种可以支持随机访问，而另一种则主要针对长期归档优化。持久化的数据可以写入到任何数据目标，也可以从任意数据源读入。

白杨应用支撑平台技术白皮书虚拟注册表：提供了Windows注册表仿真服务。虚拟注册表的主要特性包括：基于ISXF

格式实现，ISXF是一种平台无关的二进制格式。这确保了虚拟注册表数据的跨平台能力和极高的读写性能；国际化，虚拟注册表中的字符串类型完全以 Unicode 字符集（UTF-8 格式）保存。辗转在各种不同语言环境的操作系统上也不会出现显示/保存乱码、数据不正确之类的问题；高效率，虚拟注册表被载入后，所有目录和值都存放在平衡树中。即使是在非常庞大的项目中检索和访问也可以保持很高的效率；支持与CSV、INI、JSON以及Windows系统注册表间的导入导出操作。

字符串规则匹配：每一个字符串规则匹配表对象都可以由维护任意多个不同字符串匹配规

则组成的规则集合。用户可以在这些规则集合上对指定字符串进行匹配操作。libutilitis目前支持的字符串匹配规则包括：范围规则、通配符规则、正则表达式规则和枚举规则等。

线程池：创建和维护可动态调整的线程池对象。

通用数据处理框架：libutilitis定义了一套高效的，支持零内存拷贝的数据处理框架，并提

供了丰富的数据源和数据目的，如：基于文件、网络、串口、对象队列、内存缓冲区的源和目的等。也实现了很多通用滤镜，如：容器滤镜、T型滤镜等等。下文中将要介绍的libaudioio 就是基于这套框架实现的。

虚拟文件系统（VFS）：VFS是一个抽象的框架，任何一个能够被看做是包含文件的目录系

统都可以被封装为一个虚卷。VFS分为封装虚卷和基于文件的虚卷。

libutilitis实现的封装虚卷包括标准磁盘目录、基于FTP的VFS和基于HTTP的虚文件。与此同时，libutilitis也定义了一个基本的，基于文件的虚卷：这个虚卷系统可以将包含任意多文件和子目录的文件夹打包成一个单一文件进行访问。并且支持为每个文件和目录追加任意复杂的元数据（通过为其追加一个虚拟注册表）。除此之外，libutilitis中还有一个完全基于内存的虚卷实现。内存虚卷在创建临时数据和实现memory cache等场合十分有用。

虚卷中可以包含虚卷，虚卷可以进行对性能无损的嵌套访问。此外，在libcrypto中还定义了一个支持实时压缩和加密的文件型虚卷（详见下文）。

运行时环境管理器：运行时环境管理器提供以下通用的应用程序运行时功能：

环境变量管理：维护一套应用程序自有的内部环境变量系统，并提供遍历和字符串

扩展服务。变量管理器支持环境变量的递归解析以及引用操作系统环境变量的功能。

文件预约删除服务：在创建一个临时文件之前，可事先进行预约删除。这样即使发

生系统掉电等严重事故，也会保证最迟在下次启动此应用程序时删除这些文件。预约删除服务提供基于事务的完整性保证。

临时文件生成服务：原子性地生成并打开一个临时文件。

基于IP地址和掩码的IP网络列表，支持IPv4和IPv6。可执行的操作包括匹配、遍历、添

加、删除、序列化等。可以用来实现网络黑名单或白名单服务。

支撑平台工具使用说明

目录 1综述 (2) 2winnttcp (3) 2.1 简介： (3) 2.2 操作方法 (4) 2.2.1 链路状态图 (4) 2.2.2 链路详细信息页 (5) 2.2.3 配置选项页 (6) 3tcpout (7) 3.1 简介： (7) 3.2 操作方法 (7) 4 S10see (8) 4.1 简介： (8) 4.2 操作方法 (9) 4.2.1 支撑系统信息页 (9) 4.2.2 支撑打印信息页和业务打印信息页 (10) 4.2.3 参数设置页 (10) 5 Printctl (12) 5.1 简介： (12) 5.2 操作方法 (12) 5.2.1流向选择页 (12) 5.2.2业务模块选择页 (13) 5.2.3测试选项页 (13) 6 Ommsee (14) 6.1 简介： (14) 6.2 操作方法 (14)

1综述 支撑系统的主要功能是为上层应用进程提供和操作系统平台无关的调用接口，对应用进程进行基于消息的调度，建立和维护通信链路，统一管理定时器和内存资源，实时监控系统的运行情况，收集运行参数，捕获各种异常情况并进行记录和相应处理。 支撑系统各个主要模块的分布结构如图所示，图中实线箭头为链路建立的方向：

2winnttcp 1.1 简介： winnttcp又称小轮子、小齿轮，是运行在后台服务器129-139节点以及客户端30-64，165-199，210-239上的通信程序，专门负责建立、维护通信链路以及应用进程之间的通信。 应用进程通过调用动态连接库comm.dll中的接口函数RegisterOnZXTcp注册到winnttcp，然后就可以调用接口函数ZXClientSendMsg来发送消息到其他本地或远端的应用进程了。 Winnttcp启动以后，通过读取配置文件$WINNT\tcpseek.ini中的信息绑定本地的IP地址和端口号，侦听远端节点发来的连接（当本机设为服务器时），同时也通过读取配置文件中的远端节点的节点号和IP地址，向远端节点发起连接，默认情况本地绑定的端口和要连接的远端端口号都是5000。 关于comm.dll中的接口函数使用方法，详见如下文档： winnttcp启动以后会根据配置文件中的配置自动建立好所有链路； 应用进程通过comm.dll与winnttcp交互，调用comm.dll中的接口注册到winnttcp，将消息发到winnttcp，然后由winnttcp将消息发送到目的地，若为本节点的进程，则winnttcp 直接将消息发往目的进程，若为其他节点上的进程，winnttcp会检查与远端节点链路是否已建立，若建立，则将消息发送目的节点，目的节点上若运行的是winnttcp则目的节点上的winnttcp会将接收到的消息分发到目的进程，若目的节点上运行的是NT/UNIX或MP支撑，则这些支撑的通信模块会将消息分发到目的进程。 在发送消息接口函数ZXClientSendMsg中会在所有业务消息之前加上一个29字节的消息头，然后再发到winnttcp，消息头中主要包括消息发送者的PID、消息接收者的PID、事件号、消息长度、加密域等内容：

电子政务基础支撑平台解决方案word

电子政务基础支撑平台解决方案WORD版本下载后可编辑

目录 版权声明 ....................................................................................................................................... - 3 - 第1章概述 ............................................................................................................................... - 4 - 1.1项目背景 (4) 1.2电子政务建设目标 (4) 1.3电子政务基础支撑平台建设目标 (5) 第2章基础支撑平台的理解与分析......................................................................................... - 7 - 2.1基础支撑平台提供的功能 (7) 2.1.1业务系统运行支撑 ..................................................................................................... - 9 - 2.1.2可靠的消息传输支撑 ............................................................................................... - 12 - 2.1.3灵活可扩展的数据/应用集成支撑.......................................................................... - 14 - 2.1.4持续优化的业务流程编排支撑 ............................................................................... - 17 - 2.1.5个性化的统一门户平台支撑 ................................................................................... - 18 - 2.1.6智能可扩展的云计算平台支撑 ............................................................................... - 19 -2.2面临的问题及挑战 .. (20) 第3章应用支撑平台解决方案 .............................................................................................. - 22 - 3.1某某省电子政务外网规划及架构........................................................ 错误！未定义书签。 3.2应用支撑平台应具备的特点 (32) 3.2.1基于SOA的架构 ...................................................................................................... - 32 - 3.2.2统一的微内核体系 ................................................................................................... - 33 - 3.2.3标准与开放性 ........................................................................................................... - 33 - 3.2.4灵活、可扩展 ........................................................................................................... - 33 - 3.2.5易用性....................................................................................................................... - 34 - 3.2.6高可用性 ................................................................................................................... - 34 -3.3应用支撑平台技术实现方案.. (35) 3.3.1应用支撑平台解决方案的基础技术支撑 ................................... 错误！未定义书签。 3.3.2应用运行支撑——企业级应用服务器（AAS） ......................... 错误！未定义书签。 3.3.3可靠消息传输支撑——企业级消息中间件（AMQ） ............... 错误！未定义书签。 3.3.4灵活可扩展的SOA架构及集成支撑——企业级集成中间件（AESB）错误！未定义 书签。 第4章我们的优势.................................................................................................................. - 52 - 4.1厂商优势 (52) 4.2技术优势 (53) 4.3产品优势 (55) 4.4服务优势 (56) 4.5伙伴至上共生共赢 (58) 第5章典型客户 ..................................................................................................................... - 60 - 5.1政府 (60) 5.2金融 (60)

云服务支撑平台及重大应用-简(参考文献)

重大项目建议 云服务支撑平台及 重大应用 清华大学 2010年5月28日

目录 1背景、需求和战略意义 (3) 1.1背景 (3) 1.2需求 (3) 1.3战略意义 (4) 2技术发展现状、存在问题及国内优势 (5) 2.1技术发展现状 (5) 2.2存在问题 (6) 2.3国内优势 (7) 3技术发展趋势、发展思路及主要内容 (8) 3.1技术发展趋势 (8) 3.2发展思路 (9) 3.3主要研究内容 (10) 4技术与产业关联分析 (11) 5研究基础、科研队伍和科研条件 (12) 6发展目标、经济效益和社会效益 (13) 6.1发展目标 (13) 6.2经济效益 (14) 6.3社会效益 (14) 7发展路线图 (14)

1背景、需求和战略意义 1.1背景 随着网络基础设施的逐步完善，互联网、3G、无线宽带网络、无线传感等多个网络正在融合为泛在信息网络，“无时无刻不联网”的时代已经到来。在这种环境下，一种新的服务化计算模式——云计算(cloud computing)正在兴起。作为一种新的计算架构，云计算不仅对信息领域产生了重大影响，也对工业的发展产生着重要的影响[1,2]。 基于云计算的云制造模式正在形成和快速发展。云制造，是在“制造即服务”理念的基础上，借鉴了云计算思想发展起来的一个新概念。云制造是先进的信息技术、制造技术以及新兴物联网技术等交叉融合的产品，是制造即服务理念的体现。在理想情况下，云制造将实现对产品开发、生产、销售、使用等全生命周期的相关资源的整合，提供标准、规范、可共享的制造服务模式。这种制造模式可以使制造业用户像用水、电、煤气一样便捷地使用各种制造服务[3]。 云制造需要采取包括云计算在内的当代信息技术前沿理念，建立共享制造资源的公共服务平台，将巨大的社会制造资源池连接在一起，提供各种制造服务，实现制造资源与服务的开放协作、社会资源高度共享。 1.2需求 1、云服务平台是实现云计算技术落地的必然需求 云计算平台只是提供云服务的第一步。对于提供公共的云服务这个目标而言，建设云计算平台还仅仅是计算基础设施的建设。在应用软件方面，目前国内的云计算中心所提供的内容有限。而应用软件部署、系统和软件管理、收费模式等方面更是接近于空白[4]。因此，建设面向具体应用和业务的云服务平台，提供公共的商业云服务，是实现企业业务和IT融合的必然需求，也是保证云计算落地的根本途径。 2、云服务平台是实现传统制造业向先进制造服务业转型，实现云制造的必然需求

统一集成平台

统一集成平台 实现对各个城市业务部门和业务系统的界面集成、数据集成、服务集成、流程集成，以及在此基础上实现城市数据标准统一，全面的综合分析、呈现、多部门智能业务协同和城市管理综合智能分析。真正的实现城市治理现代化建设的系统融合、数据融合、业务融合，打破信息孤岛、部门壁垒，实现跨层级、跨地域、跨系统、跨部门、跨业务的协同管理和服务，提高城市治理能力和服务能力。 1.集成平台 1、子系统集成 从城市综合管理角度出发，将原有和新建的各类业务系统依据统一的标准进行接入，包括：运管平台内部各子模块有机集成（如：联动指挥、协同治理等）以及外部各委办局现有业务系统等。提供统一、规范的接口，保证数据一致性、接口可扩展性，实现城市运营管理信息资源的整合与共享。 2、平台统一接口规范 集成平台接口主要分为两类：包括主动发起请求方式、被动接收请求方式接口；面对分散的信息数据及数据开放请求，系统需要统一的数据接口标准，包括接口规范、数据参数、调用方式，传输协议等。 3、服务管理与集成 主要通过对下层提供的各类基础服务、如视频平台、地理空间平台、数据平台等进行统一的服务化封装、处理及管理，以便为构建上

层各类智慧应用提供统一支撑平台，作为集成系统的服务总线。 4、流程管理与集成 通过整理现代化数字城市各个领域业务规则和执行过程，抽象出工作流流程模板，为集成系统提供工作流引擎支撑。 5、集成系统管理 实现集成系统的统一管理，包括各个子系统配置管理、统一功能导航管理等。 系统管理：实现对需要集成的内部\外部子系统基础信息进行集成配置管理，包括系统名称、服务地址、排序等信息。 导航管理：以子系统为单位统一集成平台的功能导航目录，支持对系统、模块、页面、按钮的目录树管理，实现用户自定义、统一的功能导航。 按钮管理：对各个子系统的按钮进行管理，集成平台内置通用按钮，当通用按钮不能满足要求时，可为子系统自定义按钮。 自定义门户：将各个子系统统一门户展示，用户可自定义将功能导航中的系统、模块、页面作为门户展示，并可根据使用需求，对门户展示进行排序布局。 6、统一门户 （1）单点登录 在多个应用系统中，结合统一身份认证平台，用户只需要登录、认证一次就可以访问所有授权的应用系统。用户不需要多次登录，同时简化系统的用户账户管理。

基于金财工程应用支撑平台开发规范

《基于金财工程应用支撑平台开发规范（试行）》目 录 提出单位：中华人民共和国财政部 起草单位：财政部信息网络中心 发布时间：2009年2月 前言 《基于金财工程应用支撑平台开发规范（实行）》规定了基于应用支撑平台建设业务系统的技术要求，分为开发指南、参考手册、开发案例、配置手册、 问题解答等五部分。 开发指南是介绍应用支撑平台及基于应用支撑平台构建业务系统总体思路的技术文档，详细介绍了数据字典、总账、交易令、规则、权限、工作流、 交易凭证、安全、报表、数据交换等十个业务和技术组件，每个组件从基本功 能、设计原理、实现方式及应用开发等方面进行了说明，并对平台应用模式、 技术路线和部署模式等作了具体描述。 参考手册是基于应用支撑平台开发的技术文档，包括建立开发环境、公共对象结构、平台服务接口API说明、平台表结构和平台异常代码说明等。 开发案例介绍了基于应用支撑平台开发业务系统的实例，从开发的角度给系统开发人员提供参考。开发案例分别对生长模式和接入模式给出了实例说 明。 配置手册是应用支撑平台实施配置的参考手册，重点介绍了应用支撑平台本身的配置过程。具体内容包括：应用支撑平台的登录和系统定义、数据字典、

规则、总账和交易令、交易凭证、工作流、权限、数据交换、报表等的配置过程。 问题解答汇集了应用支撑平台在推广实施过程中常见的问题及解决办法。 规范性引用文件 CZ 0001—2008 《财政业务基础数据规范》中华人民共和国财政部颁布。 术语和定义 1．金财工程应用支撑平台（英文缩写FASP）：由财政部统一组织开发的、在全国财政系统推广应用的平台。应用支撑平台是统一标准的载体、整合系统的工具、连结上下级系统的桥梁、统一数据交换的中枢，为实现信息共享、协同工作提供技术手段，为实现资金监控、统计分析、决策支持创造条件。应用支撑平台是构建财政核心业务一体化管理大系统的基础，建设和推广应用支撑平台是金财工程一体化建设的根本保障。 2．业务系统：指用于财政业务管理的计算机软件系统。 3．业务组件：在总结、抽象财政业务共性的基础上，在应用支撑平台中构建的与业务密切相关的组件，包括：数据字典、规则、总账、交易令、交易凭证5个组件。 5．技术组件：在总结、抽象财政业务系统共性的基础上，在应用支撑平台中构建的与技术密切相关的组件，包括：工作流、权限、报表、安全、数据交换5个组件。 6．应用模式：基于应用支撑平台构建财政一体化大系统的设计、开发和部署模式，主要包括生长模式和接入模式。生长模式是指基于应用支撑平台的业务组件和技术组件，对现有业务系统进行合理改造、替换或开发新系统的一

电子政务内网应用软件支撑平台方案

电子政务内网应用软件支撑平台方案 1.1 建设背景和依据 目前，我国电子政务处在“跨越式”发展阶段，政府各部门的内部信息系统建设已经非常普及，随着电子政务的发展和深入应用，政务需求越来越清晰化，办公自动化程度要求越来越高，政府内部及部门间协作的智能化要求更加旺盛，电子政务内网网络建设和应用软件的推广和深层次应用受到重视各级机关的普遍重视。政务内网主要满足各级政务部门内部办公、管理、协调、监督和决策的需要，同时满足副省级以上政务部门的特殊办公需要。 政府电子政务内网(以下简称“政务内网”)是以政府系统各级、各部门行政领导、政府部门和政府工作人员为服务对象，具有办公事务处理、辅助决策、信息管理和资源共享等网上办公的政务协同基础平台。 政务内网应用软件支撑平台是政务内网开展软件建设和推进应用的软件支撑平台，平台建设后可将办公业务和信息服务统一集中到一个平台上，主要提供统一的数据库服务、统一的用户认证和单点登录服务，统一的权限划分和角色配置服务，统一的电子公章、数字签名、版式文件服务、统一的工作流程配置引擎和全站搜索服务。为公文办理、信息传输、会议管理、人力资源管理等各种政务工作提供支撑服务。实现各级行政主管部门同应用、互联互通、信息资源共享、网上办公和政务公开，提高政务信息化整体水平。最终构筑统一的政务协同基础平台，建立统一的政务内网信息门户。建设必需的安全保障体系，初步实现“政务资源数字化、内部办公协同化、信息交流网络化”。 1.2 建设内容 电子政务内网应用软件支撑平台主要建设内容如下： (1) 协同办公平台，支持业务开发的公共平台; (2) 内部门户：应用集成和内容集成; (3) 通用办公：政务管理、公文管理等功能的通用行政办公系统; (4)统一工作流管理平台：建立一个统一的业务流程管理平台，为办公系统、政务信息系统等提供服务; (5)数据集成平台：建立一个可覆盖全业务的数据中心，实现各业务系统间的数据共享、数据同步，数据交换。解决信息孤岛问题; (6)用户统一身份认证(CA中心)：建立一个统一的用户身份认证管理系统，来解决身份真实性认证及数据安全传输问题。基于CA认证的解决方案，即采用基于证书控件/网关模式的安全身份认证系统。

智慧城市公共支撑平台体系架构研究

□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□ 式。但由于历史原因，传统的信息系统之间存在壁垒，难以实现信息融合和共享。因此，需要建立智慧城市信息交互机制，通过智慧城市公共支撑平台，定义合适的接口规范和交互流程，来实现城市中信息的充分协同。本文结合３种基本的信息交互场景，给出了合理的智慧城市信息交互的技术解决方案。 参考文献 １中国电信智慧城市研究组．科学治理与城市个性：智慧城 市之路．电子工业出版社．２０１１ ２曹国辉．物联网托起智慧城市的美好明天．中国安防．２０１１，１０ ３汪芳，张云勇，房秉毅，徐雷，魏进武．物联网、云计算构建智 慧城市信息系统．移动通信．２０１１，８ ４郑立明．关于建设智慧城市的战略思考．现代管理科 学．２０１１，２ ５张永民，杜忠潮．我国智慧城市建设的现状及思考．中国 信界．２０１１，２ ５秦洪花，李汉清，赵霞．智慧城市的国内外发展现状．信息 化建设．２０１０，９ ＲｅｓｅａｒｃｈｏｎＣｒｏｓｓＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＩｎｔｅｒａｃｔｉｏｎｏｆＳｍａｒｔＣｉｔｙ Abstract Ｔｈｅｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｏｎｉｓａｎｉｍｐｏｒｔａｎｔｒｅｑｕｉｒｅｍｅｎｔｆｏｒｕｒｂａｎｍａｎａｇｅｍｅｎｔ．Ａｔｐｒｅｓｅｎｔ，ｔｈｅｒｅａｒｅｈｕｇｅｂａｒｒｉｅｒｓｂｅｔｗｅｅｎｄｉｆｆｅｒｅｎｔｉｎｆｏｒｍａｔｉｏｎｓｙｓｔｅｍｓｉｎｓｍａｒｔｃｉｔｙ，ｓｏｉｔｉｓｄｉｆｆｉｃｕｌｔｔｏａｃｈｉｅｖｅｔｈｅｇｏａｌｏｆｉｎｆｏｒｍａｔｉｏｎｓｈａｒｉｎｇａｎｄｃｏｌｌａｂｏｒａｔｉｏｎ．Ｓｕｃｈａｓｉｔｕａｔｉｏｎｍａｋｅｓｓｅｒｉｏｕｓｉｍｐｅｄｉｍｅｎｔｔｏｔｈｅｄｅｖｅｌｏｐｍｅｎｔｏｆａｓｍａｒｔｃｉｔｙ．Ｉｎｔｈｉｓｐａｐｅｒ，ｗｅｉｎｖｅｓｔｉｇａｔｅｔｈｅｃｒｏｓｓ－ｓｙｓｔｅｍｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｏｎｓｃｈｅｍｅｏｆｓｍａｒｔｃｉｔｙ，ｗｅｄｉｖｉｄｅｔｈｅｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｏｎｉｎｔｏｔｈｒｅｅｂａｓｉｃｓｃｅｎａｒｉｏｓｂａｓｅｄｏｎｔｈｅｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｏｎｒｅｑｕｉｒｅｍｅｎｔｏｆｓｍａｒｔｃｉｔｙ．Ａｔｌａｓｔ，ｔｈｅｒｅｌｅｖａｎｔｄｉｓｃｕｓｓｉｏｎｗｉｌｌｂｅｇｉｖｅｎｉｎｔｈｉｓｐａｐｅｒ．Key words ｓｍａｒｔｃｉｔｙ，ｃｒｏｓｓｓｙｓｔｅｍ，ｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｏｎ（收稿日期：2013-03-09） 1引言 目前，城市中建设、部署并实施应用的各种物联 网系统，普遍具有比较松散、杂乱的运营实体、地域范围、行业领域以及技术体系，形成了众多孤立、分散的信息通信系统，既存在重复建设的浪费，也导致了运营维护的复杂和困难。 相对于现有的城市综合信息化系统（如数字城 市、无线城市、宽带城市等），智慧城市侧重于实现城市各个信息系统间的信息共享、操作交互和业务协同，以实现对城市范围内海量信息通信资源的整合与共享。通过对原有的各行业物联网应用等孤立的、竖井式信息通信系统及其特定的行业应用进行统一实现，为政府、企业和市民提供了全方位的智慧型城市服务体系。 在智慧城市的４个层次，即感知层、传输层、数据 智慧城市公共支撑平台体系架构研究 罗 振武汉邮电科学研究院光纤通信技术和网络国家重点实验室新业务经理，工程师 摘 要智慧城市是一种综合了多个学科、服务于各类行业和对象的技术体系，可以通过公 共支撑平台，对原有各类信息通信系统的行业应用进行系统整合、资源共享和公共支撑，基于共性技术来对各种原有系统进行统一、有效的利用，从而实现智慧城市的最优化效果。 关键词智慧城市物联网信息通信系统公共支撑平台云计算 １０··

物联网应用共性服务公共支撑平台

物联网应用共性服务公共支撑平台 一、主要内容 物联网应用共性服务公共支撑平台建设由物联网应用交互支撑平台和物联网应用基础运营支撑平台组成，如下图1所示。 1）物联网应用基础运营支撑平台通过物联网网络基础设施实现广泛、跨域的感知互联，把感知到的各类信息全方位、无障碍、高可靠性、高安全性地进行传送到平台，并实现跨行业、跨应用、跨系统之间的信息协同、共享、互通。同时面向业务应用提供资源管理、运营管理、安全监控等运维支撑，构建面向应用的公共支撑平台。 2）物联网应用交互支撑平台通过应用的共性服务和支撑技术，以及标准规范、业务模式；基于电子认证、授权管理、商业智能、移动支付、信息检索、可定制的即时通信服务、征信信用服务等功能的可以安全、可信、灵活、快捷、可定制的支撑城市公共安全监管与应急指挥平台、智能城市运行管理、智能医疗卫生、智能交通、智能社区、智能物流等跨域、异构网络、多行业应用集成的智能物联网应用。

图1 物联网公共支撑平台体系示意图 通过物联网应用共性服务公共支撑平台的建立，降低应用研发和运营成本，打破局部应用壁垒，快速孵化各种创新物联网应用。 二、国内外技术状况分析、产业链状况分析（带动相关产业等） 针对目前物联网应用领域存在的问题，物联网应用共性服务公共支撑平台的建设目标是：1）物联网是典型的应用驱动型网络，不同的物联网应用对传感器网络节点和功能机制有不同需求，“垂直”应用是物联网的“点”难以构成“网”和“面”；2）现有物联网应用感知功能单一、局部应用、数据孤立、缺乏互联互通和联动机制，亟需产业链的贯通和水平分层架构的体系支撑。 物联网应用共性服务公共支撑平台旨在将物联网中局部应用、单一感知的资源由封闭转变为开放的、标准化的、可跨领域应用的共享资源，并通过共性服务集成技术将分散、小范围的物联网数据、网络、应用资源汇聚集成为共性服务资源群，形成了统一的物联网共性服务公共支撑体系，面向城市公共安全、城市运行管理、交通、医疗卫生等应用共性需求实现有效支撑；从而形成物联网应用中枢系统，打通了物联网产业链，推动北京市以及我国物联网各领域持续、快速、和谐发展。 三、市场前景 物联网应用共性服务公共支撑平台是应对我国经济转型历史契机、信息通信技术融合发展和电信成熟服务运营体系集成创新的凝聚，体现了知识密集型的集成创新为物联网应用提供专业化、知识化、网络化、资源化服务的巨大支撑。 利用信息技术和共性服务公共支撑体系，以高效、便捷、低成本的运转方式提供专业化、第三方可信的资质服务；项目的新技术、高技术推动以低能耗、低污染、低排放为基础的低碳经济发展模式，类比电信服务的成熟运营，物联网产业链中快速涌现规模化的服务运营商引领经济发展。 共性服务能力开放、集成交付提供、安全可信运营支撑这一体系的关键技术的突破和实现，使得快速构建城市公共安全监管与应急指挥平台、智能城市运行管理、智能医疗卫生、智能交通、智能社区、智能物流这些物联网应用的愿

应用支撑平台技术白皮书

应用支撑平台技术白皮书 版本：1.9 https://www.sodocs.net/doc/6e13981749.html,

白杨应用支撑平台技术白皮书版本控制 版本号修改时间修改内容修改人审阅者 1.0 2007-07-21 创建，从老版概述文档迁移白杨 白杨 修正文档组织结构（6.3.3 -> 6.4）； 1.1 2007-08-09 纠正个别措辞 新增 web 应用扩展库说明白杨 1.2 2008-01-04 加入 bz2 算法支持白杨 1.3 2008-03-19 更新 AIO 框架；新增 SCGI 支持白杨 1.4 2009-12-02 重构文档；新增 HTTP 支持白杨 1.5 2010-04-27 新增 Web 框架性能比较表白杨 1.6 2010-06-13 新增HTTP Pipelining描述白杨 1.7 2010-07-06 白杨 1.8 2010-08-25 根据近期底层库的调整新增 LRU Cache等组件 白杨 1.9 2010-08-27 新增典型的Web应用节点工作模型 说明

白杨应用支撑平台技术白皮书前言 白杨应用支撑平台从2002年发布第一版以来已有超过8年的历史了。在这8年多里，我一共为支撑平台编写了超过50万行C/C++代码。其中最基础也是最重要的libutilitis库基本上是完全由我亲手实现的。因为要实现libutilitis中包含的大量跨平台功能封装，除了原本就比较了解的Windows平台，我也逐渐熟悉并喜爱上了Linux、FreeBSD/NetBSD/OpenBSD、OpenSolaris等优秀的操作系统。 对于支撑平台中的其它库，我的主要做法就是以libutilitis为基础，设计一套界面/框架。然后依赖没有版权问题而且品质稳定的第三方代码来实现具体功能。例如：libcrypto中的密码编码学和数据压缩算法；libaudioio中的音频编解码器等等。 多年来，基于支撑平台的各种产品已被广泛部署于兴业银行（China CIB）、中石油（CNPC）、华安保险（Sinosafe Insurance）、淘宝网（https://www.sodocs.net/doc/6e13981749.html,）、法兴银行（SOCIETE GENERALE）、德尔福汽车（Delphi）、美联航（United Airlines）、GE（美国通用电气）、贝塔斯曼（Bertelsmann）等各大企业的生产环境中。生产环境下的大范围部署不但为上层应用提供了可靠的、平台无关的底层环境，也进一步检验了可靠性、稳定性、可移植性、高效性等各方面指标。

基于金财工程应用支撑平台建设财政一体化信息管理系统

基于“金财工程”应用支撑平台建设财政一体化信息管理系统 部门预算管理系统技术方案

摘要：本文详细论述部门预算管理的业务范畴、用户群体、功能需求及其意义。文章主要包括以下几个部分内容：（1）背景。论述了本文的编写目的、预期读者等。为阅读者起到导航的作用。（2）业务描述。描述了部门预算管理的业务主体、管理内容及其操作过程。（3）功能描述。依据业务描述中的业务主体、管理内容和操作过程论述了应实现的功能。

1目录 1.背景 (4) 1.1.编写目的 (4) 1.2.预期读者 (4) 1.3.参考资料 (5) 1.4.业务术语 (5) 1.5.业务简介 (5) 2.任务概述 (6) 2.1.建设目标 (6) 2.2.建设任务和原则 (7) 3.系统总体流程 (8) 3.1.系统总体流程图 (9) 4.系统总体框架 (9) 4.1系统总体框架结构图 (9) 5、项目管理 (10) 5.1目标 (10) 5.2功能 (11) 5.2.1项目库管理 (11) 5.2.2项目流程管理 (11) 5.2.3项目滚动管理 (12)

变更说明

1.背景 随着财政改革的不断深化，“金财工程”建设取得了较大进展，初步形成了以预算管理为源头，以国库收支管理为预算执行主线的系统框架，并在财政部门得到推广应用，为财政改革顺利推进、加强财政管理提供了有力的技术支撑。目前各级财政部门正在进行金财工程应用支撑平台和财政一体化系统的建设工作，构建使财政主体业务全面贯通、处理自动化的财政管理信息系统，作为财政业务的起始源头的部门预算管理系统，是金财工程业务系统的重要组成部分，系统从项目库、预算编制、预算审核、控制数管理、预算批复、结余资金管理、基础资料管理实现整个预算流程的一体化管理，提高财政资金使用效益。 1.1.编写目的 本文档的编写目的是定义部门预算管理系统高级需求，是部门预算管理系统开发的基础和文档依据。供分析人员和开发人员使用，是用户和相关分析员、开发人员、测试人员的项目依据文件。 1.2.预期读者 ?业务用户 ?客户 ?项目经理 ?系统设计人员 ?本项目参与人员

电子政务内网应用软件支撑平台方案

电子政务内网应用软件 支撑平台方案 Document number：WTWYT-WYWY-BTGTT-YTTYU-2018GT

电子政务内网应用软件支撑平台方案 建设背景和依据 目前，我国电子政务处在“跨越式”发展阶段，政府各部门的内部信息系统建设已经非常普及，随着电子政务的发展和深入应用，政务需求越来越清晰化，办公自动化程度要求越来越高，政府内部及部门间协作的智能化要求更加旺盛，电子政务内网网络建设和应用软件的推广和深层次应用受到重视各级机关的普遍重视。政务内网主要满足各级政务部门内部办公、管理、协调、监督和决策的需要，同时满足副省级以上政务部门的特殊办公需要。 政府电子政务内网(以下简称“政务内网”)是以政府系统各级、各部门行政领导、政府部门和政府工作人员为服务对象，具有办公事务处理、辅助决策、信息管理和资源共享等网上办公的政务协同基础平台。 政务内网应用软件支撑平台是政务内网开展软件建设和推进应用的软件支撑平台，平台建设后可将办公业务和信息服务统一集中到一个平台上，主要提供统一的数据库服务、统一的用户认证和单点登录服务，统一的权限划分和角色配置服务，统一的电子公章、数字签名、版式文件服务、统一的工作流程配置引擎和全站搜索服务。为公文办理、信息传输、会议管理、人力资源管理等各种政务工作提供支撑服务。实现各级行政主管部门同应用、互联互通、信息资源共享、网上办公和政务公开，提高政务信息化整体水平。最终构筑统一的政务协同基础平台，建立统一的政务内网信息门户。建设必需的安全保障体系，初步实现“政务资源数字化、内部办公协同化、信息交流网络化”。

建设内容 电子政务内网应用软件支撑平台主要建设内容如下： (1) 协同办公平台，支持业务开发的公共平台; (2) 内部门户：应用集成和内容集成; (3) 通用办公：政务管理、公文管理等功能的通用行政办公系统; (4)统一工作流管理平台：建立一个统一的业务流程管理平台，为办公系统、政务信息系统等提供服务; (5)数据集成平台：建立一个可覆盖全业务的数据中心，实现各业务系统间的数据共享、数据同步，数据交换。解决信息孤岛问题; (6)用户统一身份认证(CA中心)：建立一个统一的用户身份认证管理系统，来解决身份真实性认证及数据安全传输问题。基于CA认证的解决方案，即采用基于证书控件/网关模式的安全身份认证系统。 建设目标 以政府电子政务网络和安全体系为基础，以政务需求为导向，采用先进的开发技术和数据库结构，建设标准统一、功能全面、技术先进、简单易用的一体化办公平台。在一网式无纸化协同办公管理平台中除体现办公、政务信息和会议通知等功能以外，还将通过相关的办公事务管理以及及时消息、在线考试等辅助功能实现互动管理。同时还将实现机关内部事务管理平台，对人事信息、资金资产等机关事务进行管理。为进

智慧校园应用支撑平台建设方案

智慧校园应用支撑平台建设方案 1.1.1中职学院信息标准规范 1.1.1.1概述 信息标准是整个智慧校园信息化建设的基础，信息标准在全校范围内为数据库设计提供类似数据字典的作用，为信息交换、资源共享提供了基础性条件。信息标准确保信息在采集、处理、交换、传输的过程中有统一、科学、规范的分类和描述，能够使信息更加有序流通、最大限度地实现信息资源共享,使学校信息系统得到协同发展，发挥信息资源的综合效益。 1.1.1.2建设目标 按照教育部发布的最新数据标准，对数据基本单元的标识、分类编码、含义、表示格式等各个方面进行规范和统一，并形成统一的教育标准数据库。经过标准化的数据是信息系统的基石，可以确保各项业务以完整、有效、高效的方式运行。可以说，数据标准化工作是高校信息化建设的最基础工作。

1、统一的数据标准有利于各系统之间数据共享和统一管理，减少信息资源不足存在的矛盾； 2、为校内各系统数据库进行集成整合提供方便，确保各个业务员系统之间数据的转换和全校范围内的数据互转互通工作有效的进行； 3、通过统一数据口径、完善指标体系，可确保数据的完整性、准确性、一致性，有利于向上一级部门提供方便统一的数据报表，也方便向下级部门收集数据； 4、统一的数据标准对快速创建索引和排序，建立表间联系，优化查询等都是必不可少的，同时也便于对数据的进一步挖掘与操作。 1.1.1.3功能设计 1.1.1.3.1信息标准及数据管理 1.信息标准代码集的制定与初始化 实现信息标准代码集的新增、修改、删除、查询、导入等功能。根据教育部信息化标准中的《教育管理基础代码》初始

化标准代码集。 2.信息标准集的制定 根据教育部信息化规范，建立学校的标准数据库。内容包括学校基本信息、学生信息、教职工信息、招生信息、教学信息、办公信息等等，同时，也可以包括一些带有学校特点的其它信息。 3.信息标准的发布 对符合教育部信息化标准以及学校信息化标准的数据标准发布，生成相应的数据模型。 1.1.1.3.2据维护 对学校基础信息进行的维护、管理与查询。包括：学校概况数据、学生管理数据、招生管理数据、教职工管理数据、教学管理数据、办公管理数据等数据的维护。 1.1.1.3.3标准数据导出 系统提供按标准的格式导出数据的功能，如：可以将数据导出为固定模板的Excel、文本等格式，系统支持单表数据导

基于大数据的云计算支撑平台IOP

基于大数据的云计算支撑平台 IOP 浪潮IOP（Inspur Open Platform）是一个云计算架构的开放平台，采用大数据处理、社交网络、情景感知、服务化架构等关键技术和理念开放的应用支撑和资源整合平台，通过共享平台强化企业信息资源的有机整合和高效利用，构建开放、协同、智能、互联、弹性可扩展的IT基础软件环境，使客户有机会利用新技术的解决传统IT系统规划和建设存在的诸多难题，实现信息化从传统架构向云计算架构的平滑转型。 IOP平台采用“平台+应用”的总体思路，采用支持分布式、高并发和大数据处理的云计算架构设计。开放的架构为各种应用提供分布式计算、分布式存储、大数据分析、统一用户认证、统一消息引擎、统一资源管理等基础支撑服务能力，通过IOP可以整合来自内外部的各类信息资源，实现信息资源共享，开放业务能力和数据资源，创新应用开发和IT服务模式。 IOP平台的应用领域包括：基于云计算的信息化应用支撑、大数据处理和资源整合以及面向公众的互联网服务和电子商务。

IOP具备四个方面的关键特性，以满足之上承载应用的稳定运行。 1、满足百万级以上用户海量数据快速存取，并能够支持水平扩展， 基于大数据可弹性扩展的技术架构。 2、利用Open API整合与共享信息资源，对基础共性服务统一构建， 基于开放平台为多应用提供公共服务。 3、制定应用开发统一的标准规范，采用应用商店模式搭建应用生 态环境，促进应用创新。。 4、IOP产品研发始终坚持安全可控的技术路线，所有底层架构和 组件均为自主研发。 目前平台研发工作已经有了初步的成果，并在浪潮实施的包括智慧城市、警务云等一些重大项目中进行应用，浪潮IOP平台的应用极 大的提高了行业IT整体的计算能力、整合能力和创新能力,下一步将

统一应用支撑平台参考

统一应用支撑平台 遵循统一规范构建随需应变的的应用系统 应用支撑层是华炎办公管理各项应用系统和服务应用系统的运行支撑环境，是实现用户管理和权限控制、工作流管理、信息交换的公共服务基础平台。 应用支撑平台的主要任务包括：一是作为系统的软件运行环境，提供基础的公共功能，支持信息交换、协同工作；二是作为应用管理和数据管理平台，实现统一的用户管理和权限控制。在此基础上，支持各种具体应用。 应用平台支撑层基于构件化思想，可以随用户的不同需要提供不同的解决方案。该平台产品的构件化思路是以基础构件为核心、其他构件为业务插件的"主体+插件"形式，搭建出来的各个子系统健壮灵活，从而保证了大型企业级应用的稳定性和高效的可扩展性。 ?构建随需应变的的应用系统，增强企业快速实施战略部署能力 ?可视化组件及工具，降低使用及开发难度，提高快速执行力可持续增长的知识构件管理，降低重复开发投入，提高企业核心竞争力 ?多年多行业大型应用的经验积累，降低进入行业的门槛，提供稳定可靠的应用基础?提高应用系统的可移植性，实现应用在异构环境中的快速部署 ?构建组织信息门户，提供底层应用互通的基础，实现多业务、多系统的集成 应用支撑平台作为系统的中间层构件，它基于跨操作系统平台、数据库平台的中间件软件构建，应具有良好的平台兼容性、部署灵活性、互操作性和标准性等特点，从而达到基于应用支撑平台之上构建的业务应用系统，建设周期短，平台移植性强，系统运行稳定、维护方便的目的。

统一工作流引擎 为了统一设计、统一管理华炎办公管理不同业务系统的工作流特性， 我们整合了完全符合WFMC（工作流管理联盟）国际标准模型的统一工 作流引擎，提供给我们的开发团队、合作伙伴和客户方的定制开发小 组调用。 流程设计平台 流程设计平台提供了完全可定制的工作流引擎，可供系统各模块自由调用。系统全面采用工作流管理与控制，各项工作的流程可以根据单位实际工作规范进行配置。系统管理员无需编程便可灵活自定义出符合各种业务特征需求的流程，流程数量不限，调整灵活，能完全适应未来的需求发展及变化。工作流支持多种的归档方式；支持多种办理方式；支持多种办理人及办理权限选择和控制；支持直流、分流、辅流、条件分支、自由流程及流程嵌套等多种流向方式。从工作流规划、设计、授权、运行，调整、以及监控和管理，动态地反映一个完整的业务处理过程。 工作流的设计完全基于图示的方式，简单、明了。 一、工作流设计中主要涉及了7节点类型：通知、处理、角色处理、通知角色、通知提交者、提交者处理、归档。 1、通知和通知角色：通知节点只有一个分支。两者的区别是在本步骤中的处理人一个是非角色一个是角色（角色的概念是在流程设计前定义好的，比如：提交者是市场部的人员，市场部定义了他的下一步骤处理人为角色，那么在提交的时候，系统会自动寻找到市场部的角色处理人（一般为领导））。 2、处理和角色处理：默认有两个分支，可以选择多个分支（最多只能选择8个）。

金财工程应用支撑平台

金财工程应用支撑平台（FASP）简介 金财工程应用支撑平台（FASP）是整个金财工程的核心系统，是按照“金财工程”总体设计规划，为实现当前财政行业信息化产品和服务的要求而开发。FASP坚持一套控制机制、一本总帐、一套编码体系、一个数据平台为原则，一体化支撑财政主体业务。在统一应用平台的支撑下，建设以预算编制为源头、收支管理为过程、预算及执行分析为回路接点，全面覆盖预算及收支管理的“金财工程”核心业务大系统。 一、平台核心框架 一套标准代码体系统； 一个管理层面的业务会计信息； 一套总帐支撑一级财政全部会计业务； 一套控制机制控制一级财政所有预算指标以及预算执行过程； 一个数据平台详细记录一级财政财务事件级会计业务信息，

产生相关管理报告。 二、平台设计思路 （1）财政大系统由平台及表层业务系统共同组成 平台则由业务组件和技术组件共同构成，抽取财政业务的共性，形成业务组件；抽取信息系统的共性，形成技术组件。 通过稳定的平台，支撑多变、个性化的表层业务系统。 （2）通过平台支撑未来业务发展 实现业务管理一体化、信息资源一体化、流程控制一体化、技术实现一体化、服务一体化。 （3）平台统一的大系统技术路线 采用应用层、驱动层、数据层三层结构的设计思想，建设在政府财政应用平台支撑下具有较高自动化程度的财政大系统。 三、应用范围 各省、市、县级财政部门

与国民经济相关的各个行政管理部门 四、平台整体技术构架

GFMIS系统采用J2EE技术，跨平台、跨数据库。支持当前主要的技术规范、工业/准工业标准和安全标准，严格遵循面向对象的技术原则，采用组件式开发模式，注重产品的技术架构的建立。采用应用层、驱动层、数据层三层结构的设计思想，用户可以灵活地按需进行自定义配置，能够有效地支持产品的进一步发展。 系统框架定义为“服务器端系统框架”，为各种客户端的请求提供服务。 系统框架为以下两类客户端请求提供服务：Web客户端（浏览器，简称B端）、应用程序客户端（Windows界面，简称C 端）。 客户端与服务器通过HTTP协议进行通信，Web客户端(B 端)与服务器交互使用HTML进行数据传输，应用程序客户端（C 端）与服务器交互使用XML进行数据传输。