SOA 新業務語言 新系統架構——構建SOA

文章目錄

• SOA 新業務語言 新系統架構——構建SOA
• IBM
• Microsoft
• 《SOA概念、技術與設計》

 

SOA 新業務語言 新系統架構——構建SOA 對於企業業務來說，面向服務的架構(SOA)最大的優點就是靈活的響應能力。企業經常受到各種各樣變化的影響：市場、供應鏈、戰略流程、規則等。SOA可以建立一個靈活的環境，可靠地應對各種變化。原因在於SOA將自動化功能以可重用的方式重組，這樣便可快速配置新的或修正的流程。　　但僅僅依靠一個架構來實現敏捷性是不夠的。敏捷性來自可提供敏捷流程的各個方面。開發、重構或者建立正確的服務都需要對業務有很深的瞭解。　　由於標準化的最佳實務、深層通訊及資料協議和工業“開放性”的發展方向，SOA幾乎經曆了一場敏捷性的完美風暴。企業整合的努力及物件導向等理論的發展逐漸形成了最佳實務。由於網際網路的發展，管接技術(plumbing)成為深入瞭解和普及整合的必須。而客戶的需求、開源及資訊公開運動則促成了開放性的發展。　　為什麼說幾乎是一場完美的風暴呢?因為與之前的技術一樣，SOA只是一種使能技術。如果沒有對當前商務程序的深入瞭解，或對流程變化的總體認識，便不能正確地選擇組件，也就不能形成完美的敏捷性。　　SOA不只是怎麼做的問題，真正的業務規劃應該從做什麼開始。簡單地說，如果不知道該“做什麼”，那麼即使知道該“怎麼做”，做出來的東西也是不相干的。　　

用藍圖(Blueprints)實現“中間相遇”

　　有什麼可以指引這些新架構方法和底層技術的應用呢?　　有什麼可以防止SOA實踐者只是簡單地進行整理而沒有取得SOA真正的敏捷性和營運目標的一致性呢?　　有什麼能保證整理好的“SOA”架構能帶來可觀的效益呢?　　在SOA領域裡，關於治理的重要性已經討論了很多，但這仍然是一個怎麼做的問題，而不是做什麼。比如設計時的治理，要支援組件的重用，這是SOA的一個重要方面。如果不能重用為什麼還要花錢進行這種重用性開發呢?但對決定重用哪些部分的過程的討論卻很少。而且，成功的先決條件應該是一個可以指導選擇或建立能真正實現敏捷性的組件的模型，這樣組件才能支援新的或更高層次的商務程序。　　關於以自上而下(top down)還是自下而上(bottom up)的方式採用SOA也有許多討論。兩種方式都有不同的優缺點。自上而下的方式可以讓你“感覺不錯”，因為這種方式是基於充分分析與調查的基礎之上，但卻容易導致無限制地進行描述或制定標準，即“分析乏力”，以至計劃趕不上需求與技術的更新。　　自下而上的方式便於迅速著手，通常是為了追求新技術，並有“有機(organic)”方法的優點。然而，這種方式也常常導致不可重用的組件或沒有組織性的服務，雖然符合部分面向服務的規則，卻不能提供真正的敏捷性或再現商務服務一致性。　　還有一種“中間相遇”(meet in the middle)的策略可以將兩者的優點很好地結合起來。深入瞭解營運目標並將其重組，以及支援這些目標的過程是最容易控制和規劃的方法。但“最好的規劃”也可用於自下而上的方法，即先開始，然後在過程中重構、學習經驗，並支援根據不斷變化的優先順序、需求和技術進行細粒度的調整。由於支援平行開發，“中間相遇”的方法通常具有時間上的優越性，而自上而下的方法通常代表不同的組織和規則。但這也正是需要解決的問題。兩個為“中間相遇”而努力的團隊需要精準地瞭解彼此之間將怎樣串連。這可不是馬馬虎虎就能解決的問題。 　　一個代表當前及期望狀態的全面的分層模型(一般稱為藍圖)可以有效地支援“中間相遇”的方法。這個方法需要自上而下方法的清晰的追蹤性，而藍圖正好可以提供這一點。有了這樣一個藍圖，最終將使“宏偉目標”發揮最大效益，並可以根據基礎設施與流程需求進行平行開發。　　這是SOA實踐者提供的建議，可以建立有著很好可視性並且需求簡單的觀點驗證(proof-of-concept)，以保持注意力。在互動開發的藍圖中採用這種方法可以從營運目標到協助實現目標的基礎設施自上而下地探索追蹤性。以進行足夠的高層建模與定義作為基礎，確定早期開發的關鍵過程;但要及早進入開發過程為下一步積累經驗，做到見多識廣並且信心十足。　　因為藍圖良好的可追蹤性，可以察看當前實現或觀點驗證(poc)所滿足的需求。還可以作為捕捉實現SOA化企業過程中每一步中變化的規劃，並提供合適的組件以獲得最大的敏捷性。藍圖是一種通用語言，定義了頂端的業務結構與底層的系統架構之間的接觸點。藍圖可以確保計劃能真正的“中間相遇”。　　實質上，藍圖也就是各企業的“架構複本”，並且由於實際上它是由軟體工具啟動的，因此稱之為數位模型更為貼切。在藍圖中，治理成為一種實現這個“複本”的控制和通訊架構。計劃可以提供進度與資源以進行藍圖中“現狀(as is)”模型與“將來(to be)”模型之間的差距分析(gap analysis)。　　由於藍圖中各層之間的可追蹤性，可以通過經過最佳化的營運目標確定需要變化的商務程序，再根據商務程序確定底層的自動控制和組件，最後確定需要變化的基礎設施。有了藍圖，便很容易根據業務範圍、投資報酬率、可用資源或其它非直接與架構和技術有關的因素對項目進行最佳化。這樣便能並存執行計劃，並保證可根據進度提供所有組件，實現IT與營運目標的一致性。 來源：SOA應對敏捷企業變化http://soa.csdn.net/page/ea2ccde0-36fd-40e7-968a-bd557faa9c32 IBMIBM發現並指出了5個可以協助客戶更加容易地著手實施一個SOA項目的切入點。這些切入點包括:以人員(People)、流程(process)、資訊(Information)為中心的方法、以及系統串連性(connectivity)和重用現有資產的能力(creating and reusing services)。

• 以人員為中心的SOA切入點，能夠為企業提供綜合資訊，以及在商務程序中互動的視圖，提升人員生產力。美國漢諾威(Hanover)保險公司通過部署 SOA 門戶，處理業務的速度提高了 75%。
• 以流程為中心的SOA切入點，是一種藉助重新利用和最佳化流程，快速部署創新的業務模式。美國Wachovia公司通過單一流程實現了80%的自動化，將客戶服務進行了進一步創新。
• 以資訊為中心的SOA切入點，以嵌入式(in-line)或現場(in-context)的方法提供可靠資訊服務，提高企業業務洞察力，從而降低風險。應用此方法，福士汽車公司的員工招聘效率提高了20%。
• SOA串連切入點，將串連作為基礎以支援以業務為中心的SOA。它通過具備任意互連( any-to-any connectivity )的新型業務渠道提供服務，實現安全、一致的使用者體驗。同時相比定製整合或FTP* 可節省2到4倍的費用。
• SOA建立和再利用服務的切入點，能夠輕鬆實現SOA管理的再利用。通過再利用可降低成本、縮減周期、拓展核心應用，同時再利用現有應用的費用只是重新編寫新應用所需費用的五分之一。

MicrosoftMicrosoft advocates a ―” middle out” approach which combines both top-down and bottom-up methodologies. In this approach, SOA efforts are driven by strategic vision and business need, and are met through incremental, iterative SOA projects that are designed to deliver on business goals one business need at a time. Microsoft has been using this technique to assist customers with their SOA initiatives since the .NET framework was first released in 1999. 《SOA概念、技術與設計》

• SOA交付策略：自頂而下、自底而上、敏捷
• 面向服務分析：服務建模
• 面向服務設計：WSDL、SOAP
• 面向服務設計：SOA組合指導原則
• 面向服務設計：服務設計
• 面向服務設計：商務程序設計
• WS-*擴充