DB5305T 19.28-2019保山市信息惠民工程综合标准 第28部分：信息惠民工程系统集成标准

ICS35.240L67保山市DB5305地方标准DB/T19.28—2019替代DG5305/T19.28—2017保山市市场监督管理局发布DB5305/T19.28—2019前言本标准按照GB/T1.1—2009《标准化工作导则第1部分：标准的结构和编写》给出的规则起草。本标准由保山市大数据管理局提出。本标准由保山市工业和信息化委员会归口。本标准起草单位：保山市大数据管理局。本标准主要起草人：刘志胡、王明超、李祖燕、丁威、邹瑜、朱超群。本标准替代DG5305/T19.28—2017。1DB5305/T19.28—2019保山市信息惠民工程综合标准第28部分信息惠民工程系统集成标准1范围本标准规定了保山市信息惠民工程系统集成的术语、定义和缩略语、系统集成体系、门户集成、应用集成、数据集成、系统集成接口规范、技术要求，本标准适用于保山市信息惠民工程应用系统集成的建设。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T4754国民经济行业分类与代码GB/T18793信息技术可扩展置标语言(XML)1.0GB/T21063.4政务信息资源目录体系第4部分：政务信息资源分类DB5305/T19.3-2019保山市信息惠民工程综合标准术语DB5305/T19.25-2019保山市信息惠民工程综合标准数据交换与共享平台技术标准DB5305/T19.41-2019保山市信息惠民工程综合标准信息惠民统一门户技术标准DB5305/T19.49-2019保山市信息惠民工程综合标准权限管理与登录技术标准DB5305/T19.50-2019保山市信息惠民工程综合标准数字证书技术应用标准3术语、定义DB5305/T19.3-2019确立的以及下列术语和定义适用于本标准。3.1应用系统集成应用系统集成指以系统的高度为客户需求提供应用的系统模式，以及实现该系统模式的具体技术解决方案和运作方案，即为用户提供一个全面的系统解决方案。应用系统集成已经深入到用户具体业务和应用层面，在大多数场合，应用系统集成又称为行业信息化解决方案集成。3.2应用程序接口应用程序接口指在数据封装时，网络分层中的每个层相互之间会用接口进行交互并提供服务，其中应用层与用户之间的接口。API实际上是一种功能集合，也可说是定义、协议的集合，无论是那种集合，它的实质都是通过抽象为用户屏蔽实现上的细节和复杂性。3.3SOA(面向服务的体系结构)SOA面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。3.4Web服务2DB5305/T19.28—2019WebService是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得WebService能与其他兼容的组件进行互操作。3.5公共对象请求代理体系结构CORBA(CommonObjectRequestBrokerArchitecture,公共对象请求代理体系结构，通用对象请求代理体系结构)是由OMG组织制订的一种标准的面向对象应用程序体系规范。3.6Java消息服务JMSJava消息服务应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。4缩略语下列缩略语适用于本标准。——AJAX：AsynchronousJavascriptAndXML，异步JavaScript和XML——API：ApplicationProgramInterface，应用程序编程接口——BPEL：BusinessProcessExecutionLanguage，业务流程执行语言——BPM：BusinessProcessManager，业务流程管理——BPMN：BusinessProcessModelingNotation，业务流程建模与标注——CORBA：CommonObjectRequestBrokerArchitecture，公共对象请求代理体系结构——EJB：EnterpriseJavaBean，JavaEE服务器端组件——FTAM：FileTransferAccessandManagement，文件传输访问和管理——FTP：FileTransferProtocol，文件传输协议——HTML：HyperTextMark-upLanguage，超文本标记语言或超文本链接标示语言——HTTP：HyperTextTransferProtocol，超文本传输协议——IAAS：InfrastructureAsAService，基础设施即服务——IP：InternetProtocol，网际互联协议——IT：InformationTechnology，互联网技术——JCA：JavaConnectorArchitecture，J2EE连接器架构——JDBC：JavaDataBaseConnectivity，java数据库连接——JMS：JavaMessageService，Java消息服务——JSP：JavaServerPages，Java服务器页面——MOM：Message-OrientedMiddleware,面向消息的中间件——ORB：ObjectRequestBroker，对象请求代理——RMI：RemoteMethodInvoke，远程方法调用——SCA：ServiceComponentArchitecture，服务组件架构——SDO：ServiceDataObject，服务数据对象——SOA：Service-orientedArchitecure，面向服务的体系结构——SOAP：SimpleObjectAccessProtocol，简单对象访问协议——SSL：SecureSocketsLayer，安全套接层——TLS：TransportLayerSecurityProtocol，安全传输层协议——UDDI：UniversalDescription,DiscoveryandIntegration，统一描述、发现与集成——WS-CDL：WebServicesChoreographyDefinitionLanguage，Web服务编排定义语言——WSDL：WebServicesDescriptionLanguage，网页服务描述语言——WSDM：WebServicesDistributedManagement，分布式Web服务管理标准3DB5305/T19.28—2019——WSRP：WebServicesforRemotePortlets，远程门户网站Web服务——XML：ExtensibleMarkupLanguage，可扩展标识语言5系统集成体系5.1概述应用系统集成是保山市信息惠民工程项目建设重点工作，通过三个层次：门户集成、应用集成、数据集成的系统集成，形成“统一门户”、“多项应用”、“数据共享”的信息惠民应用系统集成体系。5.2系统集成原则5.2.1标准化原则应用系统集成应根据信息惠民工程建设情况，首先采用国家标准和国际标准，其次采用广为流行的、实用的行业标准、地方标准，充分保证未来扩展时的兼容性和采购来源的多样化。5.2.2开放性原则应用系统集成后，不能成为第N+1个系统，必须具有整体开放性和兼容性，能够适应未来不同的业务应用扩展和接入。5.2.3持续性原则信息惠民工程建设是一个持续发展的过程，在系统集成中必须充分考虑整体的扩展能力，既要保证每一阶段的建设需求，还要保证随着业务需求复杂度和需求量的剧增所带来的保障需求和压力。5.2.4SOA体系架构原则系统集成必须基于SOA体系架构，无论是门户集成、应用集成还是数据集成，均须基于SOA体系架构，由保山市大数据管理局统一规划系统集成的范围、集成的内容、集成的深度。5.2.5各司其职原则系统集成是多方共同参与才能完成的工作，需要参与各方明晰各自的职责，充分合作来共同完成集成。成5.2.6安全性原则在进行系统集成过程中需要作好安全措施，具体如下：——集成过程中，各方提供的用户名、密码、数据访问权限不得外泄、不得用于其他用途；——严格控制权限的授权和使用范围；——业务系统应该建立良好的数据备份机制，以预防意外情况。5.2.7减少运行影响原则在进行门户集成、应用集成、数据集成过程中会对现有业务系统产生一定的影响，具体情况如下：——测试期间：做好数据和系统备份，在非上班时间进行系统调试以减少对业务办理的影响；——系统试运行期间：支持并行运行，对业务系统无任何影响；——系统正式运行期间：对业务系统无任何影响。另外，由于历史数据不符合集成要求，将由保山市大数据管理局统一组织各业务部门进行数据初始化整理、必要的数据检查和修补，以确保数据质量。5.2.8计划性原则4DB5305/T19.28—2019每进行一项系统的集成，都必须事先经过策划，各方都需要做好人员与计划的准备工作。参与系统集成的各方均需要提供具体集成对接的实施详细计划。5.3系统集成架构5.3.1系统集成架构图系统集成体系架构见图1系统集成架构。1系统集成架构门户集成统一应用访问入口统一应用访问入口应用集成社会公共服务信息平台“社会公共服务信息平台网格化社会管理信息服务平台中网格化社会管理信息服务平台信息惠农综合服务平台智慧旅游综合服务平台信息惠农综合服务平台智慧旅游综合服务平台劳动就业社会保障服务平台信息惠民终端服务平台端到端的应用系统集成食品药品安全监督管理平台(市民)卡运营支撑管理平台……5.3.2门户集成门户集成，就是要建立信息惠民统一门户，打造信息惠民统一应用访问入口，使用信息惠民工程各类应用系统形成整体，进行业务处理和信息共享，打破信息化存在的“功能壁垒”和“信息壁垒”。信息惠民统一门户实现的功能见DB5305/T19.41-2019中的规定。——打破“功能壁垒”。在门户集成框架中将信息惠民应用系统中的功能重新组织，并借助权限管理将功能合理分配给相应的人员和角色，再借助单点登录功能实现一次登录多个业务系统同时使用，避免在多个业务系统中来回切换和账号维护。把不同软件系统中的功能组织在一起，让多个业务系统像一个系统一样工作。——打破“信息壁垒”。统一门户是信息惠民服务的窗口，借助统一门户把各类惠民服务平台形成集中服务，实现各服务平台见信息共享互通。——提供个性化应用。按照不同的用户、角色、权限，提供个性化的应用服务。5.3.3应用集成应用集成，是在门户集成基础上，对信息惠民工程所建设惠民服务平台，如社会公共服务信息平台、互联网+政务服务平台、网格化社会管理信息服务平台、信息惠农综合服务平台、智慧旅游综合服务平台、劳动就业社会保障服务平台、区域医疗卫生信息平台、食品药品安全监督管理平台、(市民)卡运营支撑管理平台、信息惠民终端服务平台等，进一步整合，实现信息惠民业务的流程再造，打造为一站式综合服务应用平台。5DB5305/T19.28—20196门户集成6.1门户集成概述信息惠民统一门户，不仅是应用统一访问入口，实现门户本身的功能，更是信息惠民的窗口，提供一站式的惠民办事服务，并提供跨部门、跨层级的的审批服务。因此，门户集成是信息惠民工程应用集成的战略和技术框架，它是位于各类信息惠民应用之上的窗口，以浏览器的方式向用户展现的应用信息，能有效的整合各类应用之间的缝隙，通过信息聚合功能，使用户自由地定制个性化的管理内容等。6.2统一用户认证集成6.2.1集成范围所有使用保山市信息惠民工程各类业务系统(B/S结构的业务系统)的系统用户，包括电子政务所有人员和单位申请人授权代理人都必须使用统一用户认证平台进行身份认证。新建信息惠民服务应用系统必须使用统一用户认证平台的身份认证，现有业务系统有条件的情况下进行系统改造来实现统一用户认证平台的身份认证。认证过程涉及权限管理与登录应按DB5305/T19.49-2019中的规定，涉及数字证书应用应按DB5305/T19.50-2019中的规定。6.2.2集成要求统一用户认证平台仅限于集成B/S结构系统。——信息惠民服务应用系统中的人员帐号信息必须与统一用户认证平台内人员身份帐号信息一致，如果不一致，则需要对该系统中人员帐号信息进行身份信息同步，以保证身份信息的一致性。用户身份信息通过自动同步实现，建成后无需人工干预。——原有信息惠民服务应用系统则根据保山市大数据管理局提供的接口规范、SSO实现技术，改造登录程序，实现统一认证。——信息惠民服务应用系统接入平台后，经统一的认证登录入口访问信息惠民统一门户；在信息惠民统一门户中，可以直接访问惠民服务应用系统，无需再次登录，实现“一站登录，全网漫游”。6.2.3集成方案集成方案的内容统一用户认证集成主要包括两方面内容：一是建立统一用户库中的人员帐号与信息惠民服务应用系统中的人员帐号一致；二是建立统一用户认证的机制，实现访问业务系统时的统一认证。用户信息同步用户身份信息统一汇总于身份帐号库后，流向集成业务系统的流程图如图2所示。612身份帐号库中间库认证用户信息库(LADP)4DB5305/T12身份帐号库中间库认证用户信息库(LADP)4图2身份信息流向图统一用户权限管理维维护组织和用户33同步身份帐号库同步OAMOAM认证管理根据惠民服务应用系统需要从中间库获取信息惠民服务应用获取信息惠民服务应用系统用系统业务库流程说明如下：——“统一用户权限管理”模块负责维护和管理保山市相关内部组织机构和人员信息，以及相关注册认证的群众、企业等信息，统一存放在身份帐号库；——身份帐号库，自动同步组织机构和人员信息到认证用户信息库；——身份帐号库，当身份账号库的信息发生变化，会自动以日志形式记录身份帐号库中间库，完成身份帐号信息同步；——身份帐号库中间库根据信息惠民服务应用系统要求，自动将组织机构和人员数据(即：身份帐号信息)从中间库抽取至信息惠民服务应用系统的业务库中，完成身份帐号信息同步。统一用户认证集成统一用户认证平台，提供了反向代理技术，实现信息惠民服务应用系统与统一用户认证平台的集成，此种集成采用松耦合的方式，是最优的集成方式。6.3门户内容集成6.3.1门户内容集成的方式信息惠民服务应用系统与信息惠民统一门户内容集成，可以采取页面引用、服务调用两种方式进行集成。6.3.2页面引用集成方案7C功能X功能应用一统一用户认证平台B功能Y功能应用二A功能Z功能应C功能X功能应用一统一用户认证平台B功能Y功能应用二A功能Z功能应用三页面引用集成方案指：信息惠民服务应用系统首先与统一用户认证平台集成，然后按照信息惠民统一门户界面标准进行页面风格的调整；信息惠民统一门户通过嵌套URL的方式引用信息惠民服务应用系统的功能点，这样用户登录信息惠民统一门户后就可以直接进行信息访问。如图3所示。图3页面应用集成方案示意图信息惠民服务应用信信息惠民服务应用6.3.3服务调用集成方案服务调用集成方案指：先由信息惠民服务应用系统将需要集成的业务功能WebService服务并注册到服务总线上；然后由信息惠民统一门户调用服务总线上的服务并通过Porlet进行展现。具体如图4所示。8A功能[URL]B功能[URL]C能[URL]应用三DB53A功能[URL]B功能[URL]C能[URL]应用三图4服务调用集成方案示意图服务总线信服务总线应用一应用二7应用集成7.1应用集成7.1.1应用集成概念应用集成就是建立一个统一的综合应用，也即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中，并使它们就像一个整体一样，进行业务处理和信息共享。应用集成由数据库、业务逻辑以及用户界面三个层次组成。它是一个面向用户的应用技术。目前被产业界公认的，解决应用集成的最佳方式是SOA。7.1.2SOASOA是英文词语"ServiceOrientedArchitecture"的缩写，指的是面向服务的架构。包含运行环境、编程模型、架构风格和相关方法论等在内的一套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模-开发-整合-部署-运行-管理。SOA架构带来的重要观点是业务驱动IT，即IT和业务更加紧密地对齐。以粗粒度的业务服务为基础来对业务建模，会产生更加简洁的业务和系统视图；以服务为基础来实现的IT系统更灵活、更易于重用、更好(也更快)地应对变化；以服务为基础，通过显式地定义、描述、实现和管理业务层次的粗粒度服务(包括业务流程)，提供了业务模型和相关IT实现之间更好的"可追溯性"，减小了它们之间的差距，使得业务的变化更容易传递到IT。因此，可以将SOA的主要优点概括为：IT能够更好更快地提供业务价值(BusinessCentric)、快速应变能力 (Flexibility)、重用(Reusability)。7.1.3基于SOA的应用集成基于SOA的应用集成，就是在保山市信息惠民工程项目建设中，利用SOA技术实现各信息惠民服务应用系统的集成，成为一个综合应用平台，实现跨部门、跨层级的快速协助、便捷处理的服务平台。7.2SOA应用集成服务总体规划9网页组件人机交互组件门户组件跨单位综合服务跨职能综合服务跨业务域综合服务流程服务人工交互流程服务流程引擎信息惠农网页组件人机交互组件门户组件跨单位综合服务跨职能综合服务跨业务域综合服务流程服务人工交互流程服务流程引擎信息惠农综合服务社会公共服务一站式政务服务数据聚合数据映射数据转换JDBC适配器核心数据数据仓库业务数据7.2.1SOA服务体系保山市信息惠民工程建设涉及的SOA架构之服务体系，应采用组件化的分层结构设计思想，使其具有预制性、封装性、透明性、互操作性、通用性等特征，便于快速地组装新的应用。上层的服务依赖于下层的服务来实现，而不需要了解下层的实现逻辑，通过服务的分层，降低服务之间的耦合度，提高可重用性。展现服展现服务层报表组件...综合服综合服务层...流程流程服务层流程监控...业务服务层智慧旅游综合服务...数据服数据服务层数据同步...访问服访问服务层消息打包...打包应用信息资源层非结构化数据SOA服务体系各层定义如下：——信息资源层：信息资源层为上层提供应用资源(应用系统模块)与数据资源，包括已经打包好的应用程序、地楼房核心数据库、业务系统数据库、数据仓库、非结构化数据等。——访问服务层：访问服务层实现与底层数据资源、应用资源的通信功能，使用通用标准接口，定义整合企业信息资源(数据资源与应用资源)的各种访问服务，例如：不同类型的适配器以及专用的API等。访问服务屏蔽了企业信息资源的技术和实现方式，访问服务层之上的开发者无需知道数据的位置、类型以及应用程序的编程语言等。——数据服务层：数据服务层定义的服务支持把异构的、孤立的企业数据转变成集成的、双向的、可重复使用的信息资源。数据服务通过访问服务层以统一的方式访问企业的所有数据，数据服务层之上的开发者可以集中精力处理数据的加工问题，而不必关注访问不同来源的数据的实现DB5305/T19.28—2019细节。——业务服务层：业务服务层定义那些可重用的业务处理过程，用于支持复合的业务处理需求。这层定义的业务处理过程服务可能是单个原子事务的无状态处理操作服务，也可能是多个业务应用或异步服务之间交互的有状态处理操作服务。业务服务层之上的开发者无需知道具体某项业务的逻辑处理过程。——流程服务层：业务流程是一组服务的集合，服务按照特定的顺序并使用一组特定的规则进行调用，其本身也可视为服务。流程服务层定义有状态的(长期运行或需要人工参与)、完整的业务流程。流程服务通过对下层的数据服务、业务服务的编排来实现，流程编排的规则在该层内定义。——综合服务层：综合服务层以提升企业综合管理职能、优化企业价值链为出发点，规划跨系统、跨业务管理职能域、跨单位的服务。综合服务层定义的服务是由下层的访问服务、数据服务、业务服务、流程服务组合而成的服务，通过服务的简单编排就可以快速搭建出新的业务应用系统。统——展现服务层：展现服务层定义企业信息门户中可配置、可重用的门户组件(Portlets)，与门集成相对应，用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件实现对不同客户接入方式的支持，并提供丰富的客户端展现方式。7.2.2SOA服务识别服务识别是指对业务进行分析和梳理，抽象出业务实现所需的服务，并按照SOA服务体系对服务进行合理划分。服务识别必须分析与业务功能或业务数据相关的接口以及约束该接口的契约，接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。服务识别考虑的因素服务识别基于应用需求来表达服务的需求，服务识别应包含但不限于下述考虑因素：——服务功能：满足企业当前及未来业务发展需求的业务处理与管理功能。——共享范围：跨企业级、企业级、业务职能域级或应用程序级；——可重用度：长期可重用、短期可重用或不可重用；——敏捷性：适应战略发展需求、适应业务发展需求；——可操作性：全部、部分功能已在应用系统中实现或需要重新开发；——开发技术：全部掌握、部分掌握或未掌握现有技术；——工具支持：现有工具全面支持、部分支持或不能支持；——项目规模：大规模、中等规模或小规模；——服务质量：容易实现或难以实现。服务识别涉及的内容服务识别应从业务的角度出发，包括但不限于下述切入点：——业务流程切入点：通过梳理、优化企业业务流程，将业务流程转化为可重用、更具有灵活性的流程服务。——信息资源切入点：通过梳理企业的数据资源环境，实现企业级数据交换与共享，为管理者提供各类企业经营管理信息。——用户体验切入点：关注客户体验需求，为终端用户提供增值、个性化、多渠道的服务，并据此来优化整合内部的应用和流程。7.2.3SOA服务定义服务定义是在服务识别的基础上定义服务的各项属性，描述服务的信息。服务的属性包括：基本属性、技术属性、安全属性、配置属性。服务的各项属性定义必须分阶段进行、逐步细化。服务识别阶段定义服务的基本属性；服务设计阶段定义服务的技术属性与安全属性；服务的部署阶段定义服务的配置属性。——服务的基本属性包括但不限于下述信息：DB5305/T19.28—2019序号属性说明取值说明1服务编码标识服务的唯一编码2服务英文名称服务的英文概要名称，描述应简洁准确如：CreateCustomer3服务中文名称服务的中文概要名称，描述应简洁准确如：获取楼信息5服务功能描述对服务功能规格的详细描述。如：获取某楼栋的详细信息。6服务开发单位实现服务的开发厂家——服务的技术属性包括但不限于下述信息：序号属性说明取值说明1版本号服务的版本号如：V1.02注册时间服务的正式注册时间如：2013-09-0110:003依赖的服务本服务需要调用的其它服务的编号列表如：服务编码1；服务编码2；4实现方式具体技术实现方式如：JAVA5服务类型属于服务体系中的哪种类型如：访问服务、数据服务、业务服务、流程服务等6交互属性是否需要人工交互是/否7服务调用方式客户端调用服务的具体方式如：服务同步调用、服务异步无返回调用、服务异步有返回调用8接口方法服务提供的接口方法列表如：Create()9接口协议调用服务的通讯协议如：http服务启用时间服务的正式启动时间如：2013-09-108:00服务停用时间服务的正式停用时间如：2018-09-3118:00——服务的安全属性包括但不限于下述信息：序号属性说明取值说明1安全要求调用服务时，是否需要进行安全认证是/否2允许调用的角色允许调用该服务的角色列表如：Operator；Manager3服务自行安全认证服务被调用时，是否还进行自身的安全认证是/否——服务的配置属性包括但不限于下述信息：DB5305/T19.28—2019序号属性说明取值说明1提供服务功能的网络IP地址如：2服务接口定义文件描述服务接口定义的文件路径如：http://webserver/CreateCustomer.wsdl3可以使用的时间可以使用该服务的时间段如：0：00－24：004是否支持重试服务调用失败后，是否支持重发调用是/否7.3SOA应用集成标准规范体系7.3.1概述根据保山市信息惠民工程建设总体要求，需要定义SOA服务开发与集成必须按的标准或规范，以保证信息惠民服务应用系统间共享服务的一致性和可重用性。SOA服务开发与集成技术标准规范的选择必须满足但不限于下述指导原则：——以WebService技术作为SOA服务开发技术的首选技术，并要求按WS-IBasicProfile1.0的有关指引；——以Java技术作为WebService开发的优先选择技术；——为了最大限度地复用现有应用系统的业务功能，在选择SOA技术标准规范时，必须考虑现有业务功能封装对技术标准规范的支持能力；——在选择SOA技术标准规范时，应重点定义“服务接口”和消息协议标准或规范，对服务内部功能实现所采用的技术标准规范可不加限制；——凡与SOA重用性密切相关的组件，如服务接口，必须采用成熟的技术标准规范；——对还没有最后定案的事实标准或规范(这类标准通常不是被所有软件平台和开发商支持，或者还不是很成熟，或者产品的支持与产品之间的兼容性差)，作为可选技术参考使用；——为了充分利用企业现有的IT资产，降低开发难度和成本，可以考虑采用现有系统已经支持或采用的技术标准规范；——业务系统开发商目前熟悉并掌握的技术标准规范也可作为选用依据之一，SOA服务的实现通常限制采用何种技术，因此，服务的“实现”可采用业务系统开发商目前熟悉的技术或规范开发。7.3.2技术标准规范体系图SOA技术标准规范体系图SOA架构体系各层以及层与层之间必须按相关的技术标准规范，这些标准规范包括：访问服务、数据服务、业务服务、流程服务、展现服务的技术标准规范，以及贯穿各层之间的消息交换、消息传输、安全管理、服务描述、注册与发现等技术标准规范。SOA技术标准规范体系如图6SOA技术标准规范体系图所示。消息传输(HTTP/S、RMI、JMS、FTP消息消息传输(HTTP/S、RMI、JMS、FTP消息交换(XML，XMLSchema、SOASDO安全管理(WSDM，SSL/TSL，WS-系)展现服务(JSR186、WSRP、HTML、JSP、AJAX)综合服务(BPEL、BPMN、WS-CDL)流程服务(BPEL、BPMN)业务服务(EJB、SCA)数据服务(JDBC、Xquery)图6SOA技术标准规范体系图服务描注册与发现(WSDL，UDDSOA技术标准规范体系说明SOA技术标准规范体系说明：——访问服务。JCA(JavaConnectorArchitecture)：JCA定义了一套标准的接口，用于让连接器把兼容的应用程序服务器无缝地整合起来，以及提供标准接口允许客户(或者应用程序服务器的应用程序主机)用一种统一的方法使用连接器。JDBC(JavaDataBaseConnectivity，java数据库连接)：JDBC是一种用于执行SQL语句的JavaAPI，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC为程序开发提供标准的接口，API(ApplicationProgrammingInterface)：专用API是针对某个具体软件产品(例如：LoutsNotes、SAP)提供的编程接口。——数据服务。XQuery(XMLQuery)：XQuery是W3C所制定的一套标准，用来从类XML文档中提取信息，类XML文档可以理解成一切符合XML数据模型和接口的实体，他们可能是文件或关系型数据库。——业务服务。SCA(ServiceComponentArchitecture)：SCA即服务组件架构，它提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA支持实现服务组件的各种技术及连接服务组件的各种存取方法。EJB(EnterpriseJavaBean)：EJB是一个可重用的，可移植的J2EE组件。EJB由封装了业务逻辑的多个方法组成。EJB运行在一个容器里，多个远程和本地客户端可以调用这个方法，允许开发者只关注与bean中的业务逻辑而不用考虑事务支持、安全性和远程对象访问等复杂和容易出错的事情。——流程服务。BPMN(BusinessProcessModelingNotation)：BPMN是一个业务流程建模和Web服务标准，其首要目标是提供一个通俗易懂的标注体系，另外一个重要目标是提供内部模型，便于下一代XML语言对业务流程的执行。BPEL(BusinessProcessExecutionLanguage)：BPEL也被称为BPELWS或BPEL4WS(Web服务业务流程执行语言)。它是一种可执行语言，能够与各种业务流程自动化的软件系统相兼容，通过说明性的方式(而不是编程的方式)表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，BPM产品基于此规范实现。WS-CDL(WebServicesChoreographyDefinitionLanguage)：WS-CDL即Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点(endpoints)都有Web服务基础设施。此规范更多地用于组织之外的服务流程编排。——展现服务。JSR168(JavaSpecificationRequest168)：JSR168是java规范要求，主要应用在Portal软件的开发。它为创建Portlet建立标准的API，它是为实现porltet、基于javaDB5305/T19.28—2019的门户服务器和其它web应用程序之间的互操作性而设计的。WSRP(WebServicesforRemotePortlets，远程门户网站Web服务)：WSRP定义了如何利用基于SOAP的Web服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP允许门户在它们的页面中显示远程运行的Portlet，而不需要门户开发人员进行任何编程。WSRP是由OASIS组织制定的。HTML(HyperTextMark-upLanguage)：HTML即超文本标记语言或超文本链接标示语言，是WWW的描述语言。JSP(JavaServerPages)：JSP是一种动态网页技术标准，JSP将网页逻辑与网页设计和显示分离，由HTML代码和嵌入其中的Java代码所组成，支持可重用的基于组件的设计。JSP页面是跨平台的，即能在Windows下运行，也能在Linux等其它操作系统上运行。AJAX (AsynchronousJavaScriptandXML)：AJAX是一种创建交互式网页应用的网页开发技术。AJAX仅向服务器发送并取回必需的数据，它使用SOAP或其它一些基于XML的webservice接口，并在客户端采用JavaScript处理来自服务器的响应。——消息传输。HTTP(HypertextTransferProtocol)：HTTP即超文本传输协议是用于从Web服务器传输超文本到本地浏览器的传送协议。HTTPS(SecureHypertextTransferProtocol)，又MethodInvocation)：RMI即远程对象访问传输协议，用于JAVAEJB对象之间通信。JMS(JavaMessagingService)：JMS是Java平台上有关面向消息中间件的技术规范，用于和面向消息的中间件相互通信的应用程序接口。FTP(FileTransferProtocol)：FTP是文件传输协议的简称，用于Internet上的文件的双向传输。——消息交换。XML(ExtensibleMarkupLanguage)：XML即扩展标识语言。是通用标识语言标准(SGML)的一个子集，是描述网络上的数据内容和结构的标准。XMLSchema：XMLSchema为XML文档提供明确的语义限制，确保每一个XML文档都是结构完整、语义合法、内容有效的。SOAP (SimpleObjectAccessProtocol)：SOAP即简单对象访问协议，是基于XML的在分布式的环境中交换信息的简单的协议。SDO(ServiceDataObject)：SDO即服务数据对象，是一种针对在不同的数据源之间使用统一的数据编程模型的规范说明。它统一和简化了应用程序处理数据的方式，是服务及组件之间传输的标准数据格式。使用SDO，应用编程人员可以用一致的方法操作异构数据源，包括系型数据库，XML数据源，Webservices和企业信息系统。WS-Addressing：WS-Addressing规范定义了一种将消息寻址信息综合到Webservices消息中的标准。WS-Addressing为以同步和/或异步方式传输的SOAP消息提供了一种统一的寻址方法。此外，它还提供了寻址功能来帮助Webservice开发人员在请求和响应的典型交换之外，围绕各种消息传递模式构建应用程序。WS-ReliableMessaging：WS-ReliableMessaging规范定义了一种协议和一套机制，使Web服务的开发人员能够确保在两个端点之间可靠地传递消息，该规范还具有各种传递保证和健壮性特征。——安全管理。WSDM(WebServicesDistributedManagement)：WSDM即分布式Web服务管理标准WSDM由两个不同的标准组成的：使用Web服务的管理(WSDM-MUWS)与Web服务的管理(WSDM-MOWS)。WSDM-MUWS提供了如何表示和访问MUWS资源的接口的定义。例如，MUWS标准提供了用于公布服务、服务功能所必需的结构、以及管理资源所需要提供和接收的信息。WSDM-MOWS提供了管理Web服务的定义。MOWS使用了许多由MUWS标准定义的概念和系统，同时也添加了管理Web服务特别需要的资源和功能。MOWS组件提供了支持远程管理Web服务的方法和系统。WS-Management：WS-Management定义了企业级SOA平台统一的管理接口，让不同企业级SOA平台可以被任何符合标准的管理界面操作。WS-Security：WS-Security描述通过消息完整性、消息机密性和单独消息认证，提供保护质量的SOAP消息传递增强。这些机制可以用于提供多种安全模型和加密技术。它是构建在现有安全技术的基础之上的，提供一esWSPolicyWebServicesPolicyFrameworkWeb服务策略框架规范提供了一种灵活、可扩展的语法，用于表示基于XMLWebservices的系统中实体的能力、要求和一般特性。WS-Policy定义了一个框架和一个模型，将这些特性表示为策略。WS-PolicyAttachment：WS-PolicyAttachment为通过现有的XMLWeb服务技术使用策略表达式指定了三个特定的附件机制。包括：如何从WSDL定义中引用策略；如何将策略与部署的Web服务端点关联起来；如何将策略与UDDI实体关联起来。WS-Trust：WS-Trust使用WS-Security安全的消息传递机制为安全性令牌交换定义额外的原语和扩展，以使得凭证能够在不同的信任域中签发和传播。SSL/TLS：SSL/TLS利用密钥算法在互联网上提供端点身分类标准/规范必要性用法用于集成现有J2EE应用系统，在不能JCA1.5或以上版本分类标准/规范必要性用法用于集成现有J2EE应用系统，在不能JCA1.5或以上版本可选提供基于Webservice的适配器的情况下，可考虑采用JCA。访问服务JDBC2.0或以上版本推荐用于后台数据库的访问。数据服务可以向消费者提供JDBC和Webservice两种形式的接口JDBC应份认证与通讯保密，其基础是公钥基础设施(PKI)。——服务描述、注册与发现。WSDL(WebServicesDescriptionLanguage)：WSDL即Web服务描述消息(Message)、方法(Operation)和访问端口(PortType)。WSDL只提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。UDDI(UniversalDescriptionDiscoveryandIntegration)：UDDI注册内容包括Web服务的技术模型和业务模型，本身可Web查找。SOA技术标准规范成熟度说明SOA架构技术标准规范按技术的成熟度区分如下：——必须，已经获得相关国际组织批准，而必须按的标准；——推荐，虽未获得相关国际组织批准，但已经是成熟的标准；——可选，处在标准草案阶段，在主流平台产品中没有得到广泛的应用，但在SOA中有其技术优势，在特定情况下才可采用。6.3.3服务开发技术标准规范SOA服务各层的开发技术应按技术规范如表1所示。表1SOA服务各层的开发技术规范数据服务JDBC2.0或以上版本推荐。局限于和BI应用系统进行互联的数据服务接口。XQuery1.0或以上版本必须用于查询以XML形式表达的数据。业务服务SCA1.0或以上版本推荐用于服务封装与组装。SCA提供了一种统一的面向服务组件的调用方式，从而使得客户可以把不同的软件模块通过服务组件的标准化而统一地封装起来和被调用访问。EJB3.0或以上版本可选在Webservice接口不能满足业务要求的情况下，对于J2EE平台，EJB是一种可选方案。流程服务BPMN2.0或以上版本推荐用于流程设计，它提供了设计和绘制业务流程图所需的标准符号。提供业务流程设计环境的流程建模工具，应支持该标准。WSBPEL上版本推荐用于流程引擎。DB5305/T19.28—2019表1SOA服务各层的开发技术规范(续)分类标准/规范必要性用法综合服务BPMN2.0或以上版本推荐用于流程设计，它提供了设计和绘制业务流程图所需的标准符号。提供业务流程设计环境的流程建模工具，应支持该标准。WSBPEL上版本推荐用于流程引擎。WS-CDL1.0或以上版本可选用于跨多个(三个及以上)单位间的流程服务编排展现服务WSRP1.0或以上版本推荐在Web门户中用于访问和显示驻留在准。它是唯一成熟的用于展现服务的技术协议，同时也被业界广泛支持。JSR168推荐letHTML推荐JSP推荐AJAX推荐服务描述、现UDDI2.0或以上版本必须该标准描述了服务注册的数据模型以及访问模型的API。它不仅仅用于Webservice，也可以用于其它类型的服务。UDDI是服务注册这一领域目前唯一成熟并被广泛支持的技术标准。WSDL1.1或以上版本必须WSDL用于描述Webservice接口。它是唯一成熟的，并受到广泛支持的Webservice接口标准。在使用SOAP-basedWebservice时，必须使用这一标准。消息交换XML1.1或以上版本必须bserviceXML择。在其它形式的数据交换场合，它也是最适宜的。XMLSchema1.1或以上版本必须的，并且SOAP中任何的类型的定义也是使用XMLSchema的，所以采用XMLSchema是最合理的选择。在其它形式的数据交换场合，它也是最适宜的。SOAP1.1或以上版本必须SOAP是Webservice调用过程中的标准编码协议。它被业界绝大多数主流厂商和工具所支持，也被不同的平台支。当然，考虑到兼容性，SOAP消息不应采用RPC-oriented和SOAPencoding，WSDL内的SOAP绑定只可采用document/literalstyle。当采用HTTP协议作SOAP的传输时，SOAP错误消息应采用HTTP500状态返回。DB5305/T19.28—2019表1SOA服务各层的开发技术规范(续)分类标准/规范必要性用法WSAddressing上版本可选用于Webservice的传输透明寻址能了如何在SOAPheader中定义各种类型的地址。WS-ReliableMessaging本可选该标准用于保证在webservice的消费者和提供者之间“可靠地”进行数据交换。WS-ReliableMessaging虽然现在还不完全是一个成熟的标准，但它对消息传递的可靠性作出了一个全面的支持架构，当中包括了「最少一次」 (Exactly-once)的语义。SDO2.1或以上版本推荐用于定义服务及组件之间传输的标准数据格式。SDO则作为一种数据编程架构和API，它统一了不同数据源类型的数据编程，让开发人员可以以统一的方式访问和操作不同的数据源。EJB3.0或以上版本可选在Webservice接口不能满足业务要求的情况下，对于J2EE平台，EJB是一种可选方案。消息传输HTTP/S必须eHTTPS作为指定的传输协议。HTTPSOAP消息传输JMS可选在异步模式下，可采用JMS为标准RMI可选RMI-JRMP或RMI-IIOP。FTP可选在传输大文件时，考虑到执行效率，可安全管理WSDM1.1或以上版本可选WSDM标准实际上是由两个不同的标准组成的：使用Web服务的管理(WSDM-MUWS)；Web服务的管理(WSDM-MOWS)。MUWS资源的接口的定义。例如，MUWS标准提供了用于公布服务、服务功能所必需的结构、以及管理资源所需要提供和接收的信息。WSDM-MOWS提供了管理Web服务的定义。MOWS使用了许多由MUWS标准定义的概念和系统，同时也添加了管理Web服务特别需要的资源和功能。MOWS组件提供了支持远程管理Web服务的方法和系统。安需求，应使用标准。用于SOAP-based安需求，应使用标准。用于SOAP-basedWebservice的消息层安全。它是WS-Security的扩展，推荐定义了一个用于请求和发布安全令牌的框架，并可以代理信任关系。它是此领域唯一成熟的标准。WS-Trust1.3或以上版本表1SOA服务各层的开发技术规范(续)分类标准/规范必要性用法LTLS上版本必须用于保障HTTP通信安全的协议。它可保证两端点间通信的保密性和完整性。它可以用于SOAPoverHTTP通信安全它HTTP-based通信安全。目前还没有其它更为合适的用于传输层安全的协议。在描述和沟通webservice安全规则在描述和沟通webservice安全规则时，该标准提供了通用的目的模型和相应的语法。它是在定义webservice安全需求时可用的唯一成熟标准.。它提供了将主体以及应用其上的安全规则进行关联的机制，同时它也提供了关联的机制。如果希望使用WS-Policy定义一个SOAP-basedWebservice的全该WSPolicy上版本WS-PolicyAttachment本推荐推荐上版本必须在Webservice调用过程中，该标准是保证信息层安全的最佳选择.它描何强化SOAP消息，以提供消息的完整性和机密性。同时，它还提供了将安全令牌与消息内容相关联的机制。消息层安全比传输层安全提供了更多的安全选择。加密与签名等安全措施可以被应用于任意的消息元素，消息层安全可以提供真正的“端到端”安全。6.3.4服务集成技术标准规范SOA各服务层之间的相互调用应按的技术标准规范如表2所示。表2SOA各服务层之间的相互调用应按的技术标准规范服务层标准/规范必要性用法访问服务SOAP-basedWebServices推荐Webservice是首选接口，并支持WSDL1.1。即使是异步服务，也应选择使用Webservice，此时它返回空结果。EJB可选在webservices不能满足业务要求时使用。当后端系统已经给消费者提供了EJB服务，并且证明使用web-service封装会严重损害性能，此时，使用EJB。推荐的异步模式(即不立即返回结果)。如果评估WebServices不能满足业务要求，则考虑使用JMS。JMS业务流程设计工具应当支持BPMN标准，用于描述业务流程。推荐BPMN流程服务流程服务的实现是在流程引擎上完成的，所以以推荐的异步模式(即不立即返回结果)。如果评估WebServices不能满足业务要求，则考虑使用JMS。JMS业务流程设计工具应当支持BPMN标准，用于描述业务流程。推荐BPMN流程服务流程服务的实现是在流程引擎上完成的，所以以BPEL标准输入流程定义是首选方案。推荐WS-BPEL业务流程设计工具应当支持BPMN标准，用于描述业务流程。推荐BPMN流程服务的实现是在流程引擎上完成的，所以以BPEL标准输入流程定义是首选方案。综合服务WS-BPEL推荐WS-CDL可选跨单位的流程服务编排。展现服务WSRP推荐远程Portlet开放的接口应按WSRP标准。表2SOA各服务层之间的相互调用应按的技术标准规范(续)服务层标准/规范必要性用法JMS可选如果服务是异步调用的，首选是使用WebServices的异步模式(即不立即返回结果)。如果评估WebServices不能满足业务要求，则考虑使用JMS。当后端系统已经给消费者提供了JMS服务，此时，可以直接使用JMS。FTP可选传输大文件时使用数据服务JDBC推荐数据服务应支持通过JDBC接口查询数据，主要的SOAP-basedWebServices推荐数据服务首先应提供SOAP-basedWebServices接，并支持WSDL1.1。业务服务SOAP-basedWebServices推荐如果服务是同步调用的，它应该提供WebServices接口，并支持WSDL11。如果服务是异步调用的，首选是使用WebServices7数据集成7.1数据集成概念数据集成就是将若干个分散的数据源中的数据，逻辑地或物理地集成到一个统一的数据集合中。数据集成的核心任务是要将互相关联的分布式异构数据源集成到一起，使用户能够以透明的方式访问这些数据源。集成是指维护数据源整体上的数据一致性、提高信息共享利用的效率；透明的方式是指用户无需关心如何实现对异构数据源数据的访问，只关心以何种方式访问何种数据。7.2数据集成分类数据集成可以分为基本数据集成、多级视图集成、模式集成、多粒度数据集成4个层次。7.3基本数据集成基本数据集成面临的问题很多。由于同一业务实体存在于多个系统源中，并且没有明确的办法确认这些实体是同一实体时，就会产生这类问题。处理该问题的办法如下。——隔离，保证实体的每次出现都指派一个唯一标识符；——调和，确认哪些实体是相同的，并且将该实体的各次出现合并起来。20DB5305/T19.28—20197.4多级视图集成多级视图机制有助于对数据源之间的关系进行集成：底层数据表示方式为局部模型的局部格式，如关系和文件；中间数据表示为公共模式格式，如扩展关系模型或对象模型；高级数据表示为综合模型格式，视图的集成化过程为两级映射。——数据从局部数据库中，经过数据翻译、转换并集成为符合公共模型格式的中间视图。——进行语义冲突消除、数据集成和数据导出处理，将中间视图集成为综合视图。7.5模式集成模型合并属于数据库设计问题，其设计的好坏常视设计者的经验而定，在实际应用中很少有成熟的理论指导。实际应用中，数据源的模式集成和数据库设计仍有相当的差距，如模式集成时出现的命名、单位、结构和抽象层次等冲突问题，就无法照搬模式设计的经验。在众多互操作系统中，模式集成的基本框架如属性等价、关联等价和类等价可最终归于属性等价。7.6多粒度数据集成多粒度数据集成是异构数据集成中最难处理的问题，理想的多粒度数据集成模式是自动逐步抽象。数据综合(或数据抽象)指由高精度数据经过抽象形成精度较低、但是粒度较大的数据。其作用过程为从多个较高精度的局部数据中，获得较低精度的全局数据。在这个过程中，要对各局域中的数据进行综合，提取其主要特征。数据综合集成的过程实际上是特征提取和归并的过程。数据细化指通过由一定精度的数据获取精度较高的数据，实现该过程的主要途径有：时空转换，相关分析或者由综合中数据变动的记录进行恢复。数据集成是最终实现数据共享和辅助决策的基础。7.7数据集成方法保山市信息惠民工程系统集成的数据集成应采用基于S0A技术的中间件集成方法。中间件集成方法是目前比较流行的数据集成方法，中间件模式通过统一的全局数据模型来访问异构的数据库、遗留系统、Web资源等。中间件位于异构数据源系统(数据层)和应用程序(应用层)之间，向下协调各数据源系统，向上为访问集成数据的应用提供统一数据模式和数据访问的通用接口。各数据源的应用仍然完成它们的任务，中间件系统则主要集中为异构数据源提供一个高层次检索服务。它同样使用全局数据模式，通过在中间层提供一个统一的数据逻辑视图来隐藏底层的数据细节，使得用户可以把集成数据源看为一个统一的整体。8系统集成接口规范8.1基本原则为了保证系统的完整性和健壮性，保山市信息惠民工程项目在建设过程中，系统集成接口应满足下列基本原则：——接口应实现对外部系统的接入提供企业级的支持，在系统的高并发和大容量的基础上提供安全可靠的接入；——提供完善的信息安全机制，以实现对信息的全面保护，保证系统的正常运行，应防止大量访问，以及大量占用资源的情况发生，保证系统的健壮性；——提供有效的系统的可监控机制，使得接口的运行情况可监控，便于及时发现错误及排除故障；——保证在充分利用系统资源的前提下，实现系统平滑的移植和扩展，同时在系统并发增加时提供系统资源的动态扩展，以保证系统的稳定性；——在进行扩容、新业务扩展时，应能提供快速、方便和准确的实现方式。8.2接口通讯方式接口基本采用了同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等通讯方式：21DB5305/T19.28—2019——同步请求/应答方式：客户端向服务器端发送服务请求，客户端阻塞等待服务器端返回处理结——异步请求/应答方式：客户端向服务器端发送服务请求，与同步方式不同的是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果；——会话方式：客户端与服务器端建立连接后，可以多次发送或接收数据，同时存储信息的上下文关系；——广播通知方式：由服务器端主动向客户端以单个或批量方式发出未经客户端请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作；——事件订阅方式：客户端可事先向服务器端订阅自定义的事件，当这些事件发生时，服务器端通知客户端事件发生，客户端可采取相应处理。事件订阅方式使客户端拥有了个性化的事件触发功能，极大方便了客户端及时响应所订阅的事件；——文件传输：客户端和服务器端通过文件的方式来传输消息，并采取相应处理；——可靠消息传输：在接口通讯中，基于消息的传输处理方式，除了可采用以上几种通讯方式外，还可采用可靠消息传输方式，即通过存储队列方式，客户端和服务器端来传输消息，采取相应处理。8.3集成接口安全要求集成接口安全要求：——为了保证系统的安全运行，各种接口方式都应该保证其接入的安全性；——接口的安全是系统安全的一个重要组成部分。保证接口的自身安全，通过接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是实现系统安全的一个重要基础；——根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的数据传输和数据处理的安全性；——系统应在接入点的网络边界实施接口安全控制；——接口的安全控制在逻辑上包括：安全评估、访问控制、入侵检测、口令认证、安全审计、防恶意代码、加密等内容。8.4传输控制要求传输控制利用高速数据通道技术实现把前端的大数据量并发请求分发到后端，从而保证应用系统在大量客户端同时请求服务时，能够保持快速、稳定的工作状态。系统应采用传输控制手段降低接口网络负担，提高接口吞吐能力，保证系统的整体处理能力。具体手段包括负载均衡、伸缩性与动态配置管理、网络调度等功能。——负载均衡：为了确保接口服务吞吐量最大，接口应自动地在系统中完成动态负载均衡调度；——伸缩性与动态配置管理：由系统自动伸缩管理方式或动态配置管理方式实现队列管理、存取资源管理，以及接口应用的恢复处理等；——网络调度：在双方接口之间设置多个网络通道，实现接口的多数据通道和容错性，保证当有一网络通道通讯失败时，进行自动的切换，实现接口连接的自动恢复。8.5集成接口技术8.5.1J2EE/EJB技术描述EnterpriseJavaBean(EJB)是可重用的、可移植的J2EE组件。EJB包括三种主要类型：会话bean、实体bean和消息驱动的bean。会话bean执行独立的、解除耦合的任务，譬如检查客户的信用记录。实体bean是一个复杂的业务实体，它代表数据库中存在的业务对象。消息驱动的bean用于接收异步JMS消息。EJB由封装业务逻辑的方法组成，众多远程和本地客户端可以调用这些方法。另外，EJB在容器里运行，这样开发人员只要关注bean里面的业务逻辑，不必担心复杂、容易出错的问题，22DB5305/T19.28—2019譬如事务支持、安全性和远程对象访问、高速缓存和并发等。在EJB规范中，这些特性和功能由EJB容器负责实现。容器和服务提供者实现了EJB的基础构造，这些基础构造处理了EJB的分布式、事务管理、安全性等内容。EJB规范定义了基础构造和JavaAPI的为了适应各种情况的要求，而没有指定具体实现的技术、平台、协议。EJB的上层的分布式应用程序是基于对象组件模型的，低层的事务服务用了API技术。EJB技术简化了用JAVA语言编写的企业应用系统的开发、配置和执行。技术特点技术特点:——优点,基于规范的平台，不受限于特定的操作系统或硬件平台；基于组件体系结构，简化了复杂组件的开发；提供对事务安全性以及持续性的支持；支持多种中间件技术。——缺点,与特定于某个操作系统或平台的实现技术相比，性能还有待进一步提高，且资源占用量较大。8.5.2WebService技术描述WebService是一种自包含、模块化的应用，是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使WebService能与其它兼容的组件进行互操作。可以在网络上(一般是Internet)上被描述、发布、定位和调用。WebService体系主要由以下三部分组成：传输协议、服务描述和服务发现，由一系列标准组成，主要有：XML(可扩展的标记语言)、SOAP(简单对象访问协议)等。技术特点WebService使用标准技术，应用程序资源在各网络上均可用。因为WebService基于HTTP、XML和SOAP等标准协议，所以即使以不同的语言编写并且在不同的操作系统上运行，它们也可以进行通信。因此，WebService适用于网络上不同系统的分布式应用。优点：适用于网络上不同系统的分布式应用、标准性好、扩展性好、耦合度低；内容由标准文本组成，任何平台和程序语言都可以使用；格式的转换基本不受限制，可以满足不同应用系统的需求。缺点：当XML内容较大时，解释程序的执行效率较低，一般不适合用于实现大批量数据交互的接口。8.5.3消息中间件技术描述基于消息中间件的接口机制主要通过消息传递来完成系统之间的协作和通信。通过消息中间件把应用扩展到不同的操作系统和不同的网络环境。通过使用可靠的消息队列，提供支持消息传递所需的目录、安全和管理服务。当一个事件发生时，消息中间件通知服务方应该进行何种操作。其核心安装在需要进行消息传递的系统上，在它们之间建立逻辑通道，由消息中间件实现消息发送。消息中间件可以支持同步方式和异步方式，实际上是一种点到点的机制，因而可以很好的适用于面向对象的编程方式。消息中间件可以保证消息包传输过程的正确、可靠和及时。消息中间件提供以下基本功能：消息队列、触发器、信息传递、数据格式翻译、安全性控制、数据广播、错误恢复、资源定位、消息及请求的优先级设定、扩展的调试功能等。技术特点消息中间件能够在任何时刻将消息进行传送或者存储转发，不会占用大量的网络带宽，可以跟踪事务，并且通过将事务存储到磁盘上实现网络故障时系统的恢复。优点：为不同的企业应用系统提供了跨多平台的消息传输；除支持同步传输模式外，还支持异步传输，有助于在应用间可靠地进行消息传输。