在SOA的使用中存在著隱患，很多人已經被這些錯誤的概念或者做法誤導，那么，理解這些隱患，能夠幫助你達到深謀遠慮的程度，從而使你在SOA的道路上更加安全的前行。為了使你有一個好的開端，我們已經收集了五種最為常見的、SOA使用中的隱患。 現在是SOA領域動蕩變化的時期，其發展變幻莫測，而這僅僅只是開始。由于服務設計、服務總線、服務治理甚至服務本身都處于不斷變化中，而且各大公司仍在重審這一舞臺，因此，人們的立場通常很復雜。對于IT產業中SOA的成熟度和整體狀態，許多人還非常迷惑，但是，可以確定的是，SOA在結合商業和技術方面的潛力的確非凡。 去年發布了許多SOA的新方案，每一個方案都有其特定的一套目標和期望。很可惜，其中一些方案與成功相距甚遠，一些方案距成功僅僅是一步之遙。但是，對于大多數方案而言，它們都實現了最初的目標，其成功的決定因素是——借鑒那些經歷過失敗項目的人們的寶貴經驗。這些前輩講述他們的經驗教訓，告訴人們在通往SOA道路上所要警惕的重重障礙。 在我們的日常工作中，我們被卷入進度不同、狀態不同的多個項目中。而現在，我們已經看到，很好的SOA變得越來越差，甚至更糟。雖然，問題能夠被解決，錯誤能夠被避免，但是，總是有一種強大的力量把事情拖回到原來的軌道上。很明顯，最佳做法就是：第一時間避免問題和錯誤。 在SOA的使用中存在著隱患，很多人已經被這些錯誤的概念或者做法誤導，那么，理解這些隱患，能夠幫助你達到深謀遠慮的程度，從而使你在SOA的道路上更加安全的前行。為了使你有一個好的開端，我們已經收集了五種最為常見的、SOA使用中的隱患。 　　沒有理解SOA的性能需求 松散耦合是需要代價的。當使用Web服務實現松散耦合時，SOA引入了數據處理層，同時也帶來了由這些層所影響到的上層的相關性能。當SOA項目剛開始時，規模較小，因此，構建符合功能和響應要求的、面向服務的解決方案并不復雜。但是，隨著規模的增加，需要添加更多的功能，由此可以預見到，基于信息的通訊量將會大幅度增長。如果事先沒有考慮這一情況，沒有準備好構建環境的話，那么，就需要對前一階段所做的小規模系統進行必要的遺留處理。 要構建一個成功的面向服務的解決方案，其關鍵是:盡快理解你的解決方案的性能需求、以及基礎架構的性能瓶頸。這意味著測試(如果需要的話，增強)你的構建環境的消息處理能力，并且密切關注服務設計，從而達到傳輸率、傳輸規模以及與其他服務特性之間的一個可接受的平衡點——這一平衡點會影響解決方案的性能。 　　沒有從XML基礎架構開始 在今天的SOA世界中，每件事情都開始于Web服務。這似乎已經成為公司內部的既成標準，但是它并不完全正確。事實上，在今天的SOA世界中，所有的事情都開始于XML。這才是真正的標準，依據這一標準，許多補充的標準都已經逐漸發展起來，并且形成了實際的數據表示架構。這一標準的核心，奠定了許多Web服務規則的形成基礎，并且促進著SOA的發展。 因此，人們更多地關注于數據在服務之間是如何傳輸的，而經常忽略在服務背后，數據構造和驗證的方式。這一疏忽可能導致無法合理實現SOA的持久化XML數據表示層。對于SOA而言，這一層是基礎，如果它存在著弱點，那么，所有基于這一層的解決方案都會受到不利影響。 　　沒有創建一個過渡計劃 如果沒有使用一個詳盡的過渡計劃，那么，成功遷移的機會將會降低很多。因為，在一個企業內部，服務終端所處位置的范圍將導致環境基礎架構的重新確定，一次差強人意的遷移有可能帶來重大影響。使用過渡計劃，你就能夠控制面向服務和SOA特性，并且進行相應的協調，如此一來，遷移就能夠在技術、架構以及組織層面上，按照計劃進行。 對于一個SOA過渡計劃而言，其典型的組件包括:一個具有重大影響的分析結果(預測SOA的改變程度將如何影響已有資源處理、用戶標準和技術)、過渡架構(目標是SOA，勾畫出一系列通向這一目標的中間過渡狀態)以及推測分析(考慮Web服務和支持技術的未來發展)。 　　沒有標準化SOA 與其他的架構相同，SOA也需要創建并且執行內部設計標準，以便能夠使人們真正地認識到它的優勢。舉例說明，如果一個項目采用構建面向服務的解決方案，與其他項目不同，那么，該項目的解決方案的關鍵點將不再是與相關的應用程序保持一致，它可能是需要互操作或者分享某些不可預知的服務。 這可能引發很多問題，包括不匹配的數據表示、含有不規則接口特性和語義的服務契約，以及使用非互補的Web服務擴展(或者是用不同方式實現的擴展)。 SOA的出現，促進了分離后端處理這一開發環境的發展，因此，在每個應用程序內部，SOA都能夠獨立執行。然而，標準化仍然要求——服務需要封裝這一后端邏輯，并且在設計和交互上確保一致性。 　　將SOA構建成傳統分布式架構 在實現SOA的過程中，企業一直面對的誘惑是：自稱SOA已經實現了，但是在構建面向服務的解決方案時，采用與構建傳統分布式解決方案相同的構建方式。 SOA既不是CORBA + XML，也不是 ASP.NET + WSE。同樣，面向服務既不是面向對象，也不是“足夠接近”面向對象。雖然，通常情況下，構建面向對象組建邏輯總是“非常適合”于面向服務解決方案的環境。但是，SOA是基于面向服務的、與眾不同的架構模型，以及截然不同的設計模式。對于構建自動化邏輯——純粹的面向服務，與SOA產業向全球規模發展保持一致——理解上述這些不同之處，是非常關鍵的。 職場 互聯網 休閑

0

分享

微博 QQ 微信

收藏

上一篇：網絡解決方案展示 MPLS TE... 下一篇：Trojan-Downloade... sppb

63篇文章，9W+人氣，0粉絲

Ctrl+Enter?發布

發布

取消

推薦專欄更多

網絡安全入門到實戰，讓SQLmap子彈飛一會兒

9本網絡安全實戰書籍精華

共23章?|?simeon2005

￥51.00 830人訂閱

訂???閱 Web網站安全評估分析及防御

企業級網安運維

共30章?|?simeon2005

￥51.00 408人訂閱

訂???閱 負載均衡高手煉成記

高并發架構之路

共15章?|?sery

￥51.00 507人訂閱

訂???閱

猜你喜歡

我的友情鏈接 精英設計師的情書 DNS域名系統 OpenResty的現狀、趨勢、使用及學習方法 C#調用WebService實現天氣預報 Windows 8.1 正式版全新完美激活 KMS 工具 Office 2013全新完美激活工具 “ KMSpico v9.0.5.20131119” Java線程：線程的調度-休眠 我們不得不面對的中年職場危機 Spring Boot 2.0(三)：Spring Boot 開源軟件都有哪些？ ***619錯誤處理辦法及***鏈接成功后無法聯網解決辦法 淺談DNS體系結構：DNS系列之一 17款奇駿智能互聯連接成功--高德導航 通過關鍵字獲取漏洞平臺最新漏洞信息 11月10日直播：EVE-NG模擬器入門和老司機心得分享，你來不來？ 網工2.0 - 給你一次逆襲的機會 python-dnspod：批量添加域名、解析記錄和修改解析記錄等 H3C室外無線AP（WA4320X）胖瘦切換設置方法 網絡運維 - 你與真相就差一層窗戶紙 F5負載均衡上使用iRule 來選擇SNAT pool 高校智能DNS解析技術總結分析

掃一掃,領取大禮包

0

分享 sppb

轉載于:https://blog.51cto.com/innovo/49019

總結

以上是生活随笔為你收集整理的应用分析：CIO须注意SOA使用中的五大隐患的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。