【正文】 接口層應(yīng)用接口層實(shí)現(xiàn)EAI到應(yīng)用資源層中被集成系統(tǒng)的應(yīng)用層接口，該層提供多種方式與應(yīng)用資源層系統(tǒng)連接，主要包括兩類連接方式：對于三層應(yīng)用的企業(yè)應(yīng)用，應(yīng)用接口層通過應(yīng)用接口和企業(yè)應(yīng)用的應(yīng)用服務(wù)器連接，應(yīng)用接口的實(shí)現(xiàn)協(xié)議包括：Http(s), SOAP, RMI/IIOP, FTP, JMS,SOCKET等。應(yīng)用接口層最終向上層提供一個(gè)統(tǒng)一的應(yīng)用接口界面，也就是提供一系列API，通過訪問這些API，EAI可以給各應(yīng)用系統(tǒng)提供的服務(wù)。因此，應(yīng)用視圖API對接口API進(jìn)行了一定的封裝。數(shù)據(jù)轉(zhuǎn)換包括格式轉(zhuǎn)換和語義轉(zhuǎn)換；接口封裝是指對原有接口進(jìn)行組裝，適配，實(shí)現(xiàn)更為上層高級的功能。流程整合是在應(yīng)用整合層的基礎(chǔ)上對業(yè)務(wù)流程進(jìn)行整合，向上提供集成的服務(wù)。如果應(yīng)用之間的有嚴(yán)格的調(diào)用次序和事務(wù)關(guān)系（緊耦合），則適合使用同步整合方式進(jìn)行整合。2) 異步整合方式被整合應(yīng)用之間采用消息，事件方式傳遞信息。對于異步整合方式，流程整合層提供消息總線和消息處理器。3) 混合整合方式混合整合方式同時(shí)使用同步和異步方式進(jìn)行整合。獨(dú)立于流程整合方式，流程整合層向上提供的服務(wù)也分為同步和異步方式，同步服務(wù)向上提供可直接調(diào)用接口，異步服務(wù)向上提供消息接口，需要注意的是，對于同步服務(wù)，其流程整合方式可以是同步的，也可以是異步的。異步服務(wù)也是如此。 與外部系統(tǒng)的接口外部系統(tǒng)可以通過基礎(chǔ)服務(wù)中的接入服務(wù)使用應(yīng)用集成平臺提供的應(yīng)用服務(wù)。對外服務(wù)系統(tǒng)涉及內(nèi)部系統(tǒng)包括以下幾類：n 基礎(chǔ)架構(gòu)：是對外服務(wù)系統(tǒng)的核心，包括基礎(chǔ)服務(wù)系統(tǒng)、EAI系統(tǒng)、EDI系統(tǒng)，這些系統(tǒng)沒有用戶界面。系統(tǒng)管理員通過配置和監(jiān)控子系統(tǒng)來管理對外服務(wù)系統(tǒng)。這五個(gè)應(yīng)用系統(tǒng)使用基礎(chǔ)架構(gòu)提供的各種服務(wù)，接受配置和監(jiān)控子系統(tǒng)的管理。 數(shù)據(jù)交換平臺服務(wù) EDI 的概念EDI的最初的含義是電子數(shù)據(jù)交換Electronic Data Interchange。這些要共享和交換的數(shù)據(jù)需要有一種統(tǒng)一的格式以便被各個(gè)信息系統(tǒng)識別。但是在更多的行業(yè)，還沒有統(tǒng)一的數(shù)據(jù)交換格式。隨著信息化建設(shè)程度不斷提高，電子數(shù)據(jù)交換技術(shù)的發(fā)展，一些更多技術(shù)的融合，EDI被賦予了一種新的含義即企業(yè)數(shù)據(jù)集成（Enterprise Data Integration）。對外服務(wù)系統(tǒng)只涉及到數(shù)據(jù)交換。 技術(shù)架構(gòu)網(wǎng)上業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫同綜合執(zhí)法數(shù)據(jù)庫獨(dú)立，對內(nèi)數(shù)據(jù)交換方式如下：n 基礎(chǔ)數(shù)據(jù)采用數(shù)據(jù)庫的同步機(jī)制完成，保證基礎(chǔ)數(shù)據(jù)和編碼的統(tǒng)一。數(shù)據(jù)存儲策略如下：n 地市縣級數(shù)據(jù)集中存放在交通廳信息中心數(shù)據(jù)庫中。文件可以采用加密的XML格式。n 對實(shí)時(shí)性要求較高，且交換數(shù)據(jù)信息較少的對外數(shù)據(jù)交換，采用Socket方式。即將交換的文件上傳到FTP服務(wù)器的目錄下，同時(shí)用Socket通知對方下載數(shù)據(jù)交換文件。 實(shí)現(xiàn)方式如下：n 數(shù)據(jù)接口層采用基本類實(shí)現(xiàn)；n 數(shù)據(jù)視圖層采用EJB技術(shù)實(shí)現(xiàn)，實(shí)現(xiàn)EJB的localhome接口。n 數(shù)據(jù)服務(wù)層采用EJB技術(shù)實(shí)現(xiàn)，實(shí)現(xiàn)EJB的Remote接口。n 數(shù)據(jù)視圖層和數(shù)據(jù)服務(wù)層采用Session Bean實(shí)現(xiàn)。n 數(shù)據(jù)接口層采用普通java類實(shí)現(xiàn)。 數(shù)據(jù)視圖層設(shè)計(jì)說明如下：n 數(shù)據(jù)視圖層采用SessionBean類型的EJB。n 視圖層獨(dú)立構(gòu)成一個(gè)jar包。n 數(shù)據(jù)服務(wù)可以內(nèi)置該視圖的一些缺省的輸入?yún)?shù)以提高服務(wù)的執(zhí)行效率。n 數(shù)據(jù)服務(wù)可以提供多個(gè)調(diào)用不同視圖的方法，可以從調(diào)用服務(wù)的參數(shù)中判斷具體調(diào)用那個(gè)視圖。 數(shù)據(jù)接口層數(shù)據(jù)接口層實(shí)現(xiàn)對外服務(wù)系統(tǒng)與數(shù)據(jù)源的連接。數(shù)據(jù)接口層只負(fù)責(zé)從數(shù)據(jù)源獲取數(shù)據(jù)，并且將數(shù)據(jù)原樣返回EDI系統(tǒng)的視圖層。數(shù)據(jù)接口層傳遞的數(shù)據(jù)是雙向的。接口層接口的多少是取決于連接方式的類型。數(shù)據(jù)接口層就向郵局一樣，只負(fù)責(zé)把“郵包”從按照要求從目的地送達(dá)（取回），交給目的地（請求方），而不關(guān)心具體郵包的內(nèi)容。數(shù)據(jù)視圖層也可以將輸入的數(shù)據(jù)按照要求的格式加工處理后，交給接口層，發(fā)送到目的地。 一個(gè)視圖可以多次調(diào)用多個(gè)接口。 數(shù)據(jù)服務(wù)層數(shù)據(jù)服務(wù)層使用數(shù)據(jù)視圖層的服務(wù)，對外提供數(shù)據(jù)交換服務(wù)。一個(gè)服務(wù)可以調(diào)用多個(gè)視圖，一般情況下一個(gè)服務(wù)只調(diào)用一個(gè)視圖。 與外部系統(tǒng)的接口企業(yè)數(shù)據(jù)交換服務(wù)是對外數(shù)據(jù)交換子系統(tǒng)的后臺服務(wù)，對外數(shù)據(jù)交換子系統(tǒng)是企業(yè)數(shù)據(jù)交換服務(wù)的前臺表現(xiàn)。企業(yè)數(shù)據(jù)交換提供一些常用的固定的數(shù)據(jù)服務(wù)，信息檢索引擎可以使用這些服務(wù)。應(yīng)用交換平臺可以在接口層實(shí)現(xiàn)電話、電子郵件、短信、傳真等接口。n 統(tǒng)一檢索引擎采用標(biāo)準(zhǔn)的XML輸入/輸出格式。 技術(shù)架構(gòu)信息檢索引擎設(shè)計(jì)為一個(gè) Session Bean類型的EJB，通過不同的方法實(shí)現(xiàn)不同的接入。 應(yīng)用架構(gòu)在實(shí)際應(yīng)用中，大量的查詢和統(tǒng)計(jì)信息的需求，這些需求是單向的。雙向的數(shù)據(jù)交換在數(shù)據(jù)交換服務(wù)系統(tǒng)中實(shí)現(xiàn)，不在信息檢索引擎中考慮。圖410：統(tǒng)一搜索引擎實(shí)現(xiàn)模型 與外部系統(tǒng)的接口信息檢索引擎可以使用EAI服務(wù)和EDI服務(wù)獲取信息；信息檢索引擎也可以通過自己的方法直接直接調(diào)用外部系統(tǒng)的數(shù)據(jù)庫。最常見的是logging模塊，這樣，程序按功能被分為好幾層，如果按傳統(tǒng)的繼承的話，商業(yè)模型繼承日志模塊的話根本沒有什么意義，而通過創(chuàng)建一個(gè)logging切面就可以使用AOP來實(shí)現(xiàn)相同的功能了。連接點(diǎn)是應(yīng)用程序提供給切面插入的地方，可以添加新的方法。3) advice（處理邏輯）：advice是我們切面功能的實(shí)現(xiàn)，它通知程序新的行為。advice在jointpoint處插入到應(yīng)用程序中。決定了那個(gè)jointpoint會獲得通知。6) target（目標(biāo)類）：是指那些將使用advice的類，一般是指獨(dú)立的那些商務(wù)模型。7) proxy（代理類）：使用了proxy的模式。8) weaving(編織）：是指應(yīng)用aspects到一個(gè)target對象創(chuàng)建proxy對象的過程：plie time，classload time，runtime。 Hibernate技術(shù)使用數(shù)據(jù)庫和配置文件數(shù)據(jù)來為應(yīng)用程序提供持久化服務(wù)和持久化的對象。Hibernate特性：Hibernate可以被標(biāo)準(zhǔn)的JMX Mbean管理n 多種便利開發(fā)環(huán)境：可以用Jbuilder、Idea、Eclipse開發(fā)。n 查詢與檢索：相對其他ORM而言，Hibernate提供了靈活多樣的機(jī)制。VO是獨(dú)立的Java Object，簡單攜帶了對象的一些屬性信息。n 事務(wù)管理：Hibernate 是JDBC 的輕量級封裝，本身并不具備事務(wù)管理能力。在程序中用什么機(jī)制來處理事物可以通過配置文件來設(shè)置216。 基于JTA的事務(wù)管理：JTA 提供了跨Session 的事務(wù)管理能力。JTA的事務(wù)周期可橫跨多個(gè)JDBC Connection生命樣對于基于JTA事務(wù)的Hibernate而言，JTA事務(wù)橫跨可橫跨多個(gè)Session。鎖分為樂觀鎖和悲觀鎖。Hibernate 在本地JVM 中維護(hù)了一個(gè)緩沖池，并將從數(shù)據(jù)庫獲得的數(shù)據(jù)保存到池中。2 通用模塊設(shè)計(jì) CA應(yīng)用方案 PKI/CA安全認(rèn)證體系互聯(lián)網(wǎng)的發(fā)展和信息技術(shù)的普及，給人們的工作和生活帶來了前所未有的便利。為了防范信息安全風(fēng)險(xiǎn)，許多新的安全技術(shù)和規(guī)范不斷涌現(xiàn)，PKI（Public Key Infrastructure，公開密鑰基礎(chǔ)設(shè)施）即是其中一員。n 保密性 如何保證電子商務(wù)中涉及的大量保密信息在公開網(wǎng)絡(luò)的傳輸過程中不被竊取 n 完整性 如何保證電子商務(wù)中所傳輸?shù)慕灰仔畔⒉槐恢型敬鄹募巴ㄟ^重復(fù)發(fā)送進(jìn)行虛假交易 n 身份認(rèn)證與授權(quán) 在電子商務(wù)的交易過程中，如何對雙方進(jìn)行認(rèn)證，以保證交易雙方身份的正確性 n 抗抵賴 在電子商務(wù)的交易完成后，如何保證交易的任何一方無法否認(rèn)已發(fā)生的交易 在PKI體系中，CA（Certificate Authority，認(rèn)證中心）和數(shù)字證書是密不可分的兩個(gè)部分。數(shù)字證書，又叫“數(shù)字身份證”、“數(shù)字ID”，是由認(rèn)證中心發(fā)放并經(jīng)認(rèn)證中心數(shù)字簽名的，包含公開密鑰擁有者以及公開密鑰相關(guān)信息的一種電子文件，可以用來證明數(shù)字證書持有者的真實(shí)身份。它主要負(fù)責(zé)產(chǎn)生、分配并管理所有參與網(wǎng)上交易的實(shí)體所需的身份認(rèn)證數(shù)字證書。 電子交易的各方都必須擁有合法的身份，即由數(shù)字證書認(rèn)證中心機(jī)構(gòu)（CA）簽發(fā)的數(shù)字證書，在交易的各個(gè)環(huán)節(jié)，交易的各方都需檢驗(yàn)對方數(shù)字證書的有效性，從而解決了用戶信任問題。基于其牢固的安全機(jī)制，CA應(yīng)用可擴(kuò)大到一切有安全要求的網(wǎng)上數(shù)據(jù)傳輸服務(wù)。其中安全認(rèn)證體系的建立是關(guān)鍵，它決定了網(wǎng)上交易和結(jié)算能否安全進(jìn)行，因此，數(shù)字證書認(rèn)證中心機(jī)構(gòu)的建立對電子商務(wù)的開展具有非常重要的意義。在第六章系統(tǒng)平臺與集成方案中，詳盡闡述了CA認(rèn)證中心的建設(shè)方案。每個(gè)用戶自己設(shè)定一把特定的僅為本人所知的私有密鑰（私鑰），用它進(jìn)行解密和簽名；同時(shí)設(shè)定一把公共密鑰（公鑰）并由本人公開，為一組用戶所共享，用于加密和驗(yàn)證簽名。自己的私鑰解密，這樣信息就可以安全無誤地到達(dá)目的地了。密過程是一個(gè)不可逆過程，即只有用私有密鑰才能解密。數(shù)據(jù)簽名采用公鑰密碼體制的技術(shù)實(shí)現(xiàn)的：用戶采用私有密鑰將數(shù)據(jù)進(jìn)行簽名，而擁有公用密鑰的另一方，采用公用密鑰進(jìn)行驗(yàn)證簽名。這一數(shù)字簽名過程這樣就保證了數(shù)據(jù)交換的完整性、身份認(rèn)證和不可抵賴性：252。252。252。因此，數(shù)字簽名完全可以作為對外服務(wù)系統(tǒng)的網(wǎng)上業(yè)務(wù)子系統(tǒng)的電子交易憑證。考慮到算法效率，如下實(shí)現(xiàn)：用對稱密鑰將數(shù)據(jù)信息加密，而公鑰將對稱密鑰進(jìn)行非對稱加密。這一加密過程實(shí)現(xiàn)了數(shù)據(jù)交換的保密性：252。252。對于基于Internet的網(wǎng)上電子交易，必須保證數(shù)據(jù)的保密性、完整性、身份認(rèn)證和不可抵賴性的所有要求，因此需要簽名和加密技術(shù)同時(shí)運(yùn)用。 CA的應(yīng)用需求 對外服務(wù)系統(tǒng)的網(wǎng)上業(yè)務(wù)子系統(tǒng)要求采用CA認(rèn)證方案，保證網(wǎng)上查詢等業(yè)務(wù)實(shí)現(xiàn)，其具體需求表現(xiàn)為：n 實(shí)現(xiàn)以數(shù)字證書和安全認(rèn)證中心為主的用戶身份認(rèn)證功能。n 擬采用國家交通部在建的系統(tǒng)。n 存放數(shù)字證書的方式支持USB KEY。應(yīng)用于網(wǎng)上業(yè)務(wù)子系統(tǒng)中，完全能夠保證實(shí)現(xiàn)身份認(rèn)證、數(shù)據(jù)保密性、數(shù)據(jù)完整性和不可抵賴性。節(jié)省了CA系統(tǒng)的建設(shè)投資，簡便易行，可操作性強(qiáng)。這一方案在其他機(jī)關(guān)已經(jīng)成功運(yùn)用。網(wǎng)上業(yè)務(wù)子系統(tǒng)通過使用存儲在USB KEY、IC卡內(nèi)部的證書，實(shí)現(xiàn)網(wǎng)上業(yè)務(wù)子系統(tǒng)交易的通信數(shù)據(jù)加密，和交易數(shù)據(jù)簽名。 用戶身份認(rèn)證身份認(rèn)證服務(wù)解決“是誰”的問題，即控制外部系統(tǒng)能否接入對外服務(wù)系統(tǒng)，接入以后的身份是什么；身份認(rèn)證服務(wù)可以通過用戶名，密碼方式進(jìn)行認(rèn)證，也可以調(diào)用證書服務(wù)提供更高級別的證書登錄服務(wù)。主要原理是將用戶提供的輔助驗(yàn)證信息按類別保存在服務(wù)器中，當(dāng)用戶從客戶端訪問服務(wù)器時(shí)，身份認(rèn)證系統(tǒng)要求客戶端提供這些輔助信息，大多數(shù)可以自動從客戶端的計(jì)算機(jī)中自動采集，如果是指紋則需要客戶端有指紋采集設(shè)備（例如指紋鼠標(biāo)），然后將這些信息與存放在服務(wù)器中信息進(jìn)行比對，如果成功，則通過身份驗(yàn)證。 JavaScript 中調(diào)用方法： //客戶機(jī)端和服務(wù)器端區(qū)別如前所示 Var ofjEncrypter。 Var strSrcXML。 //根據(jù)應(yīng)用不同，或者StrSrcXML=”Forms…/Forms”。Var strCert。 解密接口 接口名稱： 方法： Decrypt( [in]BSTR bstrSourceXML, //要解密的數(shù)據(jù) [in]BSTR bstrIDFileName, //解密用ID文件路徑名 [in]BSTR bstrPasswd, //解密用ID口令 [out, retval]BSTR *bstrDecryptedXML //解密后的數(shù)據(jù)或錯(cuò)誤信息 )。 objDecrypter = ActiveXObject(“fjdsPKIClient. Decrypter”)。 Var strIDFileName = “c:\\fjdsPKI\\”。strDecryptedXML= (strSrcXML,strIDFilename,”myPasswd”)。從上世紀(jì)90年代中期以來，基于PKI（Public Key Infrastructure）技術(shù)的電子數(shù)據(jù)簽名和加密技術(shù)逐漸在國際、國內(nèi)成為這種技術(shù)支撐的標(biāo)準(zhǔn)手段。上述兩類業(yè)務(wù)在電子簽名技術(shù)的利用方式上是不同的：l 行政文書在不同環(huán)節(jié)的流轉(zhuǎn)過程中經(jīng)常會發(fā)生修改，要求要保留修改痕跡，只有在達(dá)到共識，正式簽發(fā)時(shí)文檔的內(nèi)容才會穩(wěn)定下來，不允許再次修改。雖然兩種類型的業(yè)務(wù)模式有區(qū)別，但使用的技術(shù)原理基本相同，都是使用基于PKI技術(shù)的電子簽名技術(shù)，電子簽名技術(shù)與圖章圖像結(jié)合起來，就是電子印章，在這里，電子簽名技術(shù)是核心，圖章圖像只是一種直觀的表示。圖418：電子印章應(yīng)用體系結(jié)構(gòu) 電子簽名基本原理圖419：數(shù)字簽名過程無論是Word類多媒體文檔，還是XML電子表單，其數(shù)據(jù)簽名的原理都是相同的，見上圖，包括這樣幾個(gè)步驟：1) 簽名方用HASH算法從原始信息中提取數(shù)字特征值；2) 簽名方用自己的私鑰對數(shù)字特征值加密，加密后的數(shù)字特征值就是該文檔的數(shù)字簽名；3) 簽名方把原始信息和數(shù)字簽名封裝在一起，構(gòu)成一個(gè)帶簽名的文檔或表單，并發(fā)送給接受方；4) 接收方按照約定首先把接收到的文檔拆封，取得其原始數(shù)據(jù)和數(shù)字簽名；5) 接收方按照同樣的算法和原理生成原始信息的數(shù)字特征值；6) 接收方用簽名方的公鑰解密數(shù)字簽名，從中提取數(shù)字特征值，并步驟5）中自己計(jì)算得到的數(shù)字特征值比隊(duì)，如果結(jié)果相同，則原始信息沒有被篡改，傳輸過程中沒有丟失。本方案設(shè)計(jì)如下四個(gè)維度的權(quán)限控制：n 功能權(quán)限：即用戶可以進(jìn)入哪個(gè)模塊，可以進(jìn)行哪些增加、刪除、修改和查詢操作等；n 數(shù)據(jù)權(quán)限：即用戶雖然擁有功能權(quán)限，但只能操作一定范圍的數(shù)據(jù)。比如審核之前具有修改的權(quán)限，審核之后就只有瀏覽