xx工程建设领域项目信息和信用信息公开平台规划建议书

xx工程建设领域项目信息和信用信息公开平台规划建议书内容摘要：

发布。 项目招标投标信息由相应部门发布。 项目建设管理信息和从业单位、主要从业人员行为信息由项目建设单位提供，项目主管部门依据管理权限审核、发布。 土地使用权、矿业权审批和出让信息由国土资源主管部门收集、审核和发布。 相关企业基础信息由企业登记主管部门依据职能公开。 相关企业资质和个人职业资格的基础信息由建设资质主管部门依据职能公开。 各有关部门根据审批和管理权限，及时公开项目信息。 项目信息与信用信息公开平台通过中间件技术自动采集项目信息，并在公开平台上展示。 公开平台 展示 需求描述 项目信息与信用信息公开平台通过门户 Portal 中间件技术，将采集到的信息展示到门户平台上，界面展示内容如下：  项目信息公开专栏 (一) 在政府网站首页设置项目信息公开专栏，名称为“工程建设领域项目信息和信用信息公开共享专栏”（以下简称“专栏”）。 (二 ) “专栏”首页顶部为标题区，标题内容包括专栏名称和专栏建设单位。 “专栏建设单位”用“行政区域名称 +建设单位名称”表示。 (三 ) “专栏”设置项目信息公开区和信用信息共享区。 (四 ) “项目信息公开区”应设立项目审批信息、项目建设管理信息、从业单位和主要从业人员信用信息、土地使用权、矿业权审批和出让信息等内容。 (五 ) “信用信息公开区”须设立 “信用信息共享目录”，提供信用信息共享的获取功能。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 11 页 共 117 页 (六 ) “专栏”内设置项目信息搜索栏。 在搜索栏输入关键字，可对专栏内公开的项目信息进行检索。  项目信息公开 (一) 项目信息公开的基本内容，应包括：项目审批信息、项目建设管理信息、项目从业单位和主要从业人员信用信息、土地使用权、矿业权审批和出让信息等。 (二 ) 项目信息公开内容列表页须采用分页浏览方式。 列表条目内容应以“序号”、“项目编码”、“项目名称”、“发布日期”等标识。 点击条目进入该条目项下的详细信息。 (三 ) 详细信息页面上方应显示项目信息标题，注明信息发布部门和日期。 (四 ) 项目审批、核准信息由项目审批部门收集、审核和发布。 项目招标投标信息由相应部门发布。 项目建设管理信息由项目建设单位（项目法人）提供，项目主管部门审核、发布。 从业单位、主要从业人员行为信息由项目建设单位（项目法人）提供，项目主管部门审核、发布。 土地使用权、矿业权审批和出让信息由国土部门收集、审核和发布。 (五 ) 项目信息和信用信息公开由部门依据职能负责信息更新、维护和服务。 (六 ) 收集和发布的信息须及时、准确和完整。  信用信息共享 (一) 信用信息共享的基本内容，应包括：从业单位基本信息、资质信息、项目业绩信息、信用评价信息、良好 行为记录信息和不良行为记录信息等；从业人员基本信息、执业资格信息、良好行为记录信息和不良行为记录信息等。 (二 ) 信用信息共享提供部门须提供网络在线的信息获取方式。 (三 ) 从业单位信用档案的内容，应包括基本信息、资质信息、业绩信息、荣誉（奖励）信息、不良行为信息等。 (四 ) 从业人员信用档案的内容，应包括基本信息、执业资格信息、参与项目信息、荣誉（奖励）信息、不良行为信息等。 (五 ) 从业单位和从业人员信用档案，须注明发布机构和发布日期，各类信息须注明来源部门和收集日期。 (六 ) 共享信用信息的提供、更新、维护和服务，由各级行业主管部门依据职能 负责。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 12 页 共 117 页 前段码（ 19 位） XXXXXX X„ X XXXX XX„„ X 序列码（不定长）  信用等级评价结果公开表示规则 (一) 各行业根据本行业规则开展工程建设领域的从业单位信用等级评价，评价加过信息公开时应遵循公开表示规则。 (二 ) 信用等级评价结果公开表示分为 A、 B、 C 三等。 (三 ) 信用等级评价结果公开表示为 A 等的，表示从业单位在评价期内信用较好，投标行为规范，履行合同情况较好，工程质量优良，无不良行为记录。 (四 ) 信用等级评价结果公开表示为 B 等的，表示从业单位在评价期内信用一般，投标行为基本规范，履行合同法情况一般，无工程质量安全事故，无较大不良行为记录。 (五 ) 信用等级评价结果公开表示为 C 等的，表示从业单位在评价期内信用较差，经营活动中有违法行为，履行合同情况较差，有工程质量安全事故记录，有严重不良行为记录。 (六 ) 信用等级评价结果信息公开共享时，评价结果信息的对应表示工作由信息发布或提供部门负责。 评价结果信息对应表示后的展现方式是评价结果信息后位加括号标定对应等级信息，以示区分。 如“ AAA(A)”，表示原等级为 AAA，对应表示后的等级为 A。  信息表现格式 (一) 项目信息和信用信息表现形式为电子数据，包括结构化数据和非结构化数据。 (二 ) 非结构化数据包括办公文档、纯文本、表格、网页、图片、音频、视频。 (三 ) 根据 GB/T209162020，文本文档采用 XML 格式，图片采用 JPEG 格式，音频采用 WAV 格式，视频采用 AVI 格式。 (四 ) 办公文档、纯文本、表格和网页中的中文采用简体中文字符。  项目编码规则 (一) 编码对象是工程建设领域的工程项目。 (二 ) 项目代码由项目审批单位在项目立项时负责赋码，项目代码在使用过程中保持唯一性和不变性。 (三 ) 项目代码是采用组合编码方式生成的特征组合码，由 19 位前段码和不定长序列码组成。 排列顺序从左至右依次为： 6 位行政区划代码， 9 位项目建设单位组织机构代码， 4 位年度和不定长序列码。 具体表示形式如下图所示。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 13 页 共 117 页 (四 ) 行政区划代码： 6 位数字，按 GB/T2260(2020)的规定执行。 中央的行政区划代码为“ 000000”。 (五 ) 项目建设单位组织机构代码： 9 位数字。 (六 ) 年度： 4 位数字，表示项目立项的年度。 (七 ) 序列号：不定长字符的序列号，在同一前段码下具有唯一性。 数据 共享 需求描述 公开平台所展示的信息来源于不同部门、不同的业务系统，数据的形式也是多种多样，既包括结构化数据如数据库、结构化文本、 xml 文件，也包括非结构化数据如办公文档、纯文本、表格、网页、图片、音频、视频等，因此需要采用企业服务总线 ESB 产品，连接不同的业务系统与数据库，采集数据。 公开平台展示的数据要求具备时效性，当主管部门审核完成并公开发布的项目信息 、单位信息、人员信息，需要快速、准确、自动的展示到公开平台上，避免手工重复录入。 数据共享平台是项目信息与信用信息公开平台建设的核心，所选择的企业服务总线产品应具备灵活的部署模型，能够适应不同的网络、系统、硬件环境，具备数据安全传输能力，具备高可用性，具备可扩展性。 公开平台的建设应不影响各部门现有业务系统的正常使用，数据采集应自动完成，实现各部门节点与公开平台之间的数据传输模式。 数据交换提供基于事件和消息的多种会话模式，包括：  推：点到点或点到多点的主动信息推送方式。  拉：点到点或点到多点的被动信息获取 方式。  组播：在一个域或群组范围内的多点群发方式。 数据交换必须能够支持多种不同的会话策略，包括：  实时：基于事件驱动，由系统运行时动态产生和控制的会话方式。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 14 页 共 117 页  定时：由系统定时器根据预设的定时策略产生和控制的会话方式。  手工：系统运行时由用户手工产生和控制的会话方式。 数据交换的过程，必须能够支持跨平台、跨协议、跨存储介质、跨数据结构的数据交换、影射、转换，提供不重、不漏、不错、不丢的可靠、安全、稳定的数据传输。 同时，能够通过一个节点，完成对所有的分布数据节点进行可视化管理和维护。 管理和维护包括 ESB 状态监控、远程交换部署、远程服务管理、日志管理等多种基础管理功能。 非功能性需求 根据我们所建设的信息化系统的经验，我们认为，本次项目建设还需要满足以下需求。  技术路线需求 系统设计应采用业界成熟的先进技术，使系统建立在较高的起点。 能够支持不同厂家的系统软件，包括操作系统、数据库管理系统、应用服务器系统等，保证系统的可靠性、开放性、可维护性、先进性。 同时，系统的设计、开发、部署、测试等均要遵循软件开发标准体系，应采用国际、国内成熟的信息技术和先进的技术标准，要能与其它系统互联互通并具备扩展性和可维护性。  投资保护需求 系统建设必须充分考虑到对现有设备的利用和对已有投资的保护问题，技术上要有前瞻性，并力争在以后的升级中追加投资和费用最少、最有效。 系统采用的软件平台都应该基于开放式架构，从而保证整个软硬件系统的“向前兼容”及“向后扩展”。  可扩展性需求 要充分考虑技术体系发展前景，适应未来发展的需要。 系统应能适应业务发展和变革的需要，适应用户数量及业务量的增长，新业务的增加以及业务的变化。  兼容性需求 能够兼容其它相关业务环境下的软件系统。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 15 页 共 117 页 第 3章 平台 设计方案 方案选型 根据项目建设目标、需求及总体技术要求，建议在 项目建设采用金蝶中间件的 SOA 整体解决方案，方案涉及产品：金蝶 Apusic 门户平台（ Apusic Portal Server，简称 APS）与金蝶 Apusic 企业服务总线（ Apusic Enterprise Service Bus，简称为 AESB）。 金蝶 Apusic 企业服务总线 技术能力分析 面向服务架构（ SOA）的实现前提是可以通过经济高效的方式整合现有的以及新建的应用、流程和服务，无需在应用中添加复杂的编程程序便可验证或确保信息交换的可靠连接，而企业服务总线 ESB（ Enterprise Service Bus）正是在 SOA 环境中实现连接的理想解决方案。 ESB 通过以下多种能力来满足和保证应用及服务的连接性需求：  够在服务之间对消息进行匹配和路由；  在请求方与服务提供方之间转换协议；  在请求方与服务提供方之间转换消息格式；  分配和提取不同来源的业务事件。 ESB 通过应用、系统和服务之间的中间层来执行上述所有任务，不仅能够确保应用的总体复杂性不会因为连接接口的增加而增加，而且在许多情况下还能帮助企业避免或降低应用的复杂性，消除应用和系统之间所有硬编码链接。 ESB 是所有应用、服务以及其他 IT 资产的信息交互中枢，服务交互中的参与者连接至 ESB，而不是彼此直接相连。 当服务请求者连接至 ESB 时， ESB 负责将其请求传递 (通过消息 )至能提供所需功能与服务质量的服务提供者。 即使协议、交互模式或服务能力并不匹配， ESB 仍可以促进请求者与提供者之间的交互与递送。 如果对所有的应用和有效连接都采用这种机制，则应用只需单一接口便可将 ESB 连接起来，用于开展所有互动。 此外，连接 ESB 的所有其他资产都能通过这个接口与此应用进行互动，而其他资产同样只需一个接口便可实现与 ESB的连接。 无论处理要求和复杂性发生怎样的变化， 这些接口始终都是 ESB 环境中最重要的组件，并可在 ESB 中进行维护，以便在周围环境发生变化时确保应用能够以不变应万变。 青海工程建设领域项目信息和信用信息公开平台规划建议书 金蝶中间件 第 16 页 共 117 页 消除应用之间的连接性可大大降低应用中接口的复杂性，从而降低有关对这些应用进行更改的成本和风险，让用户能够以更简单、更快速、更安全的方式来使用它们，尤其是能够让用户对更多的应用和功能作为服务加以访问和重复利用。 通过加速实现 SOA 这一进程，可帮助企业获得前所未有的灵活性和响应性。 服务总线统一制定的标准业务服务接口，可通过多种服务实现方式进行接入并注册，实现访问协议的透明化；并可对各应用间的交互 服务进行协同编排，大大降低各应用系统之间的耦合度。 统一标准服务 服务总线通过统一制定的标准业务服务来规范服务接口，各应用系统按此标准接口来实现真正的服务。 服务总线以标准接口的形式来进行协同编排，可避免应用系统的具体实现问题对整个集成造成影响。 SOA 强调企业内不同系统间的松散耦合。 服务接口结构在 SOA 中是最重要的，设计糟糕的服务接口可能会极大地导致使用此接口的很多服务使用者应用程序的开发过程变得非常复杂。 从业务角度而言，设计糟糕的服务接口可能使得业务流程的开发和优化变得复杂。 相反，设计良好的服务接口可 以加速开发计划的执行，并对业务级别的灵活性起到促进作用。 接入方式 JCA 方式 JCA 是 J2EE Connector Architecture 的简称，它定义了支持 J2EE 组件以安全、可伸缩且支持事务的方式访问 EIS 的标准。 通过遵循 JCA 标准，。