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結構系統。——信息惠民服務應用系統中的人員帳號信息必須與統一用戶認證平臺內人員身份帳號信息一致，如果不一致，則需要對該系統中人員帳號信息進行身份信息同步，以保證身份信息的一致性。用戶身份信息通過自動同步實現，建成后無需人工干預?！行畔⒒菝穹諔孟到y則根據保山市大數據管理局提供的接口規范、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服務體系各層定義如下：——信息資源層：信息資源層為上層提供應用資源(應用系統模塊)與數據資源，包括已經打包好的應用程序、地樓房核心數據庫、業務系統數據庫、數據倉庫、非結構化數據等?！L問服務層：訪問服務層實現與底層數據資源、應用資源的通信功能，使用通用標準接口，定義整合企業信息資源(數據資源與應用資源)的各種訪問服務，例如：不同類型的適配器以及專用的API等。訪問服務屏蔽了企業信息資源的技術和實現方式，訪問服務層之上的開發者無需知道數據的位置、類型以及應用程序的編程語言等。——數據服務層：數據服務層定義的服務支持把異構的、孤立的企業數據轉變成集成的、雙向的、可重復使用的信息資源。數據服務通過訪問服務層以統一的方式訪問企業的所有數據，數據服務層之上的開發者可以集中精力處理數據的加工問題，而不必關注訪問不同來源的數據的實現DB5305/T19.28—2019細節?！獦I務服務層：業務服務層定義那些可重用的業務處理過程，用于支持復合的業務處理需求。這層定義的業務處理過程服務可能是單個原子事務的無狀態處理操作服務，也可能是多個業務應用或異步服務之間交互的有狀態處理操作服務。業務服務層之上的開發者無需知道具體某項業務的邏輯處理過程。——流程服務層：業務流程是一組服務的集合，服務按照特定的順序并使用一組特定的規則進行調用，其本身也可視為服務。流程服務層定義有狀態的(長期運行或需要人工參與)、完整的業務流程。流程服務通過對下層的數據服務、業務服務的編排來實現，流程編排的規則在該層內定義?！C合服務層：綜合服務層以提升企業綜合管理職能、優化企業價值鏈為出發點，規劃跨系統、跨業務管理職能域、跨單位的服務。綜合服務層定義的服務是由下層的訪問服務、數據服務、業務服務、流程服務組合而成的服務，通過服務的簡單編排就可以快速搭建出新的業務應用系統。統——展現服務層：展現服務層定義企業信息門戶中可配置、可重用的門戶組件(Portlets)，與門集成相對應，用于支持門戶應用的開發；以及人機交互組件、網頁組件、報表組件實現對不同客戶接入方式的支持，并提供豐富的客戶端展現方式。7.2.2SOA服務識別服務識別是指對業務進行分析和梳理，抽象出業務實現所需的服務，并按照SOA服務體系對服務進行合理劃分。服務識別必須分析與業務功能或業務數據相關的接口以及約束該接口的契約，接口和契約采用中立、基于標準的方式進行定義，它獨立于實現服務的硬件平臺、操作系統和編程語言。服務識別考慮的因素服務識別基于應用需求來表達服務的需求，服務識別應包含但不限于下述考慮因素：——服務功能：滿足企業當前及未來業務發展需求的業務處理與管理功能?！蚕矸秶嚎缙髽I級、企業級、業務職能域級或應用程序級；——可重用度：長期可重用、短期可重用或不可重用；——敏捷性：適應戰略發展需求、適應業務發展需求；——可操作性：全部、部分功能已在應用系統中實現或需要重新開發；——開發技術：全部掌握、部分掌握或未掌握現有技術；——工具支持：現有工具全面支持、部分支持或不能支持；——項目規模：大規模、中等規模或小規模；——服務質量：容易實現或難以實現。服務識別涉及的內容服務識別應從業務的角度出發，包括但不限于下述切入點：——業務流程切入點：通過梳理、優化企業業務流程，將業務流程轉化為可重用、更具有靈活性的流程服務。——信息資源切入點：通過梳理企業的數據資源環境，實現企業級數據交換與共享，為管理者提供各類企業經營管理信息。——用戶體驗切入點：關注客戶體驗需求，為終端用戶提供增值、個性化、多渠道的服務，并據此來優化整合內部的應用和流程。7.2.3SOA服務定義服務定義是在服務識別的基礎上定義服務的各項屬性，描述服務的信息。服務的屬性包括：基本屬性、技術屬性、安全屬性、配置屬性。服務的各項屬性定義必須分階段進行、逐步細化。服務識別階段定義服務的基本屬性；服務設計階段定義服務的技術屬性與安全屬性；服務的部署階段定義服務的配置屬性?！盏幕緦傩园ǖ幌抻谙率鲂畔ⅲ篋B5305/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數據模型和接口的實體，他們可能是文件或關系型數據庫?！獦I務服務。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服務基礎設施。此規范更多地用于組織之外的服務流程編排?！宫F服務。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上的文件的雙向傳輸?！⒔粨Q。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)?！彰枋觥⒆耘c發現。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基本數據集成基本數據集成面臨的問題很多。由于同一業務實體存在于多個系統源中，并且沒有明確的辦法確認這些實體是同一實體時，就會產生這類問題。處理該問題的辦法如下?！綦x，保證實體的每次出現都指派一個唯一標識符；——調和，確認哪些實體是相同的，并且將該實體的各次出現合并起來。20DB5305/T19.28—20197.4多級視圖集成多級視圖機制有助于對數據源之間的關系進行集成：底層數據表示方式為局部模型的局部格式，如關系和文件；中間數據表示為公共模式格式，如擴展關系模型或對象模型；高級數據表示為綜合模型格式，視圖的集成化過程為兩級映射。——數據從局部數據庫中，經過數據翻譯、轉換并集成為符合公共模型格式的中間視圖?！M行語義沖突消除、數據集成和數據導出處理，將中間視圖集成為綜合視圖。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語言編寫的企業應用系統的開發、配置和執行。技術特點技術特點:——優點,基于規范的平臺，不受限于特定的操作系統或硬件平臺；基于組件體系結構，簡化了復雜組件的開發；提供對事務安全性以及持續性的支持；支持多種中間件技術?！秉c,與特定于某個操作系統或平臺的實現技術相比，性能還有待進一步提高，且資源占用量較大。8.5.2WebService技術描述WebService是一種自包含、模塊化的應用，是基于網絡的、分布式的模塊化組件，它執行特定的任務，遵守具體的技術規范，這些規范使WebService能與其它兼容的組件進行互操作。可以在網絡上(一般是Internet)上被描述、發布、定位和調用。WebService體系主要由以下三部分組成：傳輸協議、服務描述和服務發現，由一系列標準組成，主要有：XML(可擴展的標記語言)、SOAP(簡單對象訪問協議)等。技術特點WebService使用標準技術，應用程序資源在各網絡上均可用。因為WebService基于HTTP、XML和SOAP等標準協議，所以即使以不同的語言編寫并且在不同的操作系統上運行，它們也可以進行通信。因此，WebService適用于網絡上不同系統的分布式應用。優點：適用于網絡上不同系統的分布式應用、標準性好、擴展性好、耦合度低；內容由標準文本組成，任何平臺和程序語言都可以使用；格式的轉換基本不受限制，可以滿足不同應用系統的需求。缺點：當XML內容較大時，解釋程序的執行效率較低，一般不適合用于實現大批量數據交互的接口。8.5.3消息中間件技術描述基于消息中間件的接口機制主要通過消息傳遞來完成系統之間的協作和通信。通過消息中間件把應用擴展到不同的操作系統和不同的網絡環境。通過使用可靠的消息隊列，提供支持消息傳遞所需的目錄、安全和管理服務。當一個事件發生時，消息中間件通知服務方應該進行何種操作。其核心安裝在需要進行消息傳遞的系統上，在它們之間建立邏輯通道，由消息中間件實現消息發送。消息中間件可以支持同步方式和異步方式，實際上是一種點到點的機制，因而可以很好的適用于面向對象的編程方式。消息中間件可以保證消息包傳輸過程的正確、可靠和及時。消息中間件提供以下基本功能：消息隊列、觸發器、信息傳遞、數據格式翻譯、安全性控制、數據廣播、錯誤恢復、資源定位、消息及請求的優先級設定、擴展的調試功能等。技術特點消息中間件能夠在任何時刻將消息進行傳送或者存儲轉發，不會占用大量的網絡帶寬，可以跟蹤事務，并且通過將事務存儲到磁盤上實現網絡故障時系統的恢復。優點：為不同的企業應用系統提供了跨多平臺的消息傳輸；除支持同步傳輸模式外，還支持異步傳輸，有助于在應用間可靠地進行消息傳輸。