【正文】 其中，需要保證從session中獲取消息隊(duì)列后將session關(guān)閉的功能。其中定義并實(shí)現(xiàn)了向隊(duì)列池中推送請(qǐng)求和響應(yīng)消息的方法。應(yīng)用服務(wù)器會(huì)向客戶(hù)端發(fā)送元數(shù)據(jù)請(qǐng)求，請(qǐng)求會(huì)被加入到ActiveMQ的消息隊(duì)列，然后再依次發(fā)送給客戶(hù)端，并由客戶(hù)端進(jìn)行處理。（3）設(shè)計(jì)：ActiveMQ服務(wù)器作為消息生產(chǎn)者，而客戶(hù)端和應(yīng)用服務(wù)器都是消息的消費(fèi)者。（2）服務(wù)器端：服務(wù)器端的配置是用以指定failover模式下的用以進(jìn)行消息轉(zhuǎn)發(fā)的所有ActiveMQ的URL。INSERT INTO ACTIVEMQ_LOCK(ID) VALUES (1)。 bean id=hanads class= destroymethod=closeproperty name=driverClassName value=/property name=url value=jdbc:sap://${}:${}/${}/property name=username value=${}/property name=password value=${}/property name=poolPreparedStatements value=true//bean ，所有的ActiveMQ形成了一個(gè)集群，并且全部指向同一個(gè)數(shù)據(jù)庫(kù)，在數(shù)據(jù)庫(kù)中，會(huì)設(shè)定一個(gè)排他鎖。首先需要保證在服務(wù)器端和ActiveMQ端進(jìn)行適當(dāng)?shù)呐渲?，?shí)現(xiàn)JDBC master/slave模式。而在Http Server端，：Proxy balancer://proxyBalancerMember :7171/ route=jvm1 BalancerMember :7171/ route=jvm2……/Proxy這樣對(duì)應(yīng)用服務(wù)器的負(fù)載均衡就由Http Server實(shí)現(xiàn)，無(wú)需程序另外實(shí)現(xiàn)。Apache Http Server是一個(gè)開(kāi)源的網(wǎng)頁(yè)服務(wù)器，可以在大多數(shù)的操作平臺(tái)上使用，以其跨平臺(tái)、安全性、可靠性而被廣泛接受和應(yīng)用，是目前最流行的web服務(wù)器之一。 集群實(shí)現(xiàn) 負(fù)載均衡在DMOC服務(wù)器部署過(guò)程中，使用Apache Http Server實(shí)現(xiàn)負(fù)載均衡。在整個(gè)產(chǎn)品開(kāi)發(fā)過(guò)程中，為了保證云計(jì)算的安全性，采取了有效的安全措施。通過(guò)流程圖和類(lèi)圖的設(shè)計(jì)，為集群和單點(diǎn)登錄的實(shí)現(xiàn)做好充分準(zhǔn)備。一方面，對(duì)客戶(hù)端與服務(wù)器之間的通信過(guò)程設(shè)計(jì)進(jìn)行了介紹；另一方面，對(duì)服務(wù)器端的應(yīng)用組成進(jìn)行研究，為實(shí)現(xiàn)DMOC產(chǎn)品功能的準(zhǔn)備。： 本章小結(jié)本章主要闡述了DMOC產(chǎn)品的整體框架和設(shè)計(jì)理念。只是在這種情況下，就不需要借用第三方的IDS存儲(chǔ)和管理用戶(hù)信息，只需要將服務(wù)器和數(shù)據(jù)庫(kù)之間通信時(shí)的密碼由SAML token進(jìn)行替代就可以實(shí)現(xiàn)二者之間通過(guò)SAML認(rèn)證的方式通信。在用戶(hù)需要使用DMOC服務(wù)時(shí)，實(shí)際上，用戶(hù)只需將個(gè)人信息注冊(cè)到IDS提供的SP上，DMOC根據(jù)該SP的證書(shū)和關(guān)鍵秘鑰對(duì)用戶(hù)發(fā)來(lái)的請(qǐng)求進(jìn)行解析，確認(rèn)用戶(hù)是否已注冊(cè)于指定SP，這樣就可以實(shí)現(xiàn)了對(duì)用戶(hù)訪(fǎng)問(wèn)的控制。DMOC在開(kāi)發(fā)實(shí)現(xiàn)到IDS的SSO認(rèn)證時(shí)，首先對(duì)認(rèn)證進(jìn)行了定義，使得由Java EE定義的servlet API可以實(shí)現(xiàn)資源保護(hù)，對(duì)于資源保護(hù)的具體實(shí)現(xiàn)，在應(yīng)用層完成，實(shí)現(xiàn)用戶(hù)信息獲取的同時(shí)還必須實(shí)現(xiàn)明確的退出登錄功能，使得SAML連接得到有效終止。在進(jìn)行SAML斷言解析匹配過(guò)程中，IDS實(shí)際上扮演一個(gè)SAML Identity Provider(IdP)的角色，IDS作為SAML 認(rèn)證的提供者，根據(jù)從應(yīng)用程序發(fā)送的請(qǐng)求，IdP會(huì)根據(jù)用戶(hù)的請(qǐng)求信息判斷用戶(hù)是否具有授權(quán)。用戶(hù)收到帶有Artifact的應(yīng)答消息之后，向訪(fǎng)問(wèn)的應(yīng)用程序再次發(fā)出包含有SAML斷言和Artifact的請(qǐng)求信息。SAP NetWeaver Cloud在收到用戶(hù)請(qǐng)求之后，會(huì)把這一請(qǐng)求重定向到SAP ID Service，由其進(jìn)行處理這一請(qǐng)求。根據(jù)用戶(hù)的需求，SAP ID Service可以被設(shè)置為基于HTTP的認(rèn)證方式，這是最基本的認(rèn)證方式，或者是基于SAML的單點(diǎn)登錄認(rèn)證方式。至于IDS是如何提供SSO服務(wù)的。這里的SSO可以使得用戶(hù)在訪(fǎng)問(wèn)所有部署與SAP Netweaver Cloud上的應(yīng)用時(shí)只需要登陸一次，之后用戶(hù)就可以獲得所有應(yīng)用的訪(fǎng)問(wèn)授權(quán)。這里存儲(chǔ)了所有訪(fǎng)問(wèn)應(yīng)用程序的被保護(hù)的資源信息，例如用戶(hù)名、密碼、使用角色等。通過(guò)IDS的使用，開(kāi)發(fā)者可以將精力更多的集中在業(yè)務(wù)邏輯上，而不用過(guò)多的牽涉到安全問(wèn)題的解決上，并且這樣可以集中管理用戶(hù)認(rèn)證信息，安全并高效。首先，針對(duì)SSO在IDS中的實(shí)現(xiàn)。通過(guò)在這兩部分對(duì)單點(diǎn)登錄技術(shù)的應(yīng)用，可以實(shí)現(xiàn)用戶(hù)訪(fǎng)問(wèn)web資源的便捷以保證云安全，并且，在數(shù)據(jù)庫(kù)和應(yīng)用服務(wù)器之間進(jìn)行通信時(shí)使用單點(diǎn)登錄技術(shù)也更加有效的保證了數(shù)據(jù)獲取的有效性和實(shí)時(shí)性，因?yàn)樵谠摬糠?，可以根?jù)設(shè)定好的間隔，實(shí)時(shí)更換認(rèn)證數(shù)據(jù)，保證數(shù)據(jù)獲取的安全性和實(shí)效性[11]。表格 ActiveMQ實(shí)現(xiàn)JMS類(lèi)設(shè)計(jì)Connection Factory由ActiveMQConnectionFactory類(lèi)實(shí)現(xiàn)Create connectionsinitializeTheConectionOnly()Create sessionsinitSessionDestinationsForAgent()Message ProducercreateObjectMessage()//發(fā)送消息Message ConsumergetAgentMessageFromObjectMessage()//接收消息Close SessioncloseAllSessionsAndConnections()//關(guān)閉所有session 單點(diǎn)登錄模塊設(shè)計(jì)DMOC服務(wù)器web應(yīng)用的開(kāi)發(fā)就是用了單點(diǎn)登錄技術(shù)，在本產(chǎn)品中，有兩個(gè)部分使用了該技術(shù)。下圖是需要實(shí)現(xiàn)的JMS的流程圖。 System Repository中用于存儲(chǔ)可信任IDS URL的表結(jié)構(gòu) 集群設(shè)計(jì)在DMOC設(shè)計(jì)中，支持?jǐn)?shù)據(jù)庫(kù)集群、服務(wù)器集群、客戶(hù)端集群這三種集群類(lèi)型。System Repository則是針對(duì)最高權(quán)限用戶(hù)—超級(jí)用戶(hù)設(shè)計(jì)的數(shù)據(jù)庫(kù)。根據(jù)不同用途又為每一個(gè)organization設(shè)計(jì)針對(duì)不同配置環(huán)境的數(shù)據(jù)庫(kù)，分別為sandbox和production。不同于以往將所有的用戶(hù)信息和數(shù)據(jù)都放置于同一個(gè)數(shù)據(jù)庫(kù)中，DMOC根據(jù)用戶(hù)權(quán)限和部署環(huán)境的不同，將用戶(hù)信息以及作業(yè)信息分別存儲(chǔ)于不同的數(shù)據(jù)庫(kù)中，這樣既保證了數(shù)據(jù)的安全性，又對(duì)數(shù)據(jù)的多樣性有了很好的保持。為了滿(mǎn)足用戶(hù)需求，DMOC結(jié)合其原有產(chǎn)品DM在使用中用戶(hù)的要求。 數(shù)據(jù)庫(kù)設(shè)計(jì)DMOC的數(shù)據(jù)庫(kù)設(shè)計(jì)采用SaaS安全架構(gòu)設(shè)計(jì)中的共享數(shù)據(jù)庫(kù)單獨(dú)模式。首先，集群的設(shè)計(jì)可以有效避免服務(wù)終端和非連續(xù)服務(wù)對(duì)用戶(hù)數(shù)據(jù)保護(hù)帶來(lái)的風(fēng)險(xiǎn)；其次，數(shù)據(jù)庫(kù)的設(shè)計(jì)用以保證用戶(hù)與用戶(hù)之間的信息相對(duì)獨(dú)立，保證信息安全；最后，單點(diǎn)登錄技術(shù)的設(shè)計(jì)可以有效保證用戶(hù)訪(fǎng)問(wèn)云資源的安全性。首先，用戶(hù)不能完全確定商業(yè)公司提供的云計(jì)算服務(wù)是否可信，是否可以將自己持有的商業(yè)機(jī)密放心托管給云服務(wù)提供商；其次，云計(jì)算時(shí)通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)部署的，那么其賴(lài)以生存的網(wǎng)絡(luò)無(wú)法保證持續(xù)安全，服務(wù)持續(xù)不中斷；最后，云計(jì)算的服務(wù)器部署大多依賴(lài)軟硬件的大規(guī)模結(jié)合來(lái)實(shí)現(xiàn)高可用和高效率，無(wú)法保證硬件設(shè)施的時(shí)刻安全也是用戶(hù)對(duì)云計(jì)算的安全性的顧慮所在。這也是DMOC設(shè)計(jì)的一項(xiàng)重要目的。 DMOC服務(wù)器架構(gòu)，DMOC服務(wù)器應(yīng)用的三個(gè)部分分別具有不同的分工，客戶(hù)端管理也就是Agentmanager用來(lái)對(duì)客戶(hù)端的消息進(jìn)行處理分發(fā)，交給web應(yīng)用，由組成這一部分的核心作業(yè)處理引擎處理數(shù)據(jù)ETL作業(yè)。 DMOC服務(wù)器框架設(shè)計(jì)DMOC的服務(wù)器端可以細(xì)分為三個(gè)部分，主要包含頁(yè)面UI，和處理作業(yè)的核心引擎；一部分是打包好的Agentmanager部分，用于實(shí)現(xiàn)服務(wù)器和客戶(hù)端的消息通信和分發(fā)；最后一部分是HANALoader部分，用于實(shí)現(xiàn)數(shù)據(jù)庫(kù)和應(yīng)用服務(wù)器之間的通信。HANA DB利用主存儲(chǔ)器(RAM)的低成本優(yōu)勢(shì),它使用多核處理器的數(shù)據(jù)處理能力和針對(duì)固態(tài)硬盤(pán)的快速數(shù)據(jù)存取相對(duì)傳統(tǒng)的硬盤(pán)驅(qū)動(dòng)器具有非常大優(yōu)勢(shì)，HANA具有更好的數(shù)據(jù)處理性能，可提供更好的事務(wù)性分析。與眾多應(yīng)用程序一樣，DMOC服務(wù)器的大部分信息也是存儲(chǔ)在數(shù)據(jù)庫(kù)端。這一組件負(fù)責(zé)對(duì)服務(wù)器端注冊(cè)的多個(gè)客戶(hù)端進(jìn)行管理。用戶(hù)在公用網(wǎng)絡(luò)對(duì)SAP 云進(jìn)行訪(fǎng)問(wèn)，期間使用HTTPS協(xié)議增強(qiáng)訪(fǎng)問(wèn)安全性，并使用負(fù)載均衡模式來(lái)合理分配服務(wù)器資源，使得對(duì)服務(wù)器資源的訪(fǎng)問(wèn)分配達(dá)到最優(yōu)。用戶(hù)在后續(xù)對(duì)數(shù)據(jù)進(jìn)行的管理都需要經(jīng)過(guò)客戶(hù)端的job server進(jìn)行處理。使用DMOC產(chǎn)品提供的服務(wù)，用戶(hù)只需擁有一個(gè)DMOC的賬號(hào)，通過(guò)瀏覽器訪(fǎng)問(wèn)服務(wù)提供方預(yù)先搭設(shè)成功的云平臺(tái)進(jìn)行數(shù)據(jù)遷移管理操作。其次，用戶(hù)可以使用服務(wù)提供方提供的用戶(hù)，登錄到DMOC網(wǎng)絡(luò)服務(wù)界面，下載并安裝客戶(hù)端到本地，同時(shí)將客戶(hù)端注冊(cè)到DMOC界面，并可以監(jiān)管客戶(hù)端狀態(tài)。首先，用戶(hù)在得到DMOC服務(wù)器連接信息之后，向服務(wù)提供方申請(qǐng)對(duì)DMOC提供的web service具有相應(yīng)操作權(quán)限的用戶(hù)，用戶(hù)的權(quán)限一般分為四類(lèi)，包括管理員權(quán)限，安全管理員權(quán)限，產(chǎn)品操作員權(quán)限和開(kāi)發(fā)人員權(quán)限。本地包括本地客戶(hù)端的安裝以及用戶(hù)由本地發(fā)出數(shù)據(jù)處理請(qǐng)求。19浙江大學(xué)碩士學(xué)位論文 第4章 DMOC設(shè)計(jì)第4章 DMOC設(shè)計(jì) DMOC總體設(shè)計(jì)本文主要針對(duì)DMOC服務(wù)器端的開(kāi)發(fā)設(shè)計(jì)進(jìn)行分析和研究。 slave成為master模型 本章小結(jié)本章主要對(duì)云計(jì)算平臺(tái)部署實(shí)現(xiàn)需要的應(yīng)用技術(shù)進(jìn)行了詳細(xì)介紹和分析。其設(shè)置如下：failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616)當(dāng)master開(kāi)始運(yùn)作以后，也就是broker1，則整個(gè)傳輸過(guò)程都將有master完成。 master/slave的部署模型圖。所有的broker將共同連接到一個(gè)共享的文件系統(tǒng)或者數(shù)據(jù)庫(kù)，當(dāng)master停止工作時(shí)，slave立刻接替master的工作。當(dāng)master因?yàn)橛布收匣蛘咂渌蛲Ｖ构ぷ鲿r(shí)，消息將很快的被放置于其中一個(gè)slave進(jìn)行處理，這時(shí)候處理消息的slave也就隨即變成了master，消息得到處理而且并沒(méi)有丟失。所以，master/slave模式就是基于處理這一問(wèn)題提出的。當(dāng)我們?cè)诰W(wǎng)絡(luò)中使用單獨(dú)一個(gè)broker進(jìn)行消息代理時(shí)，當(dāng)這一個(gè)broker因?yàn)槟承┰蛲Ｖ构ぷ?，那么就必須等待broker重新啟動(dòng)之后才能使得消息繼續(xù)被處理。ActiveMQ作為一個(gè)獨(dú)立的JMS提供者，支持隊(duì)列消費(fèi)集群，broker集群，和master/slave等模式的消息處理集群。 ActiveMQ與集群集群是一個(gè)較大的概念，對(duì)不同的對(duì)象具有不同的含義。它的易用性以及完全支持JMS和J2EE，使得其得到廣泛地使用。ActiveMQ是Apache的一款非常流行和功能強(qiáng)大的消息傳遞和集成服務(wù)器。它以主題為中心，是一種多對(duì)多的通信模式。這種消息傳遞模式是一對(duì)一的，所以被稱(chēng)為點(diǎn)對(duì)點(diǎn)的消息傳遞模式。JMS提供了點(diǎn)對(duì)點(diǎn)P2P(peer to peer)和發(fā)布/訂閱P/S(publish／subscriber)兩種通信模式：1)點(diǎn)對(duì)點(diǎn)通信模式：點(diǎn)對(duì)點(diǎn)的消息傳遞模式是指發(fā)送方將消息發(fā)送到一個(gè)指定消息隊(duì)列中去，接收方則從消息隊(duì)列中提取信息。當(dāng)一個(gè)JMS客戶(hù)發(fā)送出一條消息后，它依然可以繼續(xù)消息發(fā)送的操作，而無(wú)需等待響應(yīng)。在JMS中，客戶(hù)只需要將消息發(fā)送到一個(gè)主題或者隊(duì)列上，其他的消息客戶(hù)則對(duì)這一通道進(jìn)行監(jiān)聽(tīng)或者訂閱，用以完成消息處理。使用JMS，可以實(shí)現(xiàn)松耦合、消息異步處理和保證可靠性的目的。系統(tǒng)監(jiān)測(cè)算法是指通過(guò)動(dòng)態(tài)監(jiān)測(cè)評(píng)估后臺(tái)服務(wù)器的綜合性能，例如CPU 使用率、空閑內(nèi)存等，結(jié)合系統(tǒng)總體性能，根據(jù)評(píng)估結(jié)果賦予服務(wù)器不同權(quán)值，然后調(diào)度服務(wù)器可以將外部請(qǐng)求發(fā)送到負(fù)載最輕也就是權(quán)值最小的服務(wù)器上。調(diào)度服務(wù)器可以自動(dòng)更新真實(shí)服務(wù)器的負(fù)載情況，并動(dòng)態(tài)地調(diào)整其權(quán)值[6]。“加權(quán)”的意思即是根據(jù)服務(wù)器的不同負(fù)載能力，為每一臺(tái)集群中的服務(wù)器設(shè)定權(quán)值用以表明服務(wù)器負(fù)載能力，之后調(diào)度服務(wù)器通過(guò)“加權(quán)輪叫”調(diào)度算法根據(jù)不同權(quán)值來(lái)分配訪(fǎng)問(wèn)請(qǐng)求[8]。當(dāng)然，基于輪叫算法，又產(chǎn)生了一種“加權(quán)輪叫”算法。這種算法的弊端就是它不考慮調(diào)度服務(wù)器上的實(shí)際可用服務(wù)器連接數(shù)和負(fù)載能力，只是進(jìn)行簡(jiǎn)單的輪詢(xún)制的分配。負(fù)載均衡調(diào)度算法包括輪叫算法、連接算法、系統(tǒng)監(jiān)測(cè)算法等。負(fù)載均衡集群的調(diào)度服務(wù)器就是負(fù)責(zé)對(duì)需要進(jìn)行集群部署的機(jī)器進(jìn)行負(fù)載調(diào)度的服務(wù)器。 負(fù)載均衡集群本文重點(diǎn)研究負(fù)載均衡集群。其中任務(wù)片方式是將計(jì)算任務(wù)預(yù)先分配到不同機(jī)器上處理，最后將結(jié)果匯總，適合于低耦合的計(jì)算任務(wù)；并行計(jì)算則是保證計(jì)算任務(wù)的完整性的前提下，將計(jì)算任務(wù)在不同機(jī)器之間進(jìn)行轉(zhuǎn)發(fā)處理，適合于高耦合的計(jì)算任務(wù)。這一技術(shù)的關(guān)鍵是不同機(jī)器可以在象征性的“同時(shí)”的狀態(tài)下完成計(jì)算工作。這是集群技術(shù)的另外一種方式，相較于上述兩種集群方式較為復(fù)雜。當(dāng)然，完成合理分配是具有一定難度的，需要根據(jù)系統(tǒng)現(xiàn)狀，采用合適的負(fù)載均衡算法實(shí)現(xiàn)負(fù)載均衡的目的。在集群的部署模式下，每個(gè)機(jī)器相當(dāng)于一個(gè)節(jié)點(diǎn)，合理的部署模式是能夠?qū)⑺械南到y(tǒng)負(fù)載合理地分配到不同的節(jié)點(diǎn)上。負(fù)載均衡集群的設(shè)計(jì)是基于有效分配系統(tǒng)負(fù)載的需求提出的。高可用性集群通常是由多個(gè)節(jié)點(diǎn)構(gòu)成，當(dāng)單個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，系統(tǒng)其他節(jié)點(diǎn)接替服務(wù)，這樣就可以最大限度地減少服務(wù)中斷時(shí)間，甚至將服務(wù)中斷時(shí)間將為零，進(jìn)而保證整個(gè)系統(tǒng)仍能繼續(xù)正常對(duì)外提供服[7]。許多應(yīng)用程序提供的服務(wù)都需要服務(wù)器能夠提供24小時(shí)不間斷的運(yùn)轉(zhuǎn)。高可用性集群。實(shí)質(zhì)上，這樣一個(gè)集群是由多臺(tái)Linux或者UNIX機(jī)器互連部署形成的計(jì)算機(jī)群。 Linux 可以運(yùn)行于極為普及的計(jì)算機(jī)上 不需要購(gòu)買(mǎi)昂貴的UNIX硬件設(shè)備 在幾臺(tái)運(yùn)行Linux 的計(jì)算機(jī)上，只要加入相應(yīng)的集群軟件，就可以組成具有很強(qiáng)可靠性、負(fù)載能力和計(jì)算能力的Linux集群。但是隨著對(duì)Linux服務(wù)器的