將面向服務(wù)架構(gòu)（SOA）應(yīng)用遷移到包括云在內(nèi)的虛擬資源池中是有一些棘手的。也許在SOA應(yīng)用中處理彈性資源池最大的問題是，錯誤地認(rèn)為SOA發(fā)布/登記流程完全掌握了資源的發(fā)放，但實(shí)際上這會在相當(dāng)程度上把事情復(fù)雜化。
許多情況下，SOA應(yīng)用針對虛擬資源進(jìn)行優(yōu)化所需的變化被局限在publication/syndication及編排流程，應(yīng)用架構(gòu)師很容易就能對其進(jìn)行規(guī)劃，并推動這些更好地為未來準(zhǔn)備。在云爆發(fā)或組件變更會引發(fā)狀態(tài)保持的特殊情況下，特定流程必須按照次序進(jìn)行。這要由應(yīng)用架構(gòu)師來決定何時需要進(jìn)行虛擬資源調(diào)節(jié)以及如何優(yōu)化它們。
SOA應(yīng)用在高層將應(yīng)用用戶/服務(wù)用戶與服務(wù)及其組件通過登記流程進(jìn)行綁定。其目標(biāo)是讓應(yīng)用組件松耦合，甚至到允許應(yīng)用利用web服務(wù)描述語言（WDSL）動態(tài)“購買”組件的地步。組件被托管時“發(fā)布”到注冊流程—比方說，如果它是通過虛擬機(jī)器（VM）移動功能遷移的話。
隨著資源分配變得越來越動態(tài)，注冊功能的性能變得重要起來，其主要原因并非因?yàn)樗锌赡苡绊懙綉?yīng)用性能，而是由于對行動緩慢的注冊流程的快速變更會出現(xiàn)在重新注冊期間要處理服務(wù)請求的風(fēng)險。這會導(dǎo)致應(yīng)用的一部分與工作流失聯(lián)，造成應(yīng)用的不穩(wěn)定。重新注冊的風(fēng)險問題可通過確保注冊流程迅速處理請求，以及在停掉（以及撤銷注冊）舊位置的組件之前，一旦組件出現(xiàn)在新的位置時就首先注冊該組件來降低。
性能工作流以及動態(tài)資源
并非所有動態(tài)資源都是生而平等的；在VM移動應(yīng)用中，通常是在數(shù)據(jù)中心之內(nèi)對機(jī)器進(jìn)行遷移，而在云端，組件可能被托管在千里之外。此類彈性問題在于其對應(yīng)用工作流未來性能進(jìn)行優(yōu)化的影響。
在許多牽涉到服務(wù)總線協(xié)調(diào)和集成的應(yīng)用中，如果應(yīng)用組件托管在相互“網(wǎng)絡(luò)距離”遙遠(yuǎn)的地方，消息流延遲的累積會影響到應(yīng)用性能，這意味著由于地理距離及網(wǎng)絡(luò)跳轉(zhuǎn)很可能會經(jīng)歷顯著的傳輸延遲。而WDSL幾乎從來就沒有考慮過這一點(diǎn)，因此訂購組件的應(yīng)用有可能選到了一個距離太遙遠(yuǎn)的組件來支撐體驗(yàn)質(zhì)量目標(biāo)。
解決方案之一是讓W(xué)DSL適應(yīng)至少包括地理“區(qū)域”參考在內(nèi)的因素來進(jìn)行托管，以便運(yùn)行在特定地方的應(yīng)用會選擇復(fù)制于相同地理位置的組件。另一種辦法則是適應(yīng)訂購方對注冊流程的處理，返回匹配請求方地理位置的組件。
這些方法哪一個最好，將取決于應(yīng)用架構(gòu)師能夠控制注冊流程的程度；開源工具很容易修改，但是專利工具可能就不允許修改，只能嘗試“給WDSL添加位置”的辦法。如果所有其他辦法都失效了，應(yīng)用用戶可以被定向到特定位置的注冊點(diǎn)，確保不會選到地方太遠(yuǎn)的組件。當(dāng)然，所有這一切，都依賴于至少對組件托管時的存放位置有一些了解。要看一下云供應(yīng)商的管理能力，看看可以做哪些事情。
SOA協(xié)調(diào)及云爆發(fā)
在SOA/虛擬資源應(yīng)用中，協(xié)調(diào)本身會是一個復(fù)雜的因素。因?yàn)橄⒘髟诜⻊?wù)總線上合并，如果中間件采用的是真正集中化的總線架構(gòu)的話，協(xié)調(diào)點(diǎn)的位置會是性能的一個重要因素。允許直接將消息傳遞給后繼組件的更為分布式的消息管理，對于許多SOA應(yīng)用來說并不實(shí)際，因?yàn)樗鼈兺ㄟ^業(yè)務(wù)流程執(zhí)行語言（BPEL）或別的工作流語言強(qiáng)加一種消息操縱邏輯。對于這些情況，選擇在哪里對應(yīng)用進(jìn)行協(xié)調(diào)對于讓SOA與動態(tài)資源適配來說至關(guān)重要。
對于企業(yè)來說，云內(nèi)的負(fù)載均衡或數(shù)據(jù)中心資源以及溢出云資源之間的云爆發(fā)正成為越來越有價值的應(yīng)用，但是這往往意味著未來工作共享需要復(fù)制多個組件出來。在設(shè)計心得SOA組件時，考慮這一未來需要是明智的，因?yàn)樵S多組件會維持狀態(tài)或在多步事務(wù)中維持工作的上下文，因此無法在事務(wù)中被替換，否則的話狀態(tài)就會丟失。
Web或RESTful應(yīng)用設(shè)計學(xué)校一直倡導(dǎo)有客戶端來維持狀態(tài)，但是在SOA中，甚至在某些中間件里，組件也會如此。當(dāng)應(yīng)用是通過BPEL在中間件/協(xié)調(diào)級創(chuàng)建時，中間件狀態(tài)控制尤其常見，且盡管這種做法被SOA架構(gòu)師詆毀，在云爆發(fā)或負(fù)載均衡應(yīng)用中它有可能比由組件維持狀態(tài)更加靈活。如果不能確定的話，客戶端狀態(tài)管理是最好的！
如果為了利用資源的動態(tài)性而加入容錯設(shè)施，哪怕在云和虛擬應(yīng)用沒有負(fù)載均衡的情況下狀態(tài)也會成為問題。許多架構(gòu)師忘記了如果狀態(tài)是由組件自身維護(hù)的話，它會在失敗時丟失，從而令追求快速動態(tài)故障切換的目標(biāo)無法實(shí)現(xiàn)。在致力于包含有動態(tài)故障切換的SOA應(yīng)用之前，應(yīng)該先檢查看看狀態(tài)是如何維持的，否則的話你有可能浪費(fèi)寶貴的時間，為某事準(zhǔn)備的ALM周期將無法正常工作。
注冊的控制、協(xié)調(diào)以及狀態(tài)是SOA動態(tài)資源優(yōu)化的三大問題。開始考慮這三點(diǎn)的應(yīng)用架構(gòu)師可能很快就能找到所有重要的問題并正確處置。這是確保SOA應(yīng)用響應(yīng)云和虛擬化趨勢以及在未來應(yīng)用設(shè)計中正確地將其作為基石的最好方式。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：SOA應(yīng)用開發(fā)和遷移不再難
本文網(wǎng)址：http://www.oesoe.com/html/consultation/1083939676.html
相關(guān)文章
